In this second post in the DevOps series, we'll look carefully at the atomic unit of work in a DevOps system, the SW change.
A SW change is a set of additions, modifications and/or deletions on the code base of a single project. SW changes come in multiple sizes, but if your project adopts TBD (as it should), the smallest the SW change the better.
A day in the life of a SW change
From the developer desktop to the production infrastructure, a SW change makes a long trip traversing multiple stages along the DevOps system. But no matter how long that trip is, for benefiting from Continuous Deployment the trip should be completed in less than one day.
Let's describe schematically how a SW change spends a busy day in the DevOps system:
 |
| A busy day for a SW change |
- newborn: the SW change has just entered the DevOps system. Its gate into the system is the SW Version Control (SVC) service, e.g. git. Just arrived from its home town Developer Desktop, it makes a humble entrance as an anonymous citizen known only to his father, Bob Developer. But don't underestimate this small newcomer, it might potentially change the world!
- verified: as any newcomer to an organization, this new citizen must go through a safety check. Authorities need to make sure it's a sane individual, not carrying any harmful items or illnesses. Ideally, they would also try to assess what impact this newcomer might have on the organization welcoming it. Thus a number of checks are run on the SW change to verify its quality. The outcome of the checks is stored in a report in the SVC service. A copy is sent to the change's father, Bob Developer.
- merged: if the report carries a 'REJECT' statement, Bob must receive back his SW change and fix its weak points before the next attempt into the organization. If the report carries an 'ACCEPT' statement though, the responsible for approving newcomers is notified, and after a quick visual inspection the responsible (usually known as "the committer" in SW jargon) cheerfully grants the SW change access to the receiving organization as an approved citizen, merging it into the master branch of the project.
- staged: no matter how thorough the initial scan is, and no matter how smart the committer may be, there's no way of knowing in advance how will the new citizen behave and perform in its new home. Thus, before raising its status to first-class citizen, Authorities put the SW change under surveillance in a simulated environment for some time. The simulated environment should be as similar as possible to the real one, and the SW change should receive identical stimuli as it would in the real world. The name of this experiment is staging, and its goal is to reach a high level of confidence on the expected outcome of releasing the individual under surveillance as a free, first-class citizen to its receiving organization. During the surveillance lots of data and information about the SW change and the simulated environment status are gathered and attached to detailed reports, which are stored for reference. If the SW change passes this experiment it is tagged as candidate for first-class promotion. Otherwise is is rejected and sent back to its creator together with the detailed reports generated so any problems detected can be fixed before trying to enter the organization once more. Finally the outcome of the staging experiment is posted to the SVC service for reference.
- released: finally, after having passed all qualifications, the SW change is ready to become a productive first-class citizen in its receiving organization. The Authorities queue the SW change up for entrance to the real world, where it is received with joy by its peer citizens. What lies ahead for this SW change and the rest of the organization nobody knows yet, but at least the organization's Authorities can rest assured they did everything in their hands to maintain a healthy, productive, useful organization making the world a better place.
The SW change should traverse all those states as quickly as possible, and in any case in less than one labor day. The owners of the DevOps system play the role of the Authorities, and must strike a balance between safety and time, guaranteeing that as many checks as possible are performed on every SW change within the available time before releasing the SW change into production, where the impact of an undetected problem is much wider (potentially unlimited!).
Conclusion
In this post we have looked at how the ideal DevOps system should handle the atomic unit of work in the system: one SW change. It's useful to keep in mind that model in order to be aware and estimate the impact of your deviation from the ideal system.
For example, your safety checks may take more than one labor day to complete, in which case you're likely unable to introduce SW changes to the production environment one at a time. That in turn means you need to gather as much data as possible from that environment in order to easily pinpoint the liable cause of a problem detected after a batch of SW changes have been released into production. Fixing you safety checks will take you closer to the ideal model hence more able to gather the benefits of the DevOps practice.
For example, your safety checks may take more than one labor day to complete, in which case you're likely unable to introduce SW changes to the production environment one at a time. That in turn means you need to gather as much data as possible from that environment in order to easily pinpoint the liable cause of a problem detected after a batch of SW changes have been released into production. Fixing you safety checks will take you closer to the ideal model hence more able to gather the benefits of the DevOps practice.
