As practices intended to accelerate and de-risk software development, it’s perhaps ironic that there is no single fast, safe way to move to Continuous Integration and Continuous Delivery.

These approaches – usually referred to jointly as CI/CD – are well-known in the development community. By using CI tools to build code as and when commits are made and CD tools to automate testing and deployment, businesses can reduce the time, effort, and risk involved in the path that code takes from a developer’s mind to its production environment.

Once properly configured, these tools effectively turn a long list of disparate tasks into a domino run. Rather than having engineers shepherd new code through the various steps involved in building, testing, and deploying – with all of the infrastructure and compliance management labour which goes along with them – a code commit becomes a trigger for the full sequence of necessary events.

Thinking beyond the tool

There are now any number of software options that can be used to implement CI/CD, from the grandfatherly open source solution of Jenkins to options from disruptive providers such as Gitlab and enterprise packages such as Atlassian Bamboo. Selecting between these competing paths towards CI/CD can quickly come to seem like the central challenge for development teams looking to accelerate their production – and this article could take on the task of a comparative analysis of the major options.

There is a real risk, however, that focusing on identifying the ideal CI/CD technology means failing to see the wood for the trees. Even as CI/CD establishes domino effects within the development lifecycle, it has ramifications that go well beyond the software environment.

Instead of being something that you can buy off a shelf, a successful enterprise grade CI/CD solution requires the undertaking of significant organisational change, including transformation across areas as diverse as people, process, culture, and tooling as well as technology. It is my experience that enterprises frequently underestimate the impact that implementing CI/CD can have, especially for legacy or existing applications. There are, therefore, questions you need to ask which are at least as important as picking a software offering.

Coping with computational demands

Let’s take physical infrastructure as a first example. In a simple scenario, implementing CI might mean increasing the build server’s workload from one to ten builds per day. Do you know that the server can execute builds at this rate, and how it will react when multiple developers commit code and builds queue up?

Even if the server does have sufficient resources, each of those builds will need to be stored in an artefact repository, creating a significant additional storage demand. Meanwhile, it is also likely there will be an increase in the load for unit test execution. If a unit test cycle takes, say, three hours, are you certain that those cycles can be executed at a higher rate than new code commits and avoid a growing backlog of necessary testing?

These issues intensify when the pipeline matures to include CD. Beyond unit testing requirements, the functional and performance testing processes required for application deployment themselves commonly run for hours or even days. As resource needs multiply – and teams acclimatising to CI/CD begin to commit ever more frequently – it becomes necessary to automate not just delivery but the provisioning of net new infrastructure. Here, teams will find the remit of continuous methodologies growing to include Change Configuration Automation (CCA), ensuring that appropriate environments are available in a system that can react to periods of higher demand.

Managing CI/CD

This brings us to the second example of knock-on effects that teams might not foresee: organisational management. With CCA supporting the CI/CD workflow, development and testing teams will be provisioning their own infrastructure, perhaps using virtualisation, containerisation, or cloud systems. This raises several financial and legal issues that need to be accounted for prior to introducing CI/CD.

Is there a budget in place to address the increased costs of new system instantiation and ongoing support? Are there licenses available to run several new systems in parallel? Are there policies in place to decommission systems that are no longer needed while maintaining audit needs? Failure to attend to these adds cost and risk, undoing benefits which CI/CD is meant to introduce.

The managerial questions extend further in organisations where multiple development workflows operate alongside one another, with varying degrees of interdependency. If two or more applications need to be delivered to end-users in series or in parallel, due to the nature of the dependencies between them, how will CI/CD account for that? How flexible will it be if some of those applications are employing more traditional delivery models? And how will it sit in the context of formal change governance models which are umbrella across several applications?

Keeping the human in mind

Thirdly, and as in any transformation exercise, it is vital not to forget the human at the heart of all of this change. The short-scale feedback loop of CI/CD, testing and verifying code at each commit, can generate a satisfying sense of progress and achievement even as it alerts teams to potential issues earlier in the cycle.

Yet, the flip side of developers pushing commits which point back to them several times a day is that if and when they do fail, it can quickly start to feel like being put on a wall of shame. This is just one example of how the culture shift can add demotivational elements to the workflow. A reworking of overall quality metrics may also need to be considered, ensuring that later defects issued against the build and peer review of code continue to be measured alongside immediate statistics on build success or failure.

The path to success

The good news amongst all of this is that, while there are many complicated questions to respond to in order to successfully introduce CI/CD, there are also many people who have already been on that journey, and consulting with experienced providers will help to highlight likely issues and the most productive solutions to them.

Ultimately, due attention to tools, management, and counsel will help you arrive at a position where you’re ready to push the first domino in your CI/CD system.

Written by Julian Fish, director of product management for SCCM and Application Release Orchestration, Micro Focus