Confident CI/CD: How to Successfully Achieve Continuous Integration
Continuous Integration and Delivery, or CI/CD, is a trend that I believe is here to stay. In the Software world, we need to deliver code quickly and reliably in order to stay ahead of the game. As this is said, however, a reality settles in.
Often within this culture, we will begin to find deficiency and inefficiencies that creep up. A traditional Water Flow release schedule is often pushed down to enforce schedules of multiple organizations within the business. Other models of code development start to bubble up. Agile development, a modern software take on the Lean Manufacturing technique, is a common implementation. The fact of the matter is that, at the end of the day, however we decide to release software and write code, our processes are tailored around one unspoken variable, an attempt to control the inevitable. We are trying to be confident that we won’t break things for our customers.
How we deal with this, is ultimately how we end up releasing code. If we use the disguise of large entities, and we believe ourselves to be “too but to fail”, meaning, we have a culture of “we can’t release a bug”, then ultimately we will achieve a maximum output and we will not be able to progress further. We might break up our organization to make things in smaller chunks under the guise that we did something revolutionary, but ultimately, we will achieve a maximum output and we will not be able to go any faster.
If instead of focussing on the bugs, we focus on the Confidence of the Customers, the Developers, and the Business, then we will begin to discover the differences we need to make to better change our processes for the current day.
CI/CD is not a tool
Contrary to many in the industry will have us believe, CI/CD is not a tool. A successful implementation will be a change in culture and process. CI/CD is a revolution that will change our business from the bottom up. We cannot start down the road without changing our lifestyles and processes. If we do it wrong, we will be more rigid and ultimately fail. If we do it right, it can set an organization free.
So how can we start? We start by analyzing our workflow.
Look for Confidence Insufficiency
As we start looking at our workflow. Look for things that we often ask and never know. These might look like:
- What is being released right now?
- Go / No Go meetings
- QA blaming and Bug shaming
- Lack of development testing
- Reliance on QA to run the release process
- IT frustration with the current release process
- Ineffective 1 on 1 meeting schedules
- Inefficient feature release times
- Too much focus on Deadlines
Each of these can be indicators of a lack of confidence within an organization. When there is a lack of Confidence, then often things are stuck and not moving forward. We all need Confidence in what we do, in order to move forward and take action. Let’s look at these and why they are indicators.
What is being released right now?
This is kind of obvious as this statement is not confident, just by it’s nature. What it really means, however, is that because of the lack of confident, not knowing what is being released, will always result in over testing and bugs slipping in. We think we may have tested right, but not knowing, just means we have a higher risks we are introducing to our organization.
Go/No Go Meetings
If you have been reading my articles for a while, you know I don’t like these. A Go/No Go Meeting is a try to gather the troops and have product solidarity. QA runs the meeting. Stake holders go around and say whether they should go, release to production, or not. What ends up happening is QA days they are still testing and pending their tests they are ready. The others say if QA says so, then they are a go. When there is a failure in the process, blame falls to QA. It is a scapegoat process to allow for assumed responsibility. It unfair and ineffective.
QA Blaming and Bug Shaming
QA has a lot to do, but being responsible for bugs is not one of them. When an organization is blaming and shaming QA for not finding a bug, then that indicates a lack of ownership and responsibility for ones actions. Often, this is the number one reason why CI/CD fails.
Lack of Development Testing
If there is a lack of Unit Testing in an organization, there is a lack of Confidence in the organization. This often manifests itself in incomplete work, over estimates on work, and under delivering features, most often excused as “Minimum Viable Product”. Unit testing is a great way for the developer to prove and review that the code is behaving according to spec. We may not get it right every time, but often, we don’t have to revisit things as we do without it.
Reliance on QA to Run the Release Process
This one may not so obvious. The release is a product of all people’s involvement. When we hand this off to QA, we end up not empowering them. We think we do, but ultimately it is a facade. We need someone empowered to make decisions and drive excellence. QA might be able to, but until their role doesn’t involve covering for other’s mistakes, we need someone else.
IT Frustration With the Current Release Process
This looks like IT being on call and awoken multiple times a week by something that went into production. It looks like isolation and grumbling. When IT doesn’t have a stake in the release, then confidence wains and frustration abounds. This subtly becomes the same as QA. IT is responsible for the infrastructure but often is given the responsibility to ensure no down time, when often, application failure is due to the code misbehaving. They need to be a first class citizen. Allow them to own what they should.
Ineffective 1 on 1 Meeting Schedules
This might seem like a weird one. When we have meetings with managers where in they are just catching up, often on a weekly basis, this indicates that there is a lack of confidence in ability and or ownership. Allow people to own what they should. Don’t have a meeting to just have one weekly. Treat time and resources with respect and have a purpose in what is done. Be truthful and up front. Approach people with respect and don’t beat around the bush.
Inefficient Feature Release Times
Often, when we are not very confident, we lengthen our time between releases to production. This is a bi-product of a lack of confidence. Accept failure. Embrace it. Focus on how to be confident and keep going. Don’t give up! And don’t release fewer times indefinitely. If you need to hold off a release, then do it. If we make release schedules longer, then the impact of not releasing becomes more urgent and hectic and Confidence is lost and things spiral out of control.
Too Much Focus on Deadlines
If the deadline is more important than the code quality, then Confidence is gone. This often bubbles up as a last minute MVP (Minimum Viable Product). To overcome this, focus on the work, not the deadline. Don’t run and manage work by the deadline but rather by the work.
Conclusion
These are all ways that over time, when implementing focus on confidence, organizations can ultimately always grow and CI/CD can be implemented effectively and successfully.
