The foundation of continuous delivery and continuous deployment is continuous integration (CI). Microsoft defines continuous integration as “the process of automating the build and testing of code every time a team member commits changes to version control.” What does this look like in practice?
Imagine the developer makes a change. They then have to check that change into the control repository, which triggers an automated response of testing the change to make sure it compiles. Next, the change is bundled with or integrated into other developers’ work and run through automated tests to make sure it’s valid. How does continuous delivery build on top of continuous integration?
Mindset + Automation = Continuous delivery
Continuous delivery (CD) builds on the automation practices of continuous integration and shifts the way teams think about development. CD is the idea that the system is always in a verified state or valid state where if one wanted to, they could push current changes to production.
To make this idea a reality, teams have to rely heavily on automation. For example, you need an automated process for integrating the change with the work your team has done, testing it, and packaging the software so it’s ready to go. Automating these processes requires that someone think through the steps to ensure there is consistency across different workstreams.
Continuous delivery takes continuous integration one step further; it takes that integrated and validated set of software, bundles it, and prepares it to be deployed. You could compare CD to the 1980s and 1990s when you’d create executable and DLL files that could then be installed on any computer. It’s more sophisticated now, but it’s basically creating files that can be installed on servers and deployed to servers. Like the EXE and DLL files, they’re conveniently packaged and ready to go at any time.
Most customers like the concept of having a system that’s always ready to go. It gives their team a psychological boost that enforces quality, demands discipline, and improves communication. It’s easy to adopt continuous delivery because you’re getting code ready for deployment, but not actually deploying it.
Now that we understand the first part of the logical flow, (continuous integration > continuous delivery) where does continuous deployment fit in?
Continuous deployment: 1-click ordering of the development world
We can compare continuous deployment (CD) to Amazon’s 1-click ordering. When you order something on Amazon with 1-click, as soon as you make the purchase, a series of automated tasks occur. This results in you, the customer, receiving an order.
Similar to Amazon’s 1-click ordering, once a change is made under CD, it goes through a series of automated processes that result in new code being deployed to a live environment. Once the process starts, it goes from start to finish automagically. What are the actual steps CD goes through?
Continuous deployment looks a lot like this: change is made > integrated > compiled > tested > packaged > sent to production. After the change is made, continuous deployment sends it to production and your customers or beta testers see it instantly. This fact raises the stakes and is something that most companies are uncomfortable with.
A company that’s not afraid of continuous deployment is HubSpot. They deploy somewhere over 300 times a day. HubSpot is able to do this by keeping teams small, giving them ownership, leveraging feature gates, and using a whole lot of automation. It’s clear that some of the tech giants are implementing CD, but what about the rest of us? Very few organizations are making changes that fast. Many don’t want to send changes to production the moment the developer saves their code to the code base. Why?
Why do people shy away from continuous deployment?
The difficulty with continuous deployment comes more from external pressures than internal worries. A few of the external pressures organizations might have are:
- Bundling or integrating third-party software. This requires a level of coordination that is difficult to automate.
- Highly regulated industries. Regulated industries require that software be validated before pushing to production. Hastily pushing software to production could create legal liability, and for most organizations, the risk outweighs the reward. The software would have to be perfect, or near perfect, after testing and packaging before firing out to production.
Theoretically, it’s possible to simulate how third parties use your software as part of the testing process. For example, we know how partner A integrates with our software and how they use it. We can use that information to ensure future deployments are compatible with partner A’s third-party software automatically.
While continuous deployment is possible in complex situations, organizations need to ask: At what point does the cost outweigh the benefits? Do you really need 300 deployments a day?
For most organizations, continuous deployment might not make sense. However, CD can help companies that need to:
- Quickly test features with the help of beta testers or internal resources
- Remove slowdowns from bureaucracy in low-risk industries
- Ensure security or stability releases go out as soon as possible
Even when facing these challenges, organizations are still hesitant to implement continuous deployment. They don’t find CD practical and view it as highly theoretical. In fact, many organizations struggle with continuous methodologies.
The debate around the implementation of continuous methodologies
We have customers that claim to use continuous delivery. While they build, test, and bundle the software, I would argue it’s “ready to go” in a theoretical sense. They still double check the work manually, and the level of automation varies greatly. In some cases, they have really strong automated testing so that the manual review is more cursory. In other cases, the automated testing is less robust, and they need a more in-depth manual review.
Some argue that half-way implementation isn’t true continuous delivery. But I feel this becomes an academic debate that doesn’t really serve anyone. Sure, they may not be fully implementing CD, but the point is that customers are striving towards the goal of continuous delivery. Whether they are at 25, 50, or 75 percent implementation, CD is now serving as a guide in how they run their projects, and the percentage of implementation is just a statistic. The benefits they experience speak for themselves.
CI/CD promote transparency, quality, and agility
CI/CD isn’t just about having software ready all the time or being able to deploy at a moment’s notice. There are also tangible business benefits. Let’s consider a few.
Improve transparency into the state of the software. Software is no longer developed in silos, which improves communication and coordination from the top down. Improved transparency in your communication helps you keep stakeholders on the same page and make better business decisions.
Improve the quality of the software. The automation of strong processes equals consistency, security, and stability. Tedious processes like testing and QA are automated, which leaves less room for human error and increases the speed at which security patches and updates can be released. This ultimately leads to a better customer experience and reduction in the technical risk your business carries.
Improve the agility of your organization. If you think back 30 years ago, everything was based on the Waterfall software development model and was very slow moving. For example, you’d have a tentative June completion date for your software update but because you were working with separate, siloed teams, you’d lack the control to ensure completion by that date. Development was a black box, and teams couldn’t easily see the progress of the software. This process was the opposite of the continuous methodology which is built on agility and transparency.
Now that we’ve looked at some of the business benefits of CI/CD, let’s look at how it also improves your team’s workflow.
Increased automation improves workflows and reduces downtime
Twenty years ago, you could make a change to the code, check it in, and go home for the night. The problem is that you might have just released a bug that prevents the system from being compiled and screwed over other members of the development team. Another team member is now sitting there trying to finish their work, but the system is broken. Now, before they can continue working, they need to track down your changes and revert them.
This type of situation used to happen all the time. For example, it would be the end of the day on Friday, and our team in Minsk would leave at 11:00am U.S. time for the weekend. Someone would commit a change that breaks the system and would drive the U.S. engineers crazy. The CI/CD methodology stops that from happening. When a team member checks their work in, the system automatically compiles the changes and kicks back anything that doesn’t compile.
Continuous methodologies also help improve the requirements process. Requirements need to be clear and state in advance how they’ll be validated before development. To do this effectively, you have to work in parallel with the code. Someone needs to define what the requirements are and explain how they will be validated. When the team is in alignment, they can then create the test to validate it while someone else works on the code. This simultaneous workstyle requires more clarity on requirements than in the older Waterfall methodology.
These elevated standards have been positive for development as it’s raised requirements’ definition and improved clarity and specificity. This benefits the early stages of development where defects don’t really happen in coding but are more due to confusion over requirements. If somebody has to state in advance how they’re going to validate the code, it ensures we’re on the same page early on, ultimately improving communication, excelling coordination, and reducing risk.
What paths can the reader take to implement these processes?
You can start laying the foundation for continuous development by establishing the right processes within your organization. For example, it would be almost impossible to implement CI/CD without Agile as a foundation. With Waterfall, there are so many practices that don’t match up with CD, but continuous development methodologies seem to be native extensions of the Agile process.
Next would be training. Is your team trained on Agile? Are roles defined in your organization? Without people trained on Agile, specifically Scrum or Kanban, it’s going to be very difficult to implement continuous delivery or continuous deployment.
Once you have the right processes in place and people trained, it really becomes an engineering effort. Starting with continuous integration, the first role you’d probably add would be DevOps with automated testers coming in at a close second. DevOps people would give you a way to automate the building and integration of the software and automated testers would give you a way to test out the software. Once the Agile foundation is in place, you can begin to build the structure of your software by adding positions in DevOps and testing.
These steps are a great starting place for continuous delivery and continuous deployment. Are you ready to leverage the advantages of CI/CD development?
How does Coherent Solutions fit in?
Our Coherent Solutions team has a lot of experience in setting up CI/CD processes and DevOps engineering infrastructure. This includes creating the necessary tools to implement CI/CD. Our experience helps us advise clients, augment what they’re already doing, and show how other companies have solved the problems that they are facing.
CI/CD is not this half-baked Waterfall thing from 25 years ago. It’s how companies like Google and Netflix operate these days. They’re highly controlled, highly automated, and ready to rock and roll at any moment. That’s where our development team thrives. Advising and helping clients set up CI/CD is something we love to do and are passionate about. If you’re ready to implement or augment CI/CD in your organization, let’s talk today.
