Level Set of Terms
Before we dive into today's blog post, let's get familiar with these terms:
- DevOps: A mix of cultural and technology practices to improve the use of software and technology-servicing customers.
- Continuous Integration (CI): Traditionally, a developer spends their day coding, and at some point, they save (commit) their efforts within a development environment or an application branch. Think about a tree. Do you want one full of intertangled branches (loads of developers, all doing something, but getting in each other’s way), or do you want a well-balanced tree with a solid trunk? The same is true with coding, and CI allows for the integration of code to the trunk as fast as possible via agreed testing success. If the system fails (a diseased branch), then the feedback is fast enough that the code can be fixed and resubmitted. Note that the approval and commit steps are manual but the expectation is that they are performed daily at a minimum.
- Continuous Delivery (CD): Removes the manual step and introduces automated approval based on testing success to push software to the trunk. CD eliminated the authorization wait time found in CI, thereby decreasing the feedback time. Faster feedback equals faster fixes, which underpins the culture of “if no defect found, then proceed to the next step in the software value stream.”
- Continuous Deployment: I call this the ‘Trust My Developer’ process. Testing, packaging of code, release, and deployment (to the correct trunk or environment) are as automated as possible. We trust the process, the tools, and the quality of the code, and therefore we know that if there is an issue, we can also remove any code causing problems as quickly as possible. Feedback from the customer on the new applications or features is immediate.
How we created these practices: A bit of history
Software is what makes technology exciting, as it is often the software elements that make things happen, solve problems, or fulfill needs. It stands to reason then that the flow of software to a customer needs to be as fast as possible. Unfortunately, in many businesses today, that flow is a mixture of work, wait time, approval time, and probably rework.
Does your software stream look like this?
- Receive the request for something to be changed (new, feature or fix)
- Wait
- Get it approved
- Wait
- Pass it to a team as something to do
- Wait
- The team at some point begins to work on it
- They finish their work and pass it to another team to add their code, or they give it to a test team
- Wait
- The test team schedules the environments for testing: code, security, performance, business continuity
- Wait
- After authorization, the code is deployed at the pre-set monthly or quarterly release
- Wait
- The code is released
- Pray that it works and that things have not changed so much since the original request
Do you recognize your lengthy cycle of innovation? It doesn’t have to be this way, thanks to the practices of DevOps: Continuous Integration, Continuous Delivery, and Continuous Deployment.
Timewarp to today
What do your staff or customers want? Quality, fair cost, sustainability, resilience, and practicality. They want technology that helps them and, preferably, they want it now. Given the interconnectedness of the world, if a customer does not find satisfaction with you, then they go elsewhere within a mouse click. Your business peers can also do the same, hence this is how Shadow-IT (when peers circumvent formal IT processes) begins.
But what if:
- Requests are assessed within a short time of receipt?
- When the team began working on the request (either some aspect, if not the full request), was ready it for use within a sprint (two weeks to a month)?
- As much as possible, the culture is that if no defect is found, the request moves to another team or goes live?
- If the request can be improved, then how?
Jez Humble and Dave Farley best explained these practices in their book Continuous Delivery. Major software vendors such as Atlassian built their products based on these concepts (and have an excellent series of blog posts showing the why and how). It is becoming more and more difficult to find a business that does not depend on software, so why have processes that limit the use and improvement of your products or services? Sounds like nirvana (or a significant culture change).
Some of you by now are thinking that this can never happen where you work. I won’t quote how many times a day banks, Amazon, or even the latest start-ups that were born during the pandemic, deliver software to customers.
Tip: Look at sites from mature DevOps companies like Netflix and Amazon, and make that your goal so that you can work towards creating meaningful change within your organization.
The CICDCD+ culture:
- No defect goes live
- No defect goes to the next environment
- Ideally have no more than three environments; two is even better
- Automate as and when we can
- Test multiple times, as often as we can
- Trust in the tools we use
- Trust in the people that use those tools
- Ability to roll back (uninstall code) as quickly as we can promote code
- Limit the amount of work performed at any given time
- Limit the size of our changes (make smaller changes?)
- Changes are independent of the application or data (yes this is hard)
- Every day is a new day during which we strive to improve the process
The Gap of Change: Are you ready?
CI implies that your organization wants to create and improve a pipeline of software to your customer. You also agree that management is going to allow the technology and governance processes to be available to develop, maintain, and improve the pipeline. CD also implies that you are satisfied with the flow of software, the timely feedback of information related to software value, and issues are resolved before working on other code. Automation is used to automate the approval of changes and the delivery to the appropriate environments or customers.
CD+ implies that you are content with both the culture and technology of software and how development and deployment have matured. You are ready to automate as much of the process as possible. Changes are small and independent enough that if there is an issue, they are quickly revoked. Minor changes also mean that customers get spoon-fed new software, one feature at a time. Documentation and recovery are both simplified, and the cost of software reduced.
Remember that there is no value in anything you do in technology until it is used to help someone fulfill a need or solve a problem. Until that time, everything you do or spend money on is a waste. Limit your waste by trying these practices. In the next blog, we will explore the metrics of CICDCD+, and the final blog of this series will provide tips from the leadership aspect.
If you have any questions in the meantime about any of the concepts discussed in this post, let us know
smooth running production environment is a beautiful thing. But how do we get there? And how do we ensure that all of our production, staging/test, and development environments stay in sync in order to get there? Today, it seems like everyone in software development is talking about Docker and containers. In fact, according to the 
