The world of software development seems to create new buzzwords, processes, and methodologies almost as fast as it develops new software tools. The reason is that the industry is constantly evolving and becoming more efficient. However, in the software development world, there’s no such thing as one-size-fits-all solutions. Some methodologies will work better in certain scenarios than they do in others. The big question everyone is asking is, what will work for us? Or rather, what will work for us in this or that particular scenario? Recognizing that each of our organizations may have a variety of different methodologies from one product stream or dev team to another.
In this article, we will discuss the differences between “Continuous Integration,” “Continuous Delivery,” and “Continuous Deployment,” and how they may or may not work for your organization. We will also discuss how they compare to an Agile or DevOps environment.
To better understand how they each fit in and are applied, we need to develop a baseline development lifecycle to ensure we’re all on the same page. While there are a variety of nuances of the lifecycle from one organization to the next, in general, the key phases remain more or less the same. The core phases of the development lifecycle typically include a planning stage, followed by coding, building, integration, testing, release, and then deployment to the production environment.
To better establish our foundation, we need to understand the basics of the Agile and DevOps methodologies and their roles in the value stream. To do that, we’ve provided a short explanation of each to get us started.
The Agile methodology
This methodology takes the iterative approach to software development, by adding layer upon layer, building, or rather evolving, the application one sprint at a time. Regarding the lifecycle, the Agile methodology addresses the Plan, Code and Build stages. When the developer checks the code back in, automated processes then build and integrate these new iterations multiple times a day. After the code is integrated by automated processes, the new code is then passed through the remaining stages of the lifecycle manually, with little or no further automation.
DevOps
DevOps is described in Wikipedia as “a software development methodology that combines software development (Dev) with information technology operations (Ops). The goal of DevOps is to shorten the development life cycle while also delivering features, fixes, and updates frequently in close alignment with business objectives. The DevOps approach is to include automation and event monitoring at all steps of the software build.” …Development + Operations = DevOps. Typical DevOps methodology can overlap with Agile, but it typically picks up once the code is checked in and then addresses the rest of the stages in the value stream.
Iterative Methodologies vs Waterfall
Both Agile and DevOps take the iterative approach to software development. These methodologies are highly beneficial when something in production is better than something being developed. The image below provides an example of how even when the project is still being developed, there is something available and fully functional for the customers to use.
This image illustrates the value of the iterative approach. With the iterative approach, each floor is developed, built and tested before the workers move on to work on the next floor. This way the building tenants can move into that floor while the construction then begins and moves forward on the floor above, and so on. In contrast, the waterfall methodology requires the entire building to be fully developed before it can be built. And only when the entire product is built can it begin to be tested to determine if it’s acceptable for clients.
One of the key challenges with waterfall is in troubleshooting. Using the above example, if there is an electrical issue found on the 8th floor of the building, the technician needs to test each floor to narrow down and identify where the issue is originating. Only then can the issue be addressed.
However, with the iterative approach, if the same issue occurs, there is only the 8th floor to test. Each of the previous floors already passed the tests, so we can already rule out that the issue isn’t located there. If by chance the issue was located on the 4th floor, the tests would have identified it, enabling the developers to resolve the issue before they started work on the 5th floor.
Don’t get me wrong. The iterative approach isn’t the grand solution to every problem. We will discuss those challenges in detail later on in this article.
Why do I care?
Competitive differentiation is based upon a company’s ability to deliver their products and services faster than their competitors. This means that the software solutions that collect, track, manage and deliver those solutions has to also be delivered faster, cheaper, and with better quality than their competitors. Each of these methodologies discussed below delivers on all three of those accounts, though in slightly different ways, varying degrees and with different strengths. They can each be custom tailored to your specific needs, including products, velocity needs, project scale, project quantity, and workflow.
As companies strive to reduce operational costs, development teams are doing all they can to increase delivery velocity. With the focus on increasing speed, development teams are also under pressure to do so without jeopardizing quality. The classic mindset is that you can’t have both speed and quality. However, with these methodologies, the teams that use them prove this saying wrong daily, at least in regards to software development.
What is Continuous Integration (CI)?
Wikipedia describes Continuous Integration (CI) as “the practice of merging all developer working copies to a shared mainline several times a day.” The CI Model takes Agile a step further by automating the integration and Testing.
The thought of integrating new code with the mainline of the application code several times a day can be a scary thought for those more familiar with the waterfall methodology. At a glance, it seems that this would be massively problematic, resulting in the introduction of numerous bugs into the mainline code. However, as the majority of development teams have already discovered, the result is quite the opposite. The code segments being worked on at any given time are much smaller and are therefore easier to both code and debug if there is an issue. So, unlike the waterfall methodology where you create an entire version of the application and then submit it for testing, with continuous integration, the developer submits only small segments of the application at a time. Each of these code segments is then saved and automatically sent to the build server either immediately, or at regular intervals throughout the day. The build is then automatically passed to a test server that executes a series of automated unit tests to ensure that the new code segments work as planned. For additional information on the CI framework, Gartner has published a great article called, “A Guidance Framework for Continuous Integration: The Continuous Delivery ‘Heartbeat,” by Bill Holz and Sean Kenefick.
By doing this, the new code segments are built, integrated and tested in mere minutes, providing the developer with immediate feedback on the status of the code and any related issues.
How it works
With CI, the hand-off from one stage to the next is fully automated up to the completion of the testing stage. This is starkly different than that of the waterfall methodology, where the hand-off between stages is typically fully manual throughout the entire lifecycle and deals primarily with completed applications vs small code segments. This automation is achieved through the use of a combination of tools that perform the code check-in, build process, integration to the mainline application and testing. The remaining hand-offs from one stage to another in the lifecycle are all manual.
Continuous Integration (CI)
Key Strengths of Continuous Integration (CI)
- Testing
It’s no secret that testing the same test scripts every day can be a highly monotonous duty. Most development teams have found that the automation of test scripts wherever possible goes a long way. Not to mention, it also provides immediate feedback to the developer in mere minutes. - Issue Resolution
When the automated test scripts do find an issue in the code, because the code segments are small, the developers have been able to make quick work of issue identification and resolution. - Phased Changeover
With small iterative changes, studies have confirmed that the migration from an old version of the software to a newer version is much easier because the users are eased into the changes, instead of having to learn a new version of the software all at once. - Improved Team Morale
Surprisingly, submitting these iterative changes has also improved dev team morale, especially when tasked on larger projects. The reason is that it’s part of our human nature that we like to see accomplishments regularly. Unlike the waterfall methodology, where a large project can drag on for weeks or even months without completing any key milestones, the iterative approach allows developers to achieve multiple milestones per day. This also provides the immediate gratification of seeing their code passing the automated tests several times a day. - Increased Velocity
Teams have found that with the iterative changes to the code, automated builds, automated testing, and the rapid identification of issues, the overall velocity of the project delivery is significantly faster in comparison to waterfall methodology. - Improved Quality
Because issues are found and resolved with each sprint, those larger, more comprehensive development issues are substantially mitigated. This is because once a sprint has been deployed, subsequent code iterations are then added to the code that has already been proven to be functionally correct. This eliminates the issue of needing to fix multiple incorrectly developed modules because of a coding issue in a single module. - Improved Budget
With the increase in delivery velocity and shifting the identification and resolution of coding issues left, teams are saving a lot of time and resources, which all add up to a healthier bottom line.
What is Continuous Delivery (CD)?
As the next evolutionary step of CI, continuous delivery (CD or CDE) takes the development lifecycle automation a bit further. With CDE, the code is compiled, tested and dropped into the staging environment. Though not required for a continuous delivery model, some teams will also automate and execute system tests once the code is in the staging environment. Some highly recommended resources to learn more about continuous delivery include the book “Continuous Delivery” by Jez Humble and David Farley, and also Jez Humble’s website continuousdelivery.com.
It’s important to note that many credible authors do not differentiate between Continuous Delivery and Continuous Deployment. So, in researching these, it can sometimes be confusing to determine which one they are talking about.
Continuous Delivery (CD)
The key benefits of the CDE model include all the same benefits of the CI model, plus a few more
- Improved Velocity
The delivery speeds are notably faster due to the addition of the automated release into the staging/test environment. If your team also automates the system tests, it makes the overall delivery that much faster. - Phased Progression
Like Agile and CI, small segments of code are iteratively added to the mainline throughout the day. As the new code is added throughout the day, the mainline application evolves step by step to the target state. - Always Production Ready
With this methodology, the product version that sits in the staging or simulated production environment is always in a fully production-ready deployable state. This allows it to double checked, or to be held until other features are added and enabled. The advantage is that it is always ready and can be released into production at the push of a button. This methodology gives your leadership total control over product delivery. - Release Control
With a product that’s always production ready, the deployment to production becomes a business decision, providing total control over the user experience. - Additional Testing
This model allows the production-ready product to undergo additional, more comprehensive testing in various test environments, including integration testing, system integration testing (SIT), User Acceptance Tests (UAT), load testing, performance testing, and any others that your organization may require.
What is Continuous Deployment (CD)?
As the current evolutionary pinnacle of development lifecycle efficiency, continuous deployment (CD) enables a development team to integrate code segments to the production environment several times per day. This methodology is ideal for development teams that work on large websites or online tools.
Application of CD can be found at a number of large online organizations such as Amazon, Google, WordPress, and many others. It allows them to assign developers a specific set of functions to which they will continually work on and improve upon based on user feedback. Because of the small iterative changes that are constantly being added and updated to the production product, the users don’t experience any big changes that can sometimes cause consumer anxiety. Rather, a series of small simple changes add up over time, becoming big changes. This feeling of continual evolution has, in many cases, become expected by consumers for many of these high-traffic websites.
The level of automation achieved throughout the CD lifecycle is made possible by a combination of several different tools that work in tandem to receive-execute-and-pass to the next tool/stage in the lifecycle. Once the developer saves the new code, it is automatically built, integrated, tested, and deployed directly to the production environment. Because of this direct deployment into the production environment, it may not necessarily be the best solution for everyone. Some perceive it as taking control of when to move code to production from the leadership and giving it to the developers.
Continuous Deployment (CD)
The key benefits of this are similar to those of CDE. However, there are also others that should be mentioned.
- Morphed Migration
The product gets built iteratively in production and more or less morphs from one version to the next. This approach substantially reduces the anxiety that customers have when they are given a whole new version of the software that they now have to learn. - Enhanced Delivery Velocity
Gone are the days of creating code and lobbing it over the fence to builders, who then bounce it to the testers and so on. With continuous deployment, the developer can check code and get a pass/fail notification within minutes. If an issue is detected, they can resolve it and have the new version submitted and into production within a few minutes. If no issues are detected, the new code is moved automatically into production. - Shift Left
When a developer checks in code, the automated processes take the code and move it through the entire lifecycle and if it passes each gate, it gets deployed directly to production. This provides the developer with nearly immediate feedback regarding if a code segment has a defect or not. If an issue is detected in the automated tests, the developer is notified and can resolve the issue immediately. - Expedited Tests
Testing has traditionally been a bottleneck in the development lifecycle. However, with CD, automated tests can be set up throughout the value stream to be as thorough as needed. This means the testing can be set up at the appropriate stages to address the progression of the code throughout the lifecycle. This can include automated unit tests, integration tests, regression tests, performance tests, and so forth. These can be set up and executed at their respective stations in the lifecycle providing a thorough testing framework to ensure quality. However, because the gate management and handoff from one state to the next are also fully automated, the progression of the code through the lifecycle occurs at light speed when compared to the legacy waterfall approach. - Real World Experimentation
This model also allows for real-world experimentation, such as A/B testing, and allows for immediate consumer feedback. For example, if you need to change the location of a certain feature on a website, but you’re not sure of the best new location, you could make the change, monitor real-time customer usage, and make adjustments accordingly.
What are the challenges?
Over the years, the evolution and efficiency of the development lifecycles have certainly caused a lot of discussion among developers and leadership. However, while it has certainly benefited development velocity, quality, and consumer confidence, there are also some downsides that need to be considered.
