it:ad:continuous_deployment:sad:introduction:home

IT:AD:Continuous Delivery:SAD:2. Introduction and Organisation Context View

This section describes how the Solution's Context in terms of the following:

Sector Strategic AlignmentEnterprise Strategic AlignmentImpacted DepartmentsImpacted Stakeholder RolesExisting IT Process Improvement

2023/07/07 04:06

Software is recognized as a key business differentiator[4] and organizations now expect software development teams to deliver more functionality and innovation by implementing initiatives to speed up the SDLC.[5][6]

But organisations find that certain process prevent them from achieving the expected benefits of their SDLC acceleration initiative.

This Solution proposes an industry recommended approach to release the expected benefits for future projects.

The solution is driven by number of assessments(Problems/Opportunities), drivers (Internal/External) and goals:

A number of key Assessments of the organisation's current development pipeline are mapped below.

The above Assessments identify organisation issues that reflect well-recognized issues that are not unique to this organisation.

After accelerating other aspects of the delivery pipeline, organisations typically find that traditional Testing and overall Quality and Accreditation processes remain problematic[9], preventing organisations from achieving the benefits of their expected SDLC acceleration initiative.[8]

Assessment:

Assessment: Testing: Functional Testing

Software delivery iteration lengths between delivery to end users has changed from months or even years to weeks or days. Traditional methods of testing, which rely heavily on manual testing cannot keep pace. [8][10]

Initiatives to automate GUI testing have also proved problematic, due to requiring frequent adjustments.[8][10]

Assessment: Testing: Quality and Assessment Testing

Even when more current development patterns (eg: Service based UIs) and related test automation practices are added to existing test process[1][11], decision makers still lack adequate insight into the level of risk associated with an application at any given point in time.[2]

Understanding these risks is critical for making the rapid go/no go decisions involved in Continuous Delivery processes.[12]

If tests are developed without an understanding of what the business considers to be an acceptable level of risk, it is possible to have a release candidate that passes all the available tests, but which the business leaders would not consider to be ready for release.[13]

For the test results to accurately indicate whether each release candidate meets business expectations, the approach to designing tests must be based on the organisation's tolerance for risks related to security, performance, reliability, and compliance.[4]

In addition to having unit tests that check code at a very granular bottom-up level, there is a need for a broader suite of tests to provide a top-down assessment of the release candidate's business risk.[3]

Even if testing is automated and tests effectively measure the level of business risk, teams without a coordinated end-to-end quality process tend to have trouble satisfying the business expectations within today's compressed delivery cycles.[3] Trying to remove risks at the end of each iteration has been shown to be significantly slower and more resource-intensive than building quality into the product through defect prevention strategies such as development testing.[14][15]

Organizations adopt Continuous Testing as part of their Continuous Delivery processes because they recognize that these problems are preventing them from delivering quality software at the desired speed.

Organisations recognize the growing importance of software as well as the rising cost of software failure, and they are no longer willing to make a tradeoff between time, scope, and quality.[2][16][17]

The Goals/Objectives to address the above Assessments are mapped as follows:

High Level Functional Requirements were developed to meet the previously specified Goals:

The use of a Cloud Service based Development Pipeline aligns with Organisational Strategies, specifically:

  • Digital Strategy:
    • Education sector agencies and Government:
      • “Smart tools and common IT systems make delivering service improvements and implementing policy changes simpler and less expensive than they used to be, freeing up investment to improve outcomes for students and educators.”

The use of a cloud service based Continuously Accredited Delivery Service aligns with Ministry objectives of: * Aligning with the Digital Strategy * Better Value for Money.

The use of a Cloud Service service based Continuously Accredited Delivery Service aligns with other IT Projects and in some cases is a pre-requisite for other IT Projects. Specifically:

  • Dependencies:
    • None.
  • Prerequisite for:
    • The Development Cloud Project.
  • Informs:
    • ESIAM

As per the the motivation diagram above, an Assessment of the current delivery work flow for both internal and external development services is detrimental to delivering value to customers rapidly.

Below are outlined at a high level some of the more self-evident poor practises that negatively affect the organisation's IT customers.

The current project's goal is to replace these poor practices.

The current document is make more people aware of the poor practices so that we don't repeat them in the future, or design our infrastructure environments so poorly that poor practices become the norm again.

Of special note are the following areas which will be improved by the delivery of the proposed service.

  • Infrastructure Provisioning
  • Application Deployment
  • Testing Handover
  • Testing
  • Security Testing
  • Penetration Testing

A well-known issue with development for the organisation – whether done in house or by external development services – is the amount of time it takes to discuss, commission and obtain the infrastructure required for a project.

Infrastructure Services must be judicious with providing limited resources to projects. But projects continue to request considerable resources due to a combination of: * requiring upfront reservation of all the servers required for a project, for a multitude of environments (DEV, ST, UAT, TRAIN, PROD) * the organisation has no means of saving resources when not needed, and elastically meeting demand as required, * due to the quality of the development services employed, the applications are resource hungry.

The result is the process for obtaining the infrastructure for a project can be lengthy one:

Current Organisation Infrastructure Provisioning ProcessProccess can takeup to a monthif requestinglots of resources;meetwith InfrastructureServices (IS)to review SADdeploymentdiagrams.This process cantake 2 weeks.create environmentas per understoodspecifications.report completionreview infrastructurecorrect & complete?Project ManagementInfrastructure ServicesDevelopers

The deployment process we currently use is poor value for end users.

The following sequence diagram demonstrates this succinctly.

Current Organisation Infrastructure Provisioning ProcessProccess can takeup to a monthif requestinglots of resources;meetwith InfrastructureServices (IS)to review SADdeploymentdiagrams.This process cantake 2 weeks.create environmentas per understoodspecifications.report completionreview infrastructurecorrect & complete?Project ManagementInfrastructure ServicesDevelopers

developmentcomplete afteryears of workand thousandsof work itemswithin thedevelopment'spreferred ALM(TFS, JIRA,GitHubBitbucket,GitLab,etc.)test serviceswill not acceptproject unlessexisting opendefects areexported from theproject's ALMand imported intoTest Services ALMManagementTest Services

  • /home/skysigal/public_html/data/pages/it/ad/continuous_deployment/sad/introduction/home.txt
  • Last modified: 2023/11/04 23:18
  • by 127.0.0.1