Welcome to our Tech Blog Series: Continuous Delivery of Microservices in AWS

Nowadays customers expect IT-companies to deliver new features faster than ever. In the past, it might have been enough for enterprise companies to deliver a new version of a system every quarter. In the last few years, many of them had to switch to monthly releases to fulfill customer needs. Still that seems to be not enough. Lately customers start to expect a continuous flow of new features, like the big IT companies Google and Co. already do it for years.

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 a software development discipline where you build software in such a way that the software can be released to production at any time.
  by Martin Fowler, https://martinfowler.com/bliki/ContinuousDelivery.html

• 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.

Prerequisites for Continuous Delivery (CD)

While many companies are already well prepared, others still need to change and improve parts of their organisation and implementation approaches before starting with the first steps towards CD. Let's take a look at the prerequisites before we continue with introducing the essential concepts behind CD.

The organisational part of CD

I don't want to go into detail here since this is a tech blog, but there are organisational restrictions that might cause you trouble in your effort to introduce CI/CD. In many enterprise companies, there used to be a separation between development and operations. If your company still has the approach of throwing deliverables over the fence to ops, then you'll have troubles introducing even CI mechanisms. If your company already shifted towards DevOps concepts, then you should be just fine. You should be able to answer the following questions with YES in order to be all set on the organisational side to implement CI and CD:

• Are developers and operations experts working in one team or at least collaborate closely?
• Does your team has access to CI/CD tools and is allowed to handle builds and deployments to test and staging environments on their own?
• Do you work in agile development approach which enables to release software regularely?

Multiple environments and development stages

In order to make CI/CD possible, multiple environments need to be available. From the local development environment for the developers to the official production environment, there can be various environments in between. It depends on the needs of the project or product, but in general at least a Development, Test and Staging environment are necessary.

When having multiple environments, each can be used to further test and integrate the software. With each step, the maturity of the deliverable grows and the risk for the final deployment decreases.

Well-defined quality gates from stage to stage

In order to make sure that the quality is increasing from stage to stage, well-defined quality gates and tests need to be implemented. In the beginning, the tests and checks can be manual - but they need to be executed everytime. No exceptions - No quick direct deployments to production. On the way to CD, more and more steps of the quality gates need to be automated. Quality gates may include component and integration tests, data quality checks, non-functional requirement tests, code quality checks and more.

A version control with all documents checked-in

One of the basic requirements for CI/CD is a well integrated and handled version control system - preferably some sort of GIT. Most important there is a general rule to follow: Check-in every file, configuration, piece of code or anything else that is relevant for software to work. This is very important. By doing so you guarantee that your tags and branches contain everything necessary.

More sophisticated but equally important is to divide systems into different repositories and folder structures. There is no general rule, but you should consider to use different repositories for systems and independent components like microservices. On the other hand, if a database is an essential part of a (micro)service, then the scripts to create and populate the database should be in the same repository as the microservice. Managing components/systems in different repositories will lead to loose coupling which enables us to deploy them independently.

Clear branching rules and feature switches

To make CI/CD work, developers need to check-in often - at least once a day. On the other hand, the code base needs to be always in a deployable state. Therefore developers have to know how to handle release, feature or team branches. But even more important, they need to know how to develop and check-in without breaking the code. Unfinished additional features for existing components can use feature switches to deactivate them till they ready to be published and so on.

All set?

If the prerequisites don't worry you too much, then I'd say you are ready to dive deeper into CI/CD. In the next blog post we'll discuss the basics of CI/CD and start to work on our deployment pipeline.