Continuous Delivery is a collection of methods and ideas that enables organizations to securely and often deploy code to production. When most people think about CI/CD tools, they are thinking of a much narrower scope.
From Continuous Integration, testing, and architecture to application deployment pipelines, configuration management, and infrastructure management, it covers it everything. It goes on and on. These aren't things that can be accomplished just by putting in place the appropriate toolchain.
If you want a thorough understanding of CI/CD, Humble and Farley's Continuous Delivery is certainly worth reading.
Continuous Integration and Application Deployment pipelines are covered in the book's second section. This subset of Continuous Delivery is the one that most people identify with CI/CD tools, therefore I'll concentrate on it here.
Act now, rather than later :
CI/CD enhances performance in a variety of ways. It's not simply about adding new features; the value and reach extend well beyond that. In the digital economy, the capacity to deploy code (or infrastructure) fast, safely, and consistently is critical. This capacity will hold your company behind if you don't have it. Worse worse, it may put you at unnecessary risk.
Failure to implement CI/CD is more costly than having to modify or pivot later if you discover that an alternative toolchain is better suited to your needs.
There is no such thing as the ideal CI/CD toolchain for your present and future needs. Most likely, it will never happen. However, you must continue to work on developing these qualities. Our experience assisting organizations in adopting DevOps practises has shown that CI/CD enhances IT performance, which in turn improves organizational performance. This is evidenced by the yearly Accelerate State of DevOps Reports. Elite DevOps performers were twice as likely to meet or exceed organizational goals such as profitability, productivity, and market share, according to the 2019 study.
A platform solution, perhaps?
CI/CD implementation will very certainly necessitate the use of many tools. There's also a lot of talk about employing a platform approach, with a centralized team providing the tooling as a service. Larger teams can utilize the offered technology or choose their own if it doesn't match their needs (within agreed parameters).
The idea behind this is because the customer-centric platform team tailors its product to real-world requirements, making it more desirable than other choices. As a result, larger groups are gently discouraged from picking their own tools, which would increase responsibility, complexity, and cost.
This is, nonetheless, a highly mature worldview. It undoubtedly symbolizes a goal that most businesses should and should pursue.
However, there are easier ways to get started with CI/CD for organizations that are just getting started.
Choose the finest choice for the time being :
Delay means falling behind in today's fast-paced world. This is exactly what occurs when the fear of making a mistake paralyses the CI/CD toolchain decision.
Considering tooling decisions objectively and holistically may be really beneficial:
Recognize your present needs; don't strive to solve tomorrow's difficulties today.
Have a tooling amnesty: find out what's been deployed beneath the radar or in skunkworks initiatives to get a full picture of what's being utilized now. You might be amazed at the degree of knowledge currently present in your company.
Speak with the users of the tools to ensure you understand their requirements.
When it comes to tool selection, the Accelerate State of DevOps 2019 study emphasises the importance of "usefulness and ease-of-use."
Recognize your exit strategy. If you keep your eyes open and know how much it would cost to reverse the choice, vendor lock-in can be acceptable.
Note : To the CI/CD tooling question, there may not be a simple 'correct' answer. However, following these guidelines might help you make the best decision for your company.
Top comments (1)
So true. I have seen it happen where a team member watched some video or attended a workshop on a tool that does X, Y & Z and jumped into setting it up for the project without understanding if there's a need for a tool in the first place.
First recognize the problem/need, then identify the right tool (with a bit of trial and error process).