上QQ阅读APP看书，第一时间看更新

CI/CD

The term CI/CD combines the practices of CI and CD together as a seamless process. In a typical microservices-based setup, the team continuously works on enhancing the features of the microservice and fixing the issues that are encountered in production.

The entire cycle from development to deployment has three major phases, as shown in the following diagram:

In the first phase, the team commits the changes to a version control repository. The version control repository used for microservices should be common for all the services and applications. Consolidating all the implementations in a single version control system helps in automation and running application-wide integration and acceptance tests. Some version control services also support a fine-grained collaboration system that allows the developers to not only share their changes with a group of developers, but also have active reviews and a feedback system within the team before the changes are committed.

Version control systems like Git are ideal for a distributed team working on multiple microservices due to its inherent features. Service like GitHub and Bitbucket are some cloud hosting providers for Git that also have the capability to build triggers for CI/CD systems.

In the second phase, a CI/CD system such as Jenkins is used to build the changes and run the unit tests for the microservice for which the change is committed. Running the tests for each change request helps in detecting issues before the changes are integrated with the rest of the application. It also helps to detect any regressions (https://en.wikipedia.org/wiki/Software_regression) that might have been introduced due to the recent changes. If there are any test failures, an alert is sent back to the team, especially the committer who submitted the change request.

The team then fixes the tests and sends the change request again to the version control system that in-turn triggers the build to retest the changes. This process repeats until all the tests succeed. Once the tests succeed, the CI/CD system merges the changes with the mainline and prepares a release artifact for the service. Artifacts for microservices are often packaged as containers that are readily deployable by orchestration tools. Packaging microservices in a container also helps in automating the deployment and scaling of the services on-demand.

Docker is one preferred technology for packaging microservices. It has seamless integration with multiple orchestration tools such as Kubernetes and Mesos ( http://mesos.apache.org/).

In the third phase, the CI/CD system publishes the releases to a central repository and instructs the orchestration tools to pick the latest version of the microservice that contains the recent changes. The orchestration engine then pulls the latest release from the repository and deploys it in production. All the instances in production are monitored by automated tools that generate alerts for the team if there are any issues. If there are any issues encountered by the team, the team fixes the issues and submits the change request to the version control system that triggers the build and the entire process repeats to push the changes to production.

Generally, the orchestration engine does a rolling upgrade of the service while deploying updates, but some teams prefer to do the A/B testing by upgrading only a subset of deployed service instances and roll-out only when the tests succeed for that subset. Such deployments are often referred to as BlueGreenDeployment ( https://martinfowler.com/bliki/BlueGreenDeployment.html).

Such an automated environment helps the team cut short the entire development-to-deployment cycle from months to days and days to hours. Large companies such as Google, Facebook, Netflix, Amazon, and so on are now able to push multiple releases in a day due to such automated environments and robust testing processes.

本周热推：

中国信息化年鉴2017 学术虚拟社区用户社会化交互行为研究物联网概论第2版 DEM插值算法适应性理论与方法一本书读懂物联网