Non-Technical Preparations for Implementing Continuous Delivery
:: By Roee Rakovsky, BlazeMeter ::
When you first hear the words Continuous Integration (CI) and Continuous Delivery (CD), it is typical for popular tools and system enablers to come to mind, such as Jenkins CI, Ansible, CruiseControl or Bamboo. What also comes to mind is how to successfully integrate them into the enterprise, to be able to fully embrace the technologies. These are the aspects of integration that are most often discussed, but are they really the most important aspects of the implementation, and the ones that we should be spending the most time talking about?
A lot of time is spent talking about the tools required to ensure a successful Continuous Delivery process - and not enough focusing on other critical elements. While you simply can’t have a Continuous Delivery process without automated tools and systems, there is more to it than that – the tools are vital, but they come second.
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 CD process is never going to succeed. Here’s why:
Each Department Has its Own Needs
Every team has their own goals, needs and perspectives when it comes to implementing a CD process - and these don’t always match the rest of the company because especially in large organizations, teams work in silos. When there’s little or no connection between the teams, it is often that each person implements the CI or CD tools solely from his or her own perspective; they take the tools and tailor them to suit their own needs. When there is this lack of coordination in a company, the consequences of such siloed actions are clearly reflected in their CI and CD tools.
When the tools are coordinated before the team is coordinated, it naturally leads to a situation where there are many individual builds and tasks created to solve specific issues that are not a part of the overall task at hand or strategic picture. In the long term when this happens, you likely won’t remember or know who created the builds or tasks or why they created them in the first place.
For example, take a look at your Jenkins Jobs and to see how many of them are actually being used. Or take a look in your Ansible playbook, to check to make sure each role and the goals of it are really understood. Make sure to check to see how comfortable developers feel running something in production that they didn’t create. Additionally, keep in mind that the person that needs to use these tools will have to devote a lot of time and energy to understanding and fixing issues.
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 the tools are thought of 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. But for Continuous Delivery, people have to come before the tools.
It’s important to understand that you’re the process will be implemented using the tools - not the other way around. It’s crucial to understand the process and combined requirements of the organization before trying to fulfill the technical requirements.
Appoint a Continuous Delivery Engineer
To ensure a fully coordinated approach, it is recommended to have one key person to ensure that everybody - be it developers, DevOps engineers 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 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” is not an easy task - but it is possible.
If you’re taking on the role of Continuous Delivery Engineer, here’s how it is recommended to take 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 CD. 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 CD process in your organization is well within your reach. Just remember these five points before you get started:
1. Focus on the process before the tools
2. Understand the needs of each team
3. Build one process to merge the combined needs of every team in the company
4. Implement the tools
5. Appoint a Continuous Delivery Engineer to manage all of the above!
Roee Rakovsky is a senior Continuous Delivery engineer at BlazeMeter, a platform for load and performance testing enables dev and QA teams to run scalable and continuous testing for website, mobile, API and software.