Introduction
In this article I describe the outline of "a mature development and deployment process". At its core is the idea to go away from update sets to deploying application versions - hence to get away from "deploying stories" towards "deploying versioned software artefacts".
This transition raises many questions - which are discussed in great detail in the whitepaper "A mature development and deployment process":
https://www.wildgrube.com/download/A%20mature%20Development%20and%20Deployment%20Process.pdf
This articles provides an overview of the process and its quality gates. The whitepaper has all the answers regarding the technical changes, tooling, governance, automated QA and deployment and the superpowers required to change the organization i.e. the people's behaviors.
Process Overview
As for every process, it requires three factors to play all well together: people, technology, and organization.
In the following chapters we will provide a high-altitude overview on the process, describe in detail what the building blocks for the process are, which quality gates and procedures need to be put in place and which techniques the development teams need to learn and apply.
Further, we will outline an approach to introduce the process into an existing or new organization.
When thinking in terms of a process, the most obvious question is: what represents one single instance of the process?
The process ranges from end-to-end: from the documentation of an idea or demand stated by a Product Owner representing the business to the moment in time when a new or changed application capability can be used in production.
The process has 3 phases:
- Implementation
- Application Delivery
- Test and Production Deployment
The process “instance” is a different one in each of the phases:
- During “Implementation”:
A single backlog item - During “Application Delivery”:
An application version
(which embodies changes resulting from one or more backlog items) - During “Test and Production Deployment”:
A release package
(which is a combination of one or more application versions and instructions on how to install them on a target instance)
The process has 6 quality gates:
During Implementation
- Backlog item is “Ready”
- Backlog item is “Done”
During Application Delivery
- Application version is “Baselined”
Test and Production Deployment
- Release package is “In Test”
- Release package is “Ready for Production”
- Release package is “Deployed to Production”
The following chapter provides more insights on the quality gates and what requirements must be met to pass them.
Process Overview with phases, instances, and quality gates
Quality Gates
Implementation: Backlog Item is “Ready”
To pass this quality gate a backlog item must be sufficiently documented, so that the development team can start working on it.
Sufficient documentation must meet all criteria defined in the “Definition of Ready”. However, not only must the “user story” be told, but there are also architectural decisions to be made.
Which applications need to be created or changed? Which dependencies must be considered? Should existing functionality be changed or new components be created?
Another important aspect is the relevant personas, which ideally map to roles and access rights.
As always a fair balance needs to be found between excessive precision upfront and flexibility and creativity in the process. Asking these questions is never wrong – but in some cases they may get answered later in the process.
The question whether any kind of estimate (in hours, story points, or t-shirt sizes) should be done before or after a backlog item is considered “Ready”. One can argue that an estimate is only possible IF the backlog item is ready. One may also argue that once enough information is available for an estimate, it could also be made a requirement to include the result of an estimate into the definition of ready right away. As many organizations develop their own agile style, this document does not make any suggestion when estimation takes place or even if estimations should be done at all.
Checklist
- The documentation of the backlog item is compliant with the Definition of Ready
- The impacted applications have been identified and documented
- The expected dependencies have been identified and documented
Relevant Building Blocks
- Application Architecture and Dependency Management
- Definition of Ready
Gatekeepers
- Lead Developers
- Architects
Implementation: Backlog Item is “Done”
To pass this quality gate a backlog item must be completely implemented according to the requirements documented in the backlog item itself AND the additional requirements documented in the “Definition of Done” – which should specify that all tests must pass, and the delivered code is fully compliant with the Coding Guideline.
The completed code must be committed to the Source Code Repository.
“Done” does not mean that the capability described in the backlog item is available to users in production.
Checklist
- All activities defined in the Definition of Done are completed
- All related changes have been committed to the development branches of the impacted applications
- All related application files are compliant to the coding guideline
Relevant Building Blocks
- Definition of Done
- Coding Guideline
- Automated Tests
- Source Code Repository
Gatekeepers
- Lead Developers
- Product Owners
Application Delivery: Application Version is “Baselined”
To pass this quality gate an application version is available as a version specific branch (or tag) in the source code repository.
All activities described in the Application Version Baseline Procedure must be completed. That includes that any unfinished work is configured in a way that it does not impact the application’s behavior and it is (like all other technical debt) is documented as outlined in Technical Debt Management. The development team must have run all automated tests and verified their compliance with the Coding Guideline – verified through Instance Scan checks.
Checklist
- All activities defined in the application version baseline procedure have been performed
- The version branch is locked and protected against future changes
Relevant Building Blocks
- Application Version Baseline Procedure
- Technical Debt Management
- Source Code Repository
- Branching Strategy
- Coding Guideline
- Automated Tests
Gatekeepers
- Lead Developers
- Architects
- Product Owners
Test and Production Deployment: Release Package is “In Test”
To pass this quality gate a release package is successfully installed on a TEST environment.
To get there, a set of application versions – which typically relate to each other through their documented dependencies – must be identified. All steps required to install these application versions must be documented, reviewed, and performed on the TEST environment. As part of the deployment, all automated quality assurance activities should be conducted – ideally even before installing the release package on the TEST environment. These automated activities should at least include running all available and relevant ATF tests contained in the applications in the release package and performing coding guideline compliance checks using Instance Scan checks on these applications.
Checklist
- Deployment instructions do NOT contain update sets (all changes must be shipped as part of a baselined application version)
- Deployment instructions do NOT contain manual tasks – everything that needs to be “done” should be scripted in installation scripts
- All applications contained in the release package have been deployed to the TEST environment (in the required versions)
- All applications are fully compliant with the coding guideline – i.e., there are no Instance Scan findings
- All installation scripts of all applications have been executed
- All ATF tests contained in all applications have passed
- All steps defined in the deployment instructions have been performed – this may include activities to be performed in external systems or communication to stakeholders
- Smoke tests have passed – these are any quick manual tests
Relevant Building Blocks
- Source Code Repository
- Coding Guideline
- Automated Tests
- Deployment Automation
Gatekeepers
- Test Managers
- Operations
Test and Production Deployment: Release Package is “Ready for Production”
To pass this quality gate a release package is successfully tested on a TEST environment.
This document does not make any statement regarding manual testing – be it scripted or explorative – nor does it contain guidance on automated testing performed by tools outside ServiceNow. Such activities for sure play a significant role to verify quality and should be conducted with great care and craftsmanship.
If any of these tests fail, however, defects must be reported to the development team. The Defect Management and Backporting procedures specify in detail what – besides fixing the defect – needs to be done and where.
The most important aspect in this quality gate is that only if all tests pass, only then the release package in the tested form can be deployed to production and considered as “Ready for Production”.
If there is at least one show-stopping fail, the responsible applications must be fixed and provided as new versions. This constitutes a new release package, and the tests must start over.
Checklist
- All tests have passed OR all failed tests are not considered showstoppers
- All identified defects have been documented according to Defect Management and Backporting
Relevant Building Blocks
- Defect Management and Backporting
Gatekeepers
- Test Managers
- Operations
Test and Production Deployment: Release Package is “Deployed to Production”
To pass this quality gate a release package must be installed on the production instance. This may include to make the newly introduced capability available to users, but it does not have to. In some cases, new capabilities are introduced in a silent go-live without visible impact on users.
Checklist
- All applications contained in the release package have been deployed to the production environment (in the required versions)
- All installation scripts of all applications have been executed
- All steps defined in the deployment instructions have been performed
- Smoke tests have passed
Relevant Building Blocks
- Source Code Repository
- Deployment Automation
Gatekeepers
- Operations
- Product Owners
Read the full story here:
https://www.wildgrube.com/download/A%20mature%20Development%20and%20Deployment%20Process.pdf
