At the recent WinOps event, several people asked me how to select toolchains for CI/CD. It’s not an easy question to answer, and if you’re familiar with Xebia Labs’ Periodic Table of DevOps Tools you’ll understand why.
The range of options is so immense and there are so many routes you could take. How do you decide, and what happens if you get it wrong?
Before you get caught in the analysis-paralysis trap, it’s useful to revisit the definition of CI/CD and the rationale for using it.
Why use Continuous Integration / Continuous Delivery anyway?
Continuous Delivery is a set of practices and principles that allow organisations to deliver code to production safely and frequently. This is a far broader remit than most people have in mind when they talk about CI/CD tooling. It covers everything from Continuous Integration, testing and architecture, to application deployment pipelines, configuration management and infrastructure management. The list goes on. And these are not things that can simply be achieved through implementing the right toolchain.
Humble and Farley’s Continuous Delivery is well worth a read if you want an extensive explanation of CI/CD. The second part of the book covers Continuous Integration and Application Deployment pipelines. It’s this subset of Continuous Delivery that people generally associate with CI/CD tooling, so it’s what I’ll focus on here.
Act now, not later
CI/CD improves performance in multiple areas. It’s not just about delivering new features, the value and scope go much further. An ability to deploy code (or indeed infrastructure) quickly, safely and repeatably is of vital importance in the digital economy. If you don’t have this capability, it will hold your organisation back. Worse still, it could expose you to an inordinate level of risk.
Failure to adopt CI/CD is more damaging than having to adapt or pivot in the future if you find that a different toolchain is better suited to your needs.
The perfect CI/CD toolchain for your current and future needs doesn’t exist. In all likelihood it never will. But you still need to progress with development of these capabilities. Our years helping organisations embrace DevOps ways of working show that CI/CD drives better IT performance, which improves organisational performance in turn. The annual Accelerate State of DevOps Reports bear witness to this. In the 2019 report, elite performers in the DevOps space were twice as likely to meet or exceed organisational goals including profitability, productivity and market share.
A platform solution?
For organisations looking to implement CI/CD it is likely that several tools will be needed. And there’s lots of talk about using a platform model, with the tooling provided ‘as-a-service’ by a centralised team. Wider teams are free to use the supported tooling or, if it doesn’t meet their needs, choose their own (within agreed parameters).
The logic behind this is that the customer-centric platform team gears its offering towards real needs, making it more appealing than alternative options. So, wider teams are gently dissuaded from selecting their own tooling which would incur additional responsibility, complexity and cost.
However, this is a very mature view of the world. It certainly represents an end state that most organisations could and should strive for. But for organisations at the beginning of the CI/CD journey, there are simpler ways to get started.
The Azure DevOps option
If you simply don’t know where to begin with CI/CD, Azure DevOps might be the answer you’re looking for.
It’s not just for .NET applications running on Windows, but supports any language running on any platform and deploying to any cloud. It doesn’t force you to commit to a single vendor either. As an orchestrator, it allows you to retain the tools that work, replace those that don’t or introduce those that are missing.
A bugbear for organisations switching tools is the need to rebuild or reimplement working functionality. This is eradicated with Azure DevOps, because you only focus on addressing pain points. You don’t need to rip and replace the things that are working.
Nail the best option for now
With today’s rapid pace of change, to procrastinate is to fall behind the curve. This is exactly what happens when fear of getting it wrong puts a stranglehold on the CI/CD toolchain decision.
An unrealistic desire to pick one vendor which provides tools across the entire software release pipeline further complicates matters. Yes, tool sprawl is a problem which impacts security and consistency. We need to be mindful of this. But we also need to be pragmatic.
Taking an objective and holistic approach to tooling decisions can be hugely beneficial:
- Understand your immediate requirements – don’t try to fix tomorrow’s problems today.
- Have a tooling amnesty: find out what’s been deployed under the radar or in skunkworks projects to build a complete picture of what is currently being used. You may be surprised at the level of expertise already held within your organisation.
- Speak to the people who use the tools to ensure you understand their needs. The Accelerate State of DevOps 2019 report places great emphasis on the need for ‘usefulness and ease-of-use’ when it comes to tool selection.
- Shortlist your tools, decide on your criteria and timebox the decision – this creates a framework to move forward.
- Understand your exit strategy. Vendor lock in can be OK providing your eyes are open and you know what it would cost to reverse the decision.
There may not be a straightforward ‘right’ answer to the CI/CD tooling question. But taking these steps can ensure you make an appropriate choice for your organisation. It means you can make the best decision today, knowing you can change your mind if circumstances shift tomorrow.