Why Most Companies Are Getting Continuous Delivery Wrong
Why Most Companies Are Getting Continuous Delivery Wrong
Most people think of tools like Jenkins and Ansible when they think of CD, when really the people and culture should come first.
Join the DZone community and get the full member experience.Join For Free
Don’t let inefficiencies in software testing lead to delayed deployments and poor quality products. Get the 90 Days to Better QA Guide by Rainforest QA for best practices to avoid these common pitfalls.
What springs to mind when I say the words Continuous Integration (CI) and Continuous Delivery (CD)?
You’re probably already thinking of popular tools and systems that enable these processes, such as Jenkins CI, Ansible, CruiseControl, or Bamboo, and wondering how to integrate them so you can proudly say that your organization has a fully operational CI/CD process.
A few months ago, I attended a meetup at a large organization to learn how they implemented Continuous Delivery processes. They had spent a lot of time building the process in their organization — and they wanted to share the knowledge. I sat there for nearly two hours as they talked about all the tools they implemented and how they built the processes around them. It was only when I got home that I realized that I had wasted my time.
We tend to spend a lot of time talking about the tools required to ensure a successful Continuous Delivery process — and not enough focusing on other critical elements. Don’t get me wrong, you simply can’t have a Continuous Delivery process without automated tools and systems — but there’s more to it than that.
The tools are vital. But they come second.
Why Continuous Delivery Isn’t Just About the Tools
If you’re looking at the tools without first thinking about the people and the company structure, your Continuous Delivery process is never going to succeed. Here’s why:
Each Department Has Its Own Needs When It Comes to CD
Every team (or person within a team) has their own aims, needs and perspectives when it comes to implementing a continuous delivery process — and these don’t always match the rest of the company.
Often, especially in large organizations, teams work in silos. When there’s little or no connection between the teams, you’ll often find that each person implements the CI or CD tools solely from his or her own perspective. In other words, they take the tools and tailor them to suit their own needs.
When you have this lack of coordination in a company, the consequences of such siloed actions are clearly reflected in their CI and CD tools.
When you focus on the tools before you think about coordinating the teams, it naturally leads to a situation where you have many individual builds and tasks created to solve specific issues that aren’t part of the wider picture. When this happens, in the long term, you won’t even remember or know who created the builds or tasks or why they created them in the first place.
For example: try taking a look in your Jenkins Jobs and seeing how many of them are actually used. Or take a look in your Ansible playbook. Can you really understand the aims of each role and playbook? How comfortable do you feel running something in production that you didn’t create? On top of that, the person that needs to use these tools will have to devote a lot of time and energy to understanding and fixing issues.
You Need to Think About the Process — Not Just the End Result
There’s a reason the word “Process” almost always comes after the terms Continuous Integration and Continuous Delivery.
When you think about the tools before the people, you’re going straight to the solution - not the process. You’re jumping straight to the end of the line without planning and implementing the process that will ensure its success.
For Continuous Delivery — People Come Before the Tools
It’s important to understand that you’re going to implement a process using the tools - not the other way around. It’s crucial to understand the process and combined requirements of the organization before trying to fulfil the technical requirements.
Appoint a Continuous Delivery Engineer
To ensure a fully coordinated approach, you need one key person to ensure that everybody — be it developers, devops or QA — is on the same track. This person is central to the organization and to your success in establishing a Continuous Delivery process.
The Continuous Delivery Person/Engineer will take the time to understand the requirements of each team and what they require from their tools, taking into account common threads or dependencies between the departments. This individual can then plan and build one ideal process that merges all the combined needs of each team in the organization.
Tips for the Continuous Delivery Engineer
Establishing one ideal process to “suit all” isn’t an easy task — but it is possible.
If you’re taking on the role of Continuous Delivery Engineer, here’s how I recommend approaching this mission:
Try dividing your tasks into small and independent deployment units, similar to a Microservice Architecture — so that you can reuse them for different processes or connect them to others when needed. Remember “The Incredible Machine” game, where you had to assemble different parts of a complicated machine to solve a simple puzzle?
This is a similar idea, you can’t just take the objects and put them on the map. First you need to understand the task and review the objects you have. Once you’ve done all this, then you can put them all together on the map and hit the “Play” button. It’s exactly the same in Continuous Delivery. First you must understand the processes and correlations between the teams as well as your ultimate goals. Once you’ve done this, then you can move on to the tools and finally hit the “Play” button. When done correctly, you can be sure that hitting the “Play” button will cause the balloon to explode - or for your software to deploy continuously and flawlessly.
Continuous Delivery Success: 5 Things to Remember
Establishing a successful Continuous Delivery process in your organization is within your reach. Just remember these five points before you get started:
- Focus on the process before the tools
- Understand the needs of each team
- Build one process to merge the combined needs of every team in the company
- Implement the tools
- Appoint a Continuous Delivery Engineer to manage all of the above!
Good luck! If you’d like to learn more about establishing a Continuous Delivery Process in your organization, take a look at our on-demand webcast on shifting your application testing into the Continuous Delivery Age. View it here
Please also share your comments.
Published at DZone with permission of Jason Silberman . See the original article here.
Opinions expressed by DZone contributors are their own.