Why Unit Tests Aren’t the Only Answer to Continuous Delivery – InApps Technology 2022

Cloud Foundry sponsored this post.

Enterprises must review their internal processes and rethink how they approach software delivery lifecycles to make continuous integration and continuous delivery (CI/CD) a reality. The checklists and reviews of yesteryear are simply not the way forward. The hard truth is the majority of enterprises are quite behind on the journey to continuous delivery. It’s a difference between making fundamental changes to the software delivery process itself vs. half-steps like grabbing some tools off the shelf.

If the goal is to be more responsive to customers and users, software teams need to focus on a faster iteration of the software delivery cycle and to organize themselves around rapidly responding to user feedback. While there may be proxy metrics like the number of releases per month, the best measure of success in adopting continuous delivery is to track the time from feedback to updated software.

But if you just do it in a patchwork, you’re not going to get to the goal.

It’s tempting to look at something incrementally and understand how an organization can get from where it is today to where it wants to be. While I think that’s always the right approach, enterprises taking only the first steps shouldn’t fool themselves into believing they have gone far enough.

Don’t Fixate on CI/CD Tools

Often, teams start with CI by just automating the build process with some automated unit tests. That’s a great start, but don’t spend too much time fixating on charts of how many lines of code have unit test coverage. Instead, enterprises should focus their automated testing attention verifying the core business processes, user transactions and user interactions to make sure they’re all still functioning as expected and required for the business to operate effectively.

The next level of sophistication in CI/CD strategy — but one that is also a mistake if enterprises stop here — is a tendency to bundle up a large number of changes that are scheduled on a quarterly basis. Effectively, CI becomes a point where companies pause their efforts. CD, on the other hand, is all about getting changes through the pipelines and into production as frequently as possible. Once an enterprise understands how users will be impacted by code changes and automates how those changes will be implemented, it needs to drum up the courage and wherewithal to push those changes through.

Oftentimes, even if an organization is pursuing CI/CD, it fosters a mindset that views change as a risk. This inevitably leads to the belief that changes should be made less frequently. That’s the exact opposite of continuous delivery and it halts an enterprise’s ability to fully embrace CI/CD.

Smaller changes inherently carry less risk, which means a highly productive software organization should be able to move faster. The concept and promise of continuous delivery hinge on an enterprise’s ability to constantly deploy small changes. Moreover, it necessitates a widespread expectation that releases will occur frequently.

Scope Software Changes Accordingly

Businesses that go into this purely with the old way of thinking — CI tools, unit and acceptance tests — still aren’t achieving any real benefit. The scope of changes that an enterprise is deploying should serve as a guideline for the level of quality issues it can endure in the software development lifecycle.

Another common problem occurs when an organization decides to break things up into small changes, but still has a series of meetings, change control boards or strict security checks that development teams have to go through. If your organization’s goal is to move faster by deploying smaller change stacks, it won’t go anywhere until it comprehensively rethinks its internal formalized approach to release cycles.

Organizations that operate in heavily regulated sectors, such as government agencies, must overcome these challenges by making the changes and necessary documentation part of the product they are releasing. Those organizations outside of the government sector can follow their example to overcome documentation requirements by making changes to the software and describing how those changes will impact users within the markup version. A great example of this in action is how the US Government’s cloud.gov team programmatically generates documentation, like their system diagrams.

Instead of taking input from anyone who has an opinion about whether software should be released, businesses that want to be successful at CI/CD have to find a way to codify that opinion into some kind of automated test that can be accomplished quickly. Otherwise, every manual step on that path will just push those deliveries further down the line.

How Organizations Can Attack the Issue

Too many businesses are stuck somewhere in the middle — they have various tools in place to allow some of these practices, but internal processes, checklists or decisions under the purview of management are precluding the organization from releasing updates at a regular cadence.

A large number of developers are stuck in these software development cycles that are either not even attempting CI/CD or embracing an artificial version of it by fixating on tools, tests and automation.

There’s two ways organizations can break apart the problem. One way is to start by getting a CI/CD tool and empowering your various developer teams to begin using a common build service on an enterprise-wide level. The other approach is to identify the developer teams that would benefit most from higher velocity, smaller changesets and allow the insights gained from that experience to percolate throughout the business.

I think the latter model works better in most instances because the number of people involved is kept to a minimum and parts of the IT organization that are more concerned with compliance and audit will have greater flexibility to understand what’s occurring within the scope of a single application. Enterprises should be much more comfortable with the idea of experimenting with one application and one team rather than trying to push the entire company to make the shift in unison.

The goalposts of CI/CD are always moving and that’s by design, but rest assured that your organization will know it’s starting to achieve the goal of CI/CD when all of the teams that can benefit from faster delivery are realizing those results.

Feature image via Pixabay.