Introduction
Those were the days! Working for months on a release, undisturbed by customers involvement, so relaxed… Was it? Of course not, you want to add effective and efficient value to your customers business. And that’s a mutual demand! Therefore software development and delivery these days is not a linear periodic activity based on planned releases, e.g. yearly. It is evolved into an ever more frequent process of software updates delivery to meet the many vulnerabilities and user demands on time. This requires speed in all the activities of development and delivery.
When you say speed, automation is what you need. It is key! But how to automate the software development and delivery process to get that speed?
In this blog, I will showcase a simplified Continuous Integration/Continuous Delivery (CI/CD) pipeline with the software packaged in software containers.
This blog has the following content:
- Setting
- CI/CD and containers
- Software Delivery Model
- Showcase CI/CD and containers
- Conclusion
Key take-aways
The key-take-aways I would like to present in this blog:
- Consider using CI/CD always
- Build your CI/CD pipeline with the production environment as a starting point
- Using software containers simplifies your deployment automation and guarantees that your application environments are identical.
So, let’s speed things up and start!
Setting
To illustrate the subject, I present a fictitious case, an epic user story and the problems we want to solve.
Suppose you are a start-up company with smart, agile thinking people who want to develop and deliver bespoke software to demanding clients. In the future, you want to grow into a big company. So, in everything you do scaling is an important aspect. Imagine we give them an old-fashioned deployment of one release every few months. No…!
It’s very important to know how long it takes from the idea to the working version for the client. From the start, you want figures (metrics), especially the metric ‘lead-time from idea to production.
Your opinion is that developing software is a creative process but everything else in the delivery process is rather dull, error prune and can therefore best be automated. You want Continuous Integration/Continuous Delivery (CI/CD).
In your short stay at an enterprise, you were amazed that in the test processes the software environments of development (laptop of dev), test, acceptance, and production (DTAP) differ. This should not be the case and must be taken care of by technology. You heard that software containers will solve this gap.
The epic user story of this blog is: As a blog reader I want to automate my software delivery process so I can have my product with a defined quality at the push of a button.
We want to solve the following problems:
- The long time needed from idea/feature/ bugfix to software in production
- Test with the same software as will be used in production
For our setting, we have Software Delivery, the software and a development/test environment on laptop and a production environment. This is depicted in figure 1.
Figure 1: Software Delivery
CI/CD and containers
The title of this blog contains ‘CI/CD’ and ‘containers’. First, let me explain what CI/CD and containers are and why you should use them.
CI/CD
The principles of Continuous Integration / Continuous Delivery are:
- Create a repeatable, reliable process for developing software
- Automate everything
- Keep everything in version control
- If it hurts, do it more frequently and bring the pain forward
- Built-in quality
- Done means in production
- Everybody is responsible for the delivery process.
I define CI/CD as an automated process to deliver software from idea to software in the production environment for the client. This process we can start at every moment, there is no dependence on anything before, thus continuously. In CI/CD it is possible that the process stops to wait for human action, a go / no go moment.
CI/CD is a concept, and the automation is realized with a CI/CD system. The CI/CD process, which is from idea/feature/bugfix to working software in production, is implemented in what we call a CI/CD pipeline. So, a CI/CD pipeline is a chain of automated or manual processes.
Why CI/CD?
Why is CI/CD the way to go? Some rationales to use CI/CD pipelines are:
- Standardized – always the same process activities and steps
- Avoiding repetition
- Avoiding human errors
- Not only during office hours
- Decreasing time to delivery, there’s that speed again!
Containers
A software container is a standardized way to package software. In the container, in fact, the container image, we put all the artefacts needed to run the software in production and nothing more. With software, I mean application and all dependencies.
Why containers?
Why should you use software containers? Some rationales are:
- Build once (container image) and run everywhere (immutable)
- To do 1 task
- Short life (ephemeral)
Software Delivery Model
To put everything in context. I made a software delivery model for this blog (series).
Software delivery is the process to deliver quality software fast and often to our clients for the initial release, new releases, feature releases, bug fixes and security patches.
The Software Delivery Model is based on the following way of working:
- Continuous learning
- Think big – act small
- Agile
Note: the software delivery model is also dynamic and can change during this blog series.
Everything in the model will be explained from the following perspectives:
- People
- Process
- Product
People is the people working in the process and the users of the customer.
The product is what I call the gift (application the customer likes) for the user. CI/CD is also a product and can be delivered with a CI/CD pipeline in the same delivery model.
Important aspects (or requirements) of the process are:
- Change (everything is changing in an ever-changing world)
- Automation
- Speed (of course)
In figure 2 we show the model.
Figure 2: Software Delivery Model
Showcase: CI/CD and containers
In this blog, we design a CI/CD pipeline with containers, the focus of this blog.
In the old fashion way, an enterprise had at least two departments dev and ops interfacing with big runbooks with manual steps and software delivered on separate discs. The bigger the company, the bigger the number of departments with some responsibility in this. Sometimes, well more often than we would assume, it was like there was a wall of confusion between the departments. And the more departments involved, the bigger that wall.
Nowadays we want, we must deliver software automated, with a click of a button and ONE team responsible for developing and operating the systems (DevOps).
When designing a CI/CD pipeline it is a wise idea to start at the end of the process. In line with ‘customer first. All (manual) activities from production-ready product to client using the product have no added value and must be automated. In another blog post, I will discuss which activities are necessary to have defined quality software.
We choose to have software packaged in a container, so we need a container environment to run it. A container environment is agnostic to the infrastructure. Agnostic means that the environment can run on edge devices, laptops, virtual machines, or bare metal. On-premise, in the cloud, private or public, whatever the enterprise needs, not what several delivery departments need or want!
Deploying with containers means that the container image is made by the build step and placed in a container registry. A registry is a place where CI/CD can push and pull container images. The activity steps are:
- Pull the container image
- Pull the configuration file
- Run the container
- Test if the container is running
There are two configurations needed:
- Configuration immutable
- Configuration depending on the environment
The configuration is injected when deploying so the application and environment match.
The best way to guarantee that the laptop and production environment are identical is to use the same container environment. For example, when choosing for container environment Kubernetes on production it is very wise to have Kubernetes on every environment for the CI/CD pipeline. So, the activity ‘deploy on laptop’ and ‘deploy on production’ are nearly identical.
Now we can fill the model with a solution within the scope of the blog.
- Two environments: laptop of dev and production environment
- Software (application) in a software container
- The software delivery process with 3 process activities which are automated in a CI/CD pipeline.
- Build the application into a container image
- Deploy the container image and run it on the laptop of the developer
- Deploy the container image and run it on the production environment for the client.
The Software Delivery Model with blog showcase scope is depicted in figure 3.
Figure 3: Software Delivery Model: showcase CI/CD and containers
Conclusions
The key take-aways of this blog are:
- Speed is what customers demand!
- Consider using CI/CD always
- Build your CI/CD pipeline with the production environment as a starting point
- Using software containers simplifies your deployment automation and guarantees that your application environments are identical