Continuous Integration, Continuous Delivery, Continuous Deployment. If you're a developer or working with a software product in any way, you've probably heard these terms, probably more often than you would like.
In case you're not familiar with the differences, here's some quick background on what each term means.
Continuous integration (CI) means that whenever a developer checks in code to a source repository, a build is automatically triggered. The build process can be as simple as attempting to compile the source code or as complex as running unit tests, regression tests, linting the source code and then generating a report.
Continuous delivery builds ontop of Continuous integration by ensuring that code can be rapidly and repeatibly deployed to production by delivering every change to a production-like environment. Continuous delivery pipelines will run acceptance tests and smoke tests to verify that the business applications and services function as expected. Since every change is delivered to a staging environment using complete automation, you can have confidence the application can be deployed to production with a push of a button when the business is ready.
Continuous deployment takes Continuous delivery one step further. Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements.
Continuous deployment/continuous delivery has been around for a while, but the growing popularity of DevOps toolchains (such as Chef, Puppet, Ansible) and Cloud platforms (such as AWS, Azure, Google Cloud, Rackspace) have made it easier than ever to setup a completely automated deployment pipeline.
The field is still changing significantly, but there are a handful of tested and proven continuous deployment patterns, though each has its own use cases.
WIP
Continuous Integration, Continuous Delivery, Continuous Deployment. If you're a developer or working with a software product in any way, you've probably heard these terms, probably more often than you would like.
In case you're not familiar with the differences, here's some quick background on what each term means.
Continuous integration (CI) means that whenever a developer checks in code to a source repository, a build is automatically triggered. The build process can be as simple as attempting to compile the source code or as complex as running unit tests, regression tests, linting the source code and then generating a report.
Continuous delivery builds ontop of Continuous integration by ensuring that code can be rapidly and repeatibly deployed to production by delivering every change to a production-like environment. Continuous delivery pipelines will run acceptance tests and smoke tests to verify that the business applications and services function as expected. Since every change is delivered to a staging environment using complete automation, you can have confidence the application can be deployed to production with a push of a button when the business is ready.
Continuous deployment takes Continuous delivery one step further. Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements.
!Image
Continuous deployment/continuous delivery has been around for a while, but the growing popularity of DevOps toolchains (such as Chef, Puppet, Ansible) and Cloud platforms (such as AWS, Azure, Google Cloud, Rackspace) have made it easier than ever to setup a completely automated deployment pipeline.
The field is still changing significantly, but there are a handful of tested and proven continuous deployment patterns, though each has its own use cases.
Stateful Components
Stateless Components
Blue-Green (Red-Black)
Cyan (AKA Purple)
Rolling
References