Continuous integration, development, and delivery pipelines provide significant benefits to software development. An excellent example of this is “being able to shepherd code changes to production with little-to-no human intervention” like at Mozilla. More broadly, when properly implemented, they reduce time to market and provide greater transparency and reliability of new features and releases.
The question though is: when your pipeline is in active use, how can you regularly identify and remove any significant blockers that work against it being as efficient and effective as possible? I ask this because, like any business endeavor, it’s important to ensure that we’re continually improving.
However, despite being quite a technical and quantitative endeavor, it’s not always easy to know if blockers exist and where they are. As a result, it’s difficult to know how — and where — improvements are required. So over the course of this article, I’m going to help you identify some of the major blockers you may encounter and suggest a range of ways you can remove them by considering a series of questions.
What Is Your Company’s CI/CD Culture?
Before we dive into the technical aspects, I want to ask you about your business’s CI/CD culture. Is it a positive one, where everyone is fully engaged? Do they appreciate its significance on the company’s performance (and ultimate success)? Or are they only marginally aware that CI/CD exists, what it does, why it’s there, and whether it’s working?
As with any subject, the more engaged people are around a topic, the more supportive they’re likely to be. When they’re engaged and supportive, they can become ever more invested in that subject’s success. Its success becomes their success.
Furthermore, when this kind of clear-cut engagement exists, you’re less likely to encounter roadblocks when you need further resources to improve it.
This is reinforced by a report from PWC (Price, Waterhouse, Coopers) that says:
Culture is critically important to business success, according to 84 percent of the more than 2,200 global participants in the 2013 culture and change management survey…
It’s for these reasons that I strongly encourage you to consider your company’s CI/CD culture first. If it’s not an encouraging culture, then work to make it so.
How? Here are three suggestions:
- You can run group education sessions, where you highlight the existing benefits.
- You can bring in external experts to discuss real-world success use cases.
- You can hold regular webinars or group chats that show what’s going on and how it’s helping.
These are just a handful of ways. I’m confident you can think of others.
What Are Your Pipeline’s Metrics?
Now let’s consider more quantitative methods; after all, if you don’t know where you are now, you can’t know where and how you need to improve to get to where you’re going.
1 – How quickly can developers provision new environments?
Regardless of whether developers are new to your company, new to your department, or new to a given code base:
- How quickly can they provision new development environments?
- How fast can they go from zero to ready to work?
- How quickly can they throw away an existing environment (for any number of reasons) and start over?
One of the main advantages that CI and CD bring is the ability to develop new features quickly. If development environments aren’t able to be rapidly provisioned, then this is slowing developers down from being as productive as they can.
Is the process of provisioning a new development environment left up to each developer? Do they need to manually step through a checklist, running scripts, and locating dependencies? Or can an environment be automatically provisioned by a repeatable process, through using an industry-standard provisioning tool such as Packer and Ansible, Salt, Chef, and Puppet, or the newer container-centric tools, led by Docker?
2 – How quickly do tests run?
Testing is a tough area to discuss quickly because it’s such a rich and diverse topic. But it’s imperative that we do so! How long does your entire test suite take to run? Does it complete quite quickly, or does it drag on for hours — even days?
To be fair, there is no average runtime, as no two applications are ever the same. And I’m not suggesting that there should be, or even is, a standard minimum or maximum execution time. What I am saying, however, is that it mustn’t take unreasonably long. The longer it takes, the less likely it is that it’s going to be used and the more likely it is that developers will begin to avoid using it, if at all possible.
Given that:
- Where can you improve its performance?
- Are all the tests necessary?
- Have tests been written that don’t measure anything meaningful?
- Could tests be written more efficiently?
- Could resources be invested in improving the development team’s testing knowledge, whether through books, online courses, or bringing in outside experts?
Review the current test suites, whether unit, acceptance, integration, system, etc., and see how they can be improved. And consider investing further resources in ongoing testing education.
3 – How quickly are features deployed?
What’s the process by which your application, new feature, or bug fix gets deployed? Is it a process that’s organically grown over time into somewhat of a monolithic or convoluted mess? Could it be streamlined or simplified, whether by looking at it with a new set of eyes, bringing on people with dedicated experience, or employing new technologies, such as Docker?
Does legacy baggage exist, causing the process to run unduly long, perhaps because of an older version or set of features of the application that may no longer exist?
In each of these situations, look to see what can be pruned, removed, or improved.
!Sign up for a free Codeship Account
What Is Your Review Process?
In each of these three areas, don’t let it be a one-time affair. Just as you regularly engender continuous and never-ending software quality improvement in your team, so too should you also produce a strong spirit around your CI/CD pipeline. Schedule regular reviews after each major code release, alongside periodic intervals.
How Transparent Is Your Pipeline?
It’s one thing to have a pipeline in place, but how transparent is it? For example:
- Do you have the build, integration, and deployment metrics located and published in an easily accessible location, such as on a monitor in the development office?
- Is it easy to see when a build has failed and why?
- Is this information accessible to everyone?
My intent here isn’t to infer that someone within your organization might be dishonest or have questionable integrity. I say it because when the information is readily accessible, it brings several significant benefits.
These include:
- The ability to hold people accountable (such as when someone committed a change that broke the build).
- Group awareness of declining — and improving — quality standards.
- Positive affirmation of successful outcomes, such as new features and bug fixes.
As a result, I suggest that, if you don’t do it already, you should begin ensuring that you’re collecting as much information on your pipelines as possible. Then make that information as readily accessible, in as usable a manner, as possible.
Don’t just show the raw numbers though. They’re great. But they don’t always give proper context. Show trends over time as well. Make it easy to know whether the pipeline is improving or declining and why. That way, it’s easy(er) to know what action to take and when.
How Long Does It Take from Story to Feature Release?
Now that we’ve considered a series of areas in isolation, let’s step back and take more of a bird’s-eye view of the pipeline. How long does it take you to go from feature story to feature release?
What’s that process like? Is it a streamlined, well-documented, well-defined, and smooth process? Or is it more haphazard and hodgepodge? By viewing it this way, you can get a deeper, more thorough perspective on how it all fits together and how it’s working.
After you’ve reviewed the situation, consider these questions:
- Do you have a standard template for writing your stories?
- Do you have a standardized review and vetting process for them?
- How do you publish them?
- How long is it from when they’re written to when the feature has to be implemented (or abandoned)?
- Is the way that you’re writing your cards excluding some members of your organization — namely your developers? Said another way, do the cards contain unnecessary jargon, acronyms, or other insider terms?
- Are they overly complicated, taking too long to create, or attempting to do too much?
- What’s the reporting process from end to end? Is it effective and transparent?
This is just a sample of things you can look at. I encourage you to look at this process from end to end and see how you can simplify and, as much as possible, remove anything whatsoever that is unnecessary, that distracts, or that complicates the process.
Conclusion
While I’ve not always been as tangible, technical, nor as explicit as I could have been, I believe that these questions are a good starting point to help improve a CI/CD pipeline’s efficacy. If you jump in without either considering the process holistically or appreciating the key areas that need addressing, you run the risk of expending a lot of time and effort for minimal — if any — gain.
I hope that if you’re keen to improve the efficiency and effectiveness of your CI/CD pipeline that this post will give you a good start. Please take the advice as a jumping-off point, designed to stimulate your thoughts and efforts, one that you can build on over time.
It’s a profound and complex area, one that can’t be solved nor improved quickly or easily. But, when done continuously, improving on your CI/CD pipeline can return significant rewards in time, cost, and more.
| Reference: | How to Identify Major Blockers in a CI/CD Pipeline from our JCG partner Matthew Setter at the Codeship Blog blog. |
