So we are talking about a transformation of the delivery process starting from high risk, manual deployments that took hours towards daily, automated releases. That's a huge challenge for many companies and there are certain organisational and technical preparations necessary, before the transition can be started. Also be aware that there is no shortcut we can take from quarterly to daily releases, but it is rather a continuous improvement that leads to continuous delivery. We need to go from quarterly to monthly to weekly to daily releases. Some companies might already be happy with monthly releases while others feel the pressure to release on a daily basis. No matter what your goals are, the solution is almost the same.
With this tech blog series, we would like to discuss the fundamental concepts of Continuous Delivery and also provide a step-by-step hands-on sessions to set up a simple deployment pipeline for Java Microservices in Amazon Web Services (AWS) Cloud. We divided the series into 3 bigger parts and we'll post a new blog entry every 2 to 3 weeks. Let's take a look at the areas we want to cover:
Introduction: CI/CD Patterns and Antipatterns
Part 1: CI/CD fundamentals - Configuration Management, Continuous Integration and the deployment pipeline
Hands-On session: Deploy a microservice to AWS with one click
Part 2: Managing infrastructure - Environments in AWS and how to manage data
Hands-On: Deploy an AWS environment and application with one click
Part 3: Development process - Branching and test strategies for CD
Hands-On: Fully integrated, tested and verified one-click feature delivery
Summary: How to continuosly release features 100% automated
Before we discuss the prerequisites to start with Continuous Delivery, let me define the scope of this blog series.
I am aware that there are various definitions regarding Continuous Delivery. In case of this blog, we are talking about Continuous Delivery in the sense of having the technical possibility of deploying features continuously and automated to all stages of the deployment pipeline. This doesn't imply that you'll actually release new software on a daily bases, which would be Continuous Deployment. It also doesn't mean that your software implementation approach is ready to do so. But there should be no hurdles and no hassle when you want to deploy a new feature and that's what we try to achieve. By making it safe and easy to deploy new versions and to push them from one stage to the next, the release frequency will speed up on its own.
Well known popular definitions are:
- Continuous Delivery is the ability to get changes of all types — including new features, configuration changes, bug fixes and experiments — into production, or into the hands of users, safely and quickly in a sustainable way.
by Jez Humble, https://continuousdelivery.com/
To sum it up, these are the central terms and abbreviations I am going to use throughout the blog:
Continuous Integration (CI): Integrating, building, and testing code within a certain environment
Continuous Delivery (CD): Mechanisms that enable the deployment of systems, components, changes and features continuously and automated to certain environments
Continuous Deployment: Daily or regular deployment of new features to production
When using the abbreviation CI/CD, it refers to general approaches and concepts touching Continuous Integration and Delivery.