ABCDF of DevOps
Usually when you look at diagrams that explain DevOps, they show few wheels that keep moving. This is what we can call, “code, build, deploy” cycle or sometimes called a CI/CD pipeline (CI: Continuous Integration, CD: Continuous Deployment or Delivery).
This looks simple as below that you need to be making changes to code consistently that will trigger automatic builds or the CI part, which in turn will trigger deployments or the CD part:
If you have seen the infinity shaped DevOps diagrams, you may be asking: “hey, where is Testing?”. My answer to that question is that it is no more a separate phase but is part of everything. The code commits ‘must’ have tests for changes; the build ‘must’ run tests and only passes if tests pass; the deployment is followed by some tests conducted in Production environment.
In addition to the above, these are some points for each of the wheels that I have seen/heard so far. Each of them calls for a separate post but wanted to sum up the whole here for now:
- Branching policy to manage multiple release
- Having a ‘Pull Request’ workflow
- Tests being inherent part of source code
- Peer Code Reviews
- Instant builds like CI
- Follow up builds that run additional tests e.g. Performance testing
- Builds only pass when all tests pass
- Developers own buildology rather than it being a separate team
- Manual vs. automatic deployments
- Testing in production
- Approval process
- Usage logs and monitoring
Many people when embark this journey of CBD cycle, they assume that everything will start working correctly as soon as they define a Build and Release pipeline. They discover soon that it is a bumpy ride and at times they become frustrated with this journey.
What I have experienced is that if you add two more letters to the story, you increase your chances of success significantly. These are A and F to make the picture as:
- Breaking your solution into small pieces that can be managed independently e.g. Microservices architecture
- Testability of system
- Test automation frameworks
- Tightening the feedback loop where Developer knows immediately when something fails
- Traceability on who broke what
- Ways to get feedback on how users are actually using the solution
That makes the plan ready which is “ABCDF” recipe for delivering quality with speed. And if any of the pieces is not ready, it may not work the way you expect it to.
Am I missing some other letter? How does your recipe look like?