As a software engineer, the most important thing we need to resolve is, how to deliver the product to its customers?
In this page, I will share my thought in this.
Let me introduce a very typical continuous integration pipeline here. You can refer to my earlier post Continuous Integration for more details.
Build=>Unit Testing => Code Analysis => Staging => Deployment => Delivery
For many companies, the Release Day is the busiest day and why? That is because for most of the projects the risk in delivery is highest!
Let’s consider a scenario. In Release Day, Operations Team needs to prepare the OS environment, and then install 3rd-parties libraries and software. After that, Operations Team needs to transfer the to be deployed applications to the server and then follow the deployment guide provided by development team to configure the system. And if it is being deployed to a distributed environments, Operations Teams has to do above steps node by node. Okie, now everything is almost done. Operations Team tries to startup the applications however it fails out! — I think many engineers would have the similar experience as here.
Below is the summary of problems in software delivery:
1. You deploy your software manually – even for your testing, staging, demo environments.
The characteristics of this practice are:
# You have a very detailed document and you have to follow the document strictly to deploy your application
# You need to do manual testing to verify whether your deployment works.
# You need to work with development team very frequently to fix deployment issues.
# If your deployment is distributed, then you have to deploy them node by node.
# Deployment will take some time.
# The result of deployment is unknown. You cannot know whether your deployment can work or not.
# Your team doesn’t deploy or test on staging environment frequently. – Here I defined ‘Staging Environment’ as an environment with the same configuration as Production.
# You need to configure your production environment manually. In other word, you can not reproduce a duplicated production environment for other purposes in minutes.
In a word, you can not deploy your applications by clicking an ‘Enter’ button.
Okie, we all know that we can use Automated Continuous Integration/Delivery to fix above problems in Software Delivery. Fast delivery is very important nowadays, we need to have a fast, effective, and reliable way to delivery high quality and value products.
To achieve this goal, we need to delivery the products frequently and automatically:
1. Automated. If we can not automate our build, deploy, testing and delivery, then it is not reproducible. The result of every deployment is unpredictable because software configuration, system configuration, and the procedures can not be reproducible. That means we can not provide good quality products through our release engineering.
2. Do it frequently. If we can deploy very frequently then the difference between deployment with last deployment will be minor and this will reduce the risk dynamically and also it is easy to roll back the deployment if any issue happen.