Continuous Integration and Continuous Deployment Techniques

The DevOps trend has given rise to a number of buzzwords and methodologies aiming to speed delivery and accuracy, giving developers the tools they need to deliver better products, with fewer bugs, and implement improvements continuously. Speaking of continuously, you may be familiar with the terms continuous delivery, continuous deployment, and continuous integration. The differences between the three can be confusing, but there are some important distinctions to know.

We wanted to gain some clear insights and expert perspectives on the three concepts and the primary differences. So, we reached out to a panel of development leaders and dev pros and asked them to weigh in on this question:

New call-to-action

"What are the biggest differences between Continuous Delivery, Continuous Deployment, and Continuous Integration, and how can developers best utilize them?"

Meet Our Panel of DevOps Pros and Development Leaders:

Find out what our panel had to say about the three popular terms and how you can put these methodologies to work for you by reading their responses below.

Nick Jones

@NS804Apps

As Founder and CEO at NS804, Nick has developed hundreds of apps for iOS and Android helping entrepreneurs, start-ups and Business leaders harness the power of mobile devices through custom mobile applications.

"Continuous Delivery is a small build cycle with short sprints…"

Where the aim is to keep the code in a deployable state at any given time. This does not mean the code or project is 100% complete, but the feature sets that are available are vetted, tested, debugged and ready to deploy, although you may not deploy at that moment.

The focus and key here is to keep the code base at a deployable state. This is the standard everyday project that goes out to the public or is consumer facing. In today's world, you cannot afford to release a bug-riddled project, so smaller sprints allow for quicker turn times to identify bugs and therefore quicker time in fixing those bugs, creating a much more stable code base early on. This is our preferred method of working.

With Continuous Deployment, every change that is made is automatically deployed to production. This approach works well in enterprise environments where you plan to use the user as the actual tester and it can be quicker to release.

Try Stackify's free code profiler, Prefix, to write better code on your workstation. Prefix works with .NET, Java, PHP, Node.js, Ruby, and Python.

Continuous Integration is merging all code from all developers to one central branch of the repo many times a day trying to avoid conflicts in the code in the future. The concept here is to have multiple devs on a project to keep the main branch of the repo to the most current form of the source code, so each dev can check out or pull from the latest code to avoid conflicts.

This is critical in multiple person dev teams on a project. For example, we have a project going on now where the backend Dev team is in California and they make progress on their work, while we are completing the client side of the mobile app (in Virginia). We were stumped for two days because we could not connect to the simulator because of integration issues, which is critical for not only the back end devs to be working in parallel to our work, but all of us to be on the same exact version of the code, otherwise we could build out items that work for some, but not for the rest of the team.

Overall, each option is a concept in developing, and you need to approach your project to determine which works best for you and your project. As noted above, large companies developing internal apps would focus on the Continuous Deployment so they can get user feedback from the actual users faster, plan the next iterations, and get it out faster to the end user. Also they do not stand to lose a customer base if there are bugs.

The key is to approach each project and understand the end user to determine which approach you want to take.

Rod Cope

@RodCope

Rod Cope, CTO at Rogue Wave Software, has spoken on various technical and business topics at Strata/Big Data, OSCON, Embedded World, Embedded Systems Conference, ApacheCon, and LinuxCon, was a ZendCon keynote speaker, and received the JavaOne Rockstar Award three years in a row.

"Continuous Integration is…"

About automating build and test processes to make sure the resulting software is in a good state, ideally every time a developer changes code. CI helps development teams avoid "integration hell" where the software works on individual developers' machines, but it fails when all developers combine (or "integrate") their code. Continuous Delivery goes one step further to automate a software release, which typically involves packaging the software for deployment in a production-like environment. The goal of Continuous Delivery is to make sure the software is always ready to go to production, even if the team decides not to do it for business reasons. Finally, Continuous Deployment is a process that automatically deploys the results of Continuous Delivery into the final production environment, usually every time a developer changes code (assuming all automated tests pass). Companies using Continuous Deployment can push hundreds or even thousands of releases into production every day. Of course, this practice requires excellent automated testing coverage and benefits from the ability to roll out changes slowly (e.g., starting with a small subset of servers or customers and expanding to more over time if no issues occur) and to roll back changes quickly if something goes wrong.

Development teams can take advantage of Continuous Integration by deploying a solution such as Jenkins, the most popular open source tool in the space, and configuring it to build and test their code. Continuous Delivery usually involves other DevOps-related tools like Puppet, Chef, Ansible, or SaltStack to install and configure environments for testing. Docker and container orchestration components like Kubernetes make it easier for teams to automatically set up and tear down these environments as part of the CI/CD process. The open source project Spinnaker, created by Netflix, provides a robust Continuous Delivery and Continuous Deployment solution. Although Continuous Deployment works best for web sites and APIs, Continuous Integration and Continuous Delivery help with all software development, including shrink-wrapped products and internal use only applications.

Mark Snodgrass

Mark is Managing Director of Hararei, Inc., an IT consultancy firm with specialties in Cloud, Cybersecurity, Agile, DevOps, Transformation Change/People and Process. Mark's expertise is in Cloud, IT Security, Storage, Virtualization and Infrastructure. He held leadership positions with ADP, Merrill Lynch and Accenture and was a technology advisory board member (Google, IBM).

"The overall objectives of the Agile software development approach are to accelerate time to market and improve code quality…"

The Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment (CD) process is a framework that enables this approach. The biggest difference between these stages (CI/CDs) is whom it benefits most at each stage.

CI benefits developers most because it allows for code produced to be automatically tested and continuously "integrated" with other developers' code, and with the existing codebase. The developer benefits from receiving continuous and immediate feedback regarding code and integration errors. As s/he fixes these errors, automated testing tools in this stage will report if the errors were successfully fixed and when the code is accepted. This continuous feedback loop dramatically increases a developer's productivity.

Continuous Delivery benefits business users because as soon as code is successfully accepted in the CI stage and a logical function can be tested, it is released to users. They verify that the features meet their expectations and provide feedback to developers who then address the feedback in this stage. This feedback loop between users and developers is continuous and seamless. Whereas in traditional waterfall method, users could wait weeks/months to see the features for the first time, this approach can dramatically reduce the time to just hours/days.

Continuous Deployment seamlessly pushes code that has been successfully accepted in the CI/CD cycle into the production environment. This stage benefits all key stakeholders, from application investors who fund the development to external consumers and internal end-users as new features/application is available for immediate (external) commercial sale or internal use.

Developers can best utilize the CI/CD/CD process by leveraging on Open Source tooling (e.g., Jenkins, GIT, and Bamboo from Atalassian), or AWS services (e.g., Code Deploy) that automates various integration, deployment, and release management tasks.

Kofi Senaya

@ClrMobile

Kofi Senaya is the Director of Product at Clearbridge Mobile where he works with multiple clients in various industries to design, plan, and execute their ideas. He leads a team of Product Owners and oversees quality assurance. Over the past 15 years, he has been deeply involved in all domains of product management from engineering to product support and even marketing.

"Let's say you have two development teams but both are working on the same project…"

Continuous Integration means that when they are working on the same code, they are building and unit-testing it to prevent any integration problems. If you spend two weeks writing the code and merging it without checking if it will integrate properly, issues can arise. Continuous Integration is a development practice that requires developers to integrate or merge code into a shared repository, continuously (preferably daily). The code is verified by the automated build which allows teams to identify problems before it's too late. If you wait too long to integrate the code and there's an issue, it becomes a bigger problem. Imagine that you're sewing a garment – say a shirt – and you give the sleeves and the collar to one team and the body of the shirt to another team. If you wait until the day of to give the shirt to someone, you won't know if it will fit them properly. Continuous Integration will help you save on costs in the long run as it is more expensive to fix defects in your high-level architecture when it's discovered later on in the process.

Continuous Delivery is similar to Continuous Integration. You are building a product that can be released to production at any time. Continuous Delivery requires building, testing, and releasing faster and more frequently. Continuous Integration happens before you build as you are testing code. Delivery means you can release something to the staging environment or the pre-production environment.

Continuous Delivery is when your code is always ready to be released but isn't pushed to production unless you make the decision to do so. It is a manual step. With Continuous Deployment, any updated working version of the app is automatically pushed to production.

Stefana Muller

@stefanamuller

Stefana is a DevOps expert bringing almost 20 years experience delivering enterprise software to the Fortune 1000. Currently Vice President at Datagrid Systems, she works with software and application developers to help them move from periodic releases to rapid deployment. Prior to Datagrid, Stefana spent 16 years with CA Technologies running global software product lines in security, cloud, agile development, and testing technology. As a Sr. Director, Product at CA, Stefana led CA Service Virtualization to #1 in market-share and revenue. She's transformed teams from waterfall development to Agile and worked with hundreds of teams to help them move to a DevOps culture.

"The differences between continuous integration, continuous delivery, and continuous deployment are…"

Continuous Integration (CI) is a software engineering practice in which developers integrate code into a shared repository several times a day in order to obtain rapid feedback of the feasibility of that code. CI enables automated build and testing so that teams can rapidly work on a single project together.

Continuous delivery (CD) is a software engineering practice in which teams develop, build, test, and release software in short cycles. It depends on automation at every stage so that cycles can be both quick and reliable.

Continuous Deployment is the process by which qualified changes in software code or architecture are deployed to production as soon as they are ready and without human intervention.

How do they work together?

In essence, continuous integration is the beginning of the cycle where builds are created and tested. Continuous delivery encompasses the cycle from the beginning of CI and ends with the "release" of the verified artifacts – packages, VM or container images – published onto a download server. Continuous deployment ensures that qualified releases are automatically deployed to production – taken from the download servers and made the currently running version in one or more environments/locations, typically also using rolling upgrades in order to ensure that applications remain available to users during the process.

How can developers best utilize these methods?

In the most efficient situations, the CI/CD pipeline is a fully automated (and sometimes autonomous) toolchain that ends in running software. This allows developers to focus on writing code and not on the minutia of build/test/deploy. Essentially, CI/CD provides developers a reliable path to deliver their technology to users. Developers, and mostly DevOps teams, can benefit from tools that help them automate this pipeline to a point of autonomy so that any situation brought to the table (update, upgrade, downgrade, teardown, errors, rollback, etc.) can automatically be handled by the system without a team having to manage or script out the change.

Alex Walworth

@PITSSAmerica

Alex Walworth is a technical lead a PITSS. He leads digital transformation projects in every industry from healthcare to financial services.

"The difference between continuous integration, deployment, and development is…"

At the highest level, all of these terms focus on the ability to plan, develop, and deploy applications in a quick and effective manner. These terms are still in the process of being more concretely defined in the tech industry.

For example, many people consider continuous integration to pertain to the process of automated testing and deployment of applications by a means of updating a particular version of the app's source code. Others consider CI to only pertain to the versioning of source code. I disagree with this definition as the means of versioning source code is a common practice for nearly two decades. Most IT professionals will understand Continuous integration to be the former.

There are some who would rather separate the meaning of Continuous Integration and Deployment. As mentioned before, CI pertains to only the means of properly versioning source code, and Deployment refers to automated deployments of the source code. This is accomplished by another system monitoring the changes occurring in particular code branches, which will then initiate a build process. This process will automatically build the application with specific library versions, or even dynamically retrieve the latest version available. It will then automatically run tests on the application to ensure everything is functioning properly before deploying to the environment specified. If all goes well, the changes made by the developer will be deployed and ready to access by the user base without any other action. Again, I want to reiterate that although some may consider this process to be defined by the term Continuous Deployment versus Continuous Integration, the majority of the tech industry will refer to this process as CI.

Continuous development focuses on the practice of development while dynamically determining the business requirements of a project. This strategy, which is most popularly practiced via the Agile development methodology, allows for the lifecycle of the project to change based on reviews sessions over short periods of time. Following this means of development ensures that changes are fluid and continuously updated based on the current state of the project.

Anatoliy Okhotnikov

@Softjourn

Anatoliy Okhotnikov is the Head of Engineering at Softjourn, Inc. He has more than 15 years of software development experience, including 10+ years in fintech, and holds a project leadership certificate from eCornell University.

" For me, the biggest differences between continuous delivery, continuous deployment, and continuous integration relates to the level on which every one of them operates…"

I strongly believe that continuous integration should be the basis for both continuous delivery & continuous deployment. While in its own turn, continuous delivery does not make much sense without the ability to deploy continuously to test, staging, and production environments. Some people might even say that continuous delivery is a synonym to continuous deployment to production.

In my mind, I am looking at the pyramid with continuous integration at the bottom, continuous deployment in the middle, and continuous delivery on the top. You can have only one of them or two of them at a time, and sometimes there is no other way around. But without the full stack, the developers will impair themselves and be less effective and efficient. For the developers, continuous integration is a must as it is one the primary practices in eXtreme Programming and Agile. The integration is unpredictable and the longer developer waits, more problems he or she creates for themselves in the future when it is time to integrate the code.

The ability to deploy continuously allows developers to get feedback as fast as possible from all the stakeholders including QA/QC, product owners, customers, etc. When you are able to move the result of your work to a production-like environment at any time, developers get the results of full-scale functional testing ASAP and move faster and with higher quality. The daily deployment to production, which is actually both continuous deployment and continuous delivery, is one of the corollary practices of XP. It allows developers to dramatically reduce the gap between what is on a programmer's desk and what is in production, which is always a risk.

And lastly, one more significant difference between the practices, which actually comes out of the level of operation is responsibility – where continuous delivery is absolute basic for the developers and all, including juniors, should do it. Continuous delivery, especially when it goes to the production environment, requires much more responsibility and trust – the ability to satisfy the customer through the continuous delivery of valuable software.

Anyway, this set of interconnected practices is a great tool for developers to make customers happy and developers professional.

Yaniv Yehuda

@DBmaestro

Yaniv is Co-Founder and CTO of DBmaestro and Co-Founder and head of development for the Extreme group, a leading IT services provider employing more than 200 and serving more than 50 of the largest enterprises in Israel. He previously co-founded by Uman, an innovative solution for managing web-enabled contact centers.

"Continuous integration and continuous delivery are integral parts of the continuous deployment process…"

Continuous integration combines the integrate and test function, following the initial code/build process of agile development. It focuses on streamlining development, integrating code into shared repositories, and automating builds and tests to make it easier to prevent and find problems more quickly.

Continuous delivery encompasses the release step, following integration. It ensures that each change is releasable, with complete automation of the release process. Continuous deployment is the final step in the process, allowing organizations to accelerate time to market on an ongoing basis.

Following the entire process – DevOps – ensures that developers can keep up with the demands of the business to accelerate time to market. On a day-to-day basis, developers need to choose the tools that will accelerate automation and allow complete oversight and control, making sure everything is integrated and delivered quickly and correctly, without causing any problems down the line.

Robby Russell

@robbyrussell

Robby Russell is a Partner and the VP of Engineering at Planet Argon, a Portland-based design and development agency specializing in Ruby on Rails applications. Outside of the studio, Robby plays music in an instrumental post-rock band, recharges on solo hikes in the woods, thinks up amusing tweets that never get published, and writes and consumes many types of content.

"Continuous Delivery and Continuous Deployment have a lot in common…"

In that when practiced, your product's code base is ready to be deployed at any time. The key difference is that with Continuous Deployment, your application is run through an automated pipeline workflow. Whereas with Continuous Delivery, your application is ready to be deployed whenever your team decides it's time to do so.

Continuous Integration is part of these workflows in that it's the process that your team uses to validate that the code base is in a healthy state by running your automated testing suite. It's the validation step when your developers add new features and make updates to ensure they didn't break existing functionality. Regardless of your deployment strategy, this is the key ingredient to a healthy software development recipe.

Alan Zucker

Alan Zucker is the Founding Principal of Project Management Essentials LLC.

"In Agile software development the ultimate goal is to deploy working software to end-users (customers) as quickly as possible, often in 2-week increments…"

Software being developed does not add value until it's deployed and being used. Also, when we deploy quickly we can see first hand how the software actually works. Agile places a premium on regularly (continuously) delivering software to the end-users.

In today's environment, there is the concept of a "build pipeline" which represents the steps to move new code from development into production. The basic steps in the build pipeline are:

1. Develop code
2. Unit test (test the code locally to ensure it works as expected)
3. Integrate (the new code into the existing code base)
4. Acceptance test (test the entire system to ensure it meets the users expectations)
5. Deploy to production

The terms continuous delivery, integration, and deployment have multiple meanings, often based on the audience and context.

Continuous integration refers to the software development practice of regularly integrating new code into the existing code base. This can be accomplished with automated tools that include the integration and testing of the code base. Often the new code is integrated into the base daily with automated tests ensuring that the new code works as expected and does not adversely impact the rest of the system.
Continuous delivery is sometimes used to represent the end-to-end chain of regularly delivering code to production. Others state that continuous delivery means that you have the ability to deliver to production, but the actual deployment is a manual step.
In the context in which the deployment of code to production is manual, continuous deployment represents automation of that last step. Continuous deployment creates the opportunity to deploy new code into production several times a day.

These "continuous" processes, taken together, represent the end-to-end automation of the software build process where teams are "always ready" to deploy new changes. These processes have many benefits including lower risk, faster time to market, better quality, lower cost, and happier teams.

Conceptually, continuous integration, delivery, and deployment represent different segments of the build pipeline. To a large extent, the distinctions between these steps are not material. The goal is to build and deploy software as quickly as possible. The segmentation of the process is a byproduct of the different tool suites that address discrete steps along the build pipeline.

Lindsey Havens

@PhishLabs

Lindsey Havens is the Senior Marketing Manager for PhishLabs with over 10 years of experience in Marketing, Communications, Public Relations, Lead Nurturing/Generation, and Analytics. With a unique blend of marketing and communications experience coupled with a background in behavioral and situational analysis, she bring metrics-driven results and the ability to focus sales and marketing efforts in a direction that offers the highest potential for long-term, sustainable growth.

"In continuous delivery software can be deployed to a customer immediately with a push of a button…"

When software uses continuous deployment, it must first pass through the continuous integration system before it is deployed. Continuous Integration is a core technique where code is integrated early and often into the system by everyone every single day. Deployment is derived from integration, so the two go hand-in-hand.

Richard Li

@datawireio

Richard Li is the founder of Datawire. Datawire builds open source infrastructure software that makes it easy for any company to adopt microservices.

"One of the keys to improving the agility of your software development process is in minimizing the friction required to integrate and release your code…"

Continuous integration is the process by which a developer's code is integrated with the main code branch as quickly as possible. A CI strategy usually involves an automated build system that is tightly integrated with your software configuration management system. Continuous delivery takes CI one step further, with an emphasis not just on integrating code, but also making the code shippable at any time. Continuous delivery usually requires automated testing, so that the developers are confident that the code can be shipped at will. Continuous deployment is a term that is usually applied to cloud software systems, where software code changes are automatically deployed to production, in a safe way. Continuous deployment strategies usually involve incremental deployments that allow changes to be tested incrementally.

Arthur Ariel Sabintsev

@ArtSabintsev

Arthur Ariel Sabintsev is The iOS Consultant. Currently, he is one of the lead iOS developers at The Washington Post. He has taught over a hundred classes on iOS Development at General Assembly, Betamore, and American University, and has edited a book for Packt Publishing. He has contributed to Apple's Swift Programming Language, and recently, one of his projects, Guitar, became part of Swift's Source Compatibility suite, which will be used by Apple to test Swift for backwards source compatibility. His open source software has been downloaded over 1,000,000 times and used in over 10,000 applications.

"To understand what these services are, one must understand how modern software is built…"

Imagine a tree, without branches at the moment – so, just the trunk (we also call it the mainline branch). That's where all the working/functioning features in your code live. Whenever a developer decides to work on a new feature, they branch from the trunk – a literal and figurative branch. At the beginning of their branch, they have a copy of the existing, working code, which they use as the base for building their new feature (or fixing a bug). After finishing their task, that code needs to be merged back into the trunk (existing working codebase). Now, imagine this same scenario, but with multiple engineers attempting to merge their code every hour of every day. This will lead into what is known as integration hell, which is due to the potential of multiple developers working on the same files of the codebase on their distinct copies (i.e., branches).

To resolve this issue, engineering teams employ Continuous Integration (CI), which is the act of having a (third-party, bloud-based) service attempt to compile the code in the branch, ruin the test suite, and check the changes that were made against the trunk. If the code in the branch doesn't have any issues, then this means that integration can occur, or that the build passed CI. CI is usually run on every commit made to a branch to catch errors early on.

Continuous Deployment is the act of deploying every addition to the mainline branch to the consumer. In the case of iOS development, it's the act of submitting a copy to the App Store for beta testing and eventual release to the general public. So, in the example I mentioned earlier, Continuous Deployment would happen after CI passes and the feature/bug fixes made were merged into the mainline/trunk branch. All the changes would be sent to the distribution/production environment; App Store for iOS, the actual server for web development

Continuous Delivery is the act of having a piece of code that is deployable. Depending on the company you're at, you may not simply want to deploy every change/feature that's added, but rather wait until a whole load of features/bug fixes are made and deploy it all at once (hence seeing App Updates every 1-2 weeks in the App Store). This is a point of contention among developers, as some teams prefer to deploy early and often, while others wait until the end of a 2-week cycle.

Marko Anastasov

@markoa

Marko Anastasov is a cofounder of SemaphoreCI.com, a hosted continuous integration and deployment service.

"The key difference between the three is in the scope of automation applied in a software release process…"

Most developers start with Continuous Integration (CI), which is about everyone merging code changes in a central repository multiple times a day. Each merge triggers an automated build and testing sequence for the given project.

CI is a safety net that lets developers prevent many issues before they reach users. As a result, they ship code with more confidence, but not necessarily faster — the deployment process may still be manual, long, and complicated.

The best initial investment developers can make is make sure that their automated test suite is comprehensive and stable enough that they feel safe to deploy every passed CI build to a staging and later production environment.

The second thing to maintain is speed: an easy way to optimize CI time is to run tests in parallel on a powerful platform. I strongly believe that developers must get CI results within 10 minutes otherwise their productivity shrinks due to a lack of focus and frequent context switching.

Continuous Delivery and Deployment

Continuous Delivery is a practice of automating the entire software release process. The idea is to do CI plus automatically prepare and track a release to production. By eliminating nearly all manual tasks, developers become more productive.

Continuous Deployment (CD) is a special case of Continuous Delivery in which every change in source code is deployed to production automatically, without explicit approval from a developer. A developer's job typically ends at reviewing a pull request from a teammate and merging it to master branch. A CI/CD service takes over from there by running all tests and deploying the code to production, while keeping the team informed about outcome of every important event. This also requires a high culture of monitoring, being on-call and recovery.

At Semaphore we've talked to many teams who do CD and found that developers find it very valuable to be able to configure different deployment targets and have a shared history of who deployed what and when. Developers who do CI and want to transition to Continuous Deployment often start by automating deployment to a staging environment, while keeping the deployment to production manual, with one click.

Allan Leinwand

@leinwand

Allan Leinwand has built a reputation for managing the world's most demanding clouds – in B2B and B2C. He is the chief technology officer at ServiceNow responsible for building and running the ServiceNow Enterprise Cloud – the second largest enterprise cloud computing environment on the planet. In this role, he is responsible for overseeing all technical aspects and guiding the long-term technology strategy for the company.

"Each of these 3 concepts are key principles that are used today to deliver products faster to the customer in a DevOps environment…"

Continuous integration is a step in which all code is merged as developers complete code in order to run automated builds and tests. Continuous deployment is the process of moving software that has been built and tested successfully into production. Continuous delivery is an approach which incorporates the concepts of continuous integration, automated testing and continuous deployment. The difference between continuous delivery and deployment is that business teams may decide not to release software into production with continuous delivery due to various reasons.

Sergiy Golub

@assembla

Sergiy Golub is the Vice President of Engineering at Assembla.

NOTE: The following information is excerpted from Continuous Delivery vs Continuous Deployment vs Continuous Integration: Key Definitions via Assembla.

"In today's modern software development world, continuous delivery, continuous deployment, and continuous integration have become widespread, but their definitions are often confused and consequently they can be misused…"

Continuous integration is the practice of constantly merging development work with a Master/Trunk/Mainline branch so that you can test changes and test that those changes work with other changes. The idea here is to test your code as often as possible so you can catch issues early on. In the continuous integration process, most of the work is done by an automated tests technique, which requires a unit test framework. It is best practice to have a build server designed specifically for performing these tests so your development team can continue merging requests even while tests are being performed.

Continuous delivery is the continual delivery of code to an environment once the developer feels the code is ready to ship – this could be UAT, staging, or production. The idea behind continuous delivery is that you're constantly delivering code to a user base, whether it be QA or directly to customers for continual review and inspection. Although similar to continuous integration, continuous delivery differs because it can feed business logic tests where unit tests are unable to catch all business logic, particularly design issues. In this process, you may also be delivering code for code review, which may be batched for release or not until after the UAT or QA is done.

Continuous deployment is the deployment or release of code to production as soon as it's ready. There is no large batching in staging nor a long UAT process before production. Any testing is done prior to merging to the Mainline branch and is performed on production-like environments. The production branch is always stable and ready to be deployed by an automated process. The automated process is key because it should be able to be performed by anyone in a matter of minutes (preferably by the press of a button). After a deploy, logs must be inspected to determine if your key metrics are affected, positively or negatively. Some of these metrics may include revenue, user sign-up, response time or traffic and preferably these metrics are graphed for easy consumption.

Justin Ellingwood

@jmellingwood

Justin Ellingwood is a Senior Technical Writer at Digital Ocean.

NOTE: The following information is excerpted from An Introduction to Continuous Integration, Delivery, and Deployment via Digital Ocean.

"To develop, test, and release software in a quick and consistent way, developers and organizations have created three related but distinct strategies to manage and automate these processes…"

Continuous integration focuses on integrating work from individual developers into a main repository multiple times a day to catch integration bugs early and accelerate collaborative development. Continuous delivery is concerned with reducing friction in the deployment or release process, automating the steps required to deploy a build so that code can be released safely at any time. Continuous deployment takes this one step further by automatically deploying each time a code change is made.

Chris Tozzi

@devopsdotcom

@SweetCodeHQ

Christopher Tozzi has covered technology and business news for nearly a decade, specializing in open source, containers, big data, networking and security. He is currently Senior Editor and DevOps Analyst with Fixate.io and Sweetcode.io.

NOTE: The following information is excerpted from Continuous Integration vs. Delivery vs. Deployment: What's the Difference? via DevOps.com.

"Like many technological concepts, continuous integration, continuous delivery, and continuous deployment are terms that DevOps teams tend to use without defining them precisely. For that reason, it's worth taking a closer look at what each of these terms actually means…"

Continuous integration can really mean one of two things, depending on the context.

In the narrower sense, continuous integration refers to the work done by a continuous integration server, such as Jenkins or Bamboo. A continuous integration server automatically tests code written by individual developers to make sure it can be merged into the main code base. By automating this process, continuous integration servers help developers to write and test small chunks of code on an ongoing basis, which minimizes the risk that a code change could cause serious problems and force developers to revert their application to an earlier state.

In a broader sense, continuous integration means the constant integration of changes to an application at all stages of the delivery chain. This includes but is not limited to the automated integration testing and code merging performed by an integration server.

In most definitions, continuous delivery refers to the process of delivering software updates to users on a nearly constant basis. Continuous delivery is made possible by continuous integration and other optimizations at earlier stages of the development process. But the definition of continuous delivery gets a little cloudy when you start comparing it to continuous deployment.

What's the difference between continuous delivery and continuous deployment? For some DevOps teams, nothing. People tend to use these terms interchangeably. In fact, they are usually simply abbreviated as "CD," leaving it up to the listener to decide what the speaker is actually talking about when he hears the term during a conversation about DevOps.

Some developers draw a distinction between continuous delivery and continuous deployment, however. For example, Mirco Hering writes that continuous delivery requires that the DevOps team manually release updates to users. In contrast, the continuous deployment pipeline is fully automated; users get updates as soon as they are written and tested, with no manual intervention by developers.

Sten Pittet

@Atlassian

Sten Pittet has a multidisciplinary profile. He understands very well both business and technical constraints and has many years of experience on the Web on various projects. He believes in the work hard, play hard philosophy. Previously, he worked for Atlassian as a Senior Product Manager and is currently taking a year off to look after his new baby and explore personal projects in Lisbon.

NOTE: The following information is excerpted from Continuous integration vs. continuous delivery vs. continuous deployment via Atlassian.

"CI and CD are two acronyms that are often mentioned when people talk about modern development practices…"

CI is straightforward and stands for continuous integration, a practice that focuses on making preparing a release easier. But CD can either mean continuous delivery or continuous deployment, and while those two practices have a lot in common, they also have a significant difference that can have critical consequences for a business.

Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button.

Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production.

Victoria Williams

@TeamRigor

Victoria Williams is a Digital Marketing Specialist at Rigor.

NOTE: The following information is excerpted from The Differences Between Continuous Integration, Continuous Deployment, and Continuous Delivery via Rigor.

"As continuous integration and continuous deployment/delivery become everyday terms in software development and the DevOps world, it's useful to define what they mean and clarify what each concept includes (and doesn't)…"

Depending on the context, continuous integration (CI) can mean one of two things:

The work done by a continuous integration server, such as Jenkins or Bamboo
The process of integrating changes into software at all stages of the delivery pipeline

Continuous Delivery/Deployment (CD) is a process by which an application is delivered to various environments, such as testing or production, once someone (usually a product owner/manager) decides that it is ready to go. Though some people use continuous delivery and continuous deployment interchangeably, there are some differences that should be noted:

Continuous Delivery is the frequent shipping of code to a given environment (such as test or production) via manual release.
Continuous Deployment is the automated release of code to a production environment.

Regardless of which term is used, the CD process is made up of the techniques, tools, and workflows that aid the above actions and allow CD to build on the benefits offered by CI.

###

Continuous integration, continuous deployment, and continuous delivery play a big role in culture within a dev team. It's important to have an agreed-upon process between dev and IT teams. For more insights on culture, download The Complete Development Takeover – The Culture Issue of our popular BuildBetter magazine. In this issue, you'll gain valuable insights on application monitoring, how to support production apps, how the cloud has impacted app troubleshooting the differences between app monitoring and application performance management, and more. And, check out our list of the top continuous integration tools if you're ready to start leveraging CI.

About the Author
Latest Posts

Top .NET Developer Skills According to Tech Leaders and Experts - October 20, 2021
What to Do About Java Memory Leaks: Tools, Fixes, and More - September 3, 2021
What is Load Testing? How It Works, Tools, Tutorials, and More - February 5, 2021
Americaneagle.com and ROC Commerce stay ahead with Retrace - September 25, 2020
Stackify's New Pricing: Everything you need to know - September 9, 2020

kitamuramaugh1943.blogspot.com

Source: https://stackify.com/continuous-delivery-vs-continuous-deployment-vs-continuous-integration/