In the previous article, “Connections and Differences between Continuous Integration and Continuous Delivery,” we covered the basic concepts of continuous integration and continuous delivery and the connections and differences between the two. This article will go one step further and show you how Choerodon’s CD pipeline capabilities can help the project team achieve continuous delivery.
What is continuous delivery
Before moving on to features, let’s review the concept of continuous delivery. ** Continuous delivery refers to the ability to continuously deploy integrated code to development, test, or pre-production environments for testing and verification on the basis of continuous integration. ** That is, continuous delivery is the delivery of every change to a non-production environment, and the final choice to deploy to production will be a complete feature or set of features, or a complete application or service.
The figure above nicely illustrates the process of continuous delivery, where code can be continuously deployed to development or test environments after continuous integration. Finally, after the overall functionality and requirements testing is complete, it can be manually deployed into production. Of course, there are other things to note:
Continuous delivery does not mean that every change should be deployed to production as quickly as possible. It means that every change is ready to deploy. — Carl Caum(Caum, 2013)
Why continuous delivery
We all know that continuous delivery is an important part of DevOps practice, but what benefits does continuous delivery bring to the team?
- Quick release. Able to quickly respond to business requirements and realize software value faster;
- Continuous delivery advocates frequent deployment and automatic deployment, which is the premise of continuous testing to improve software quality;
- High quality software distribution standards. The whole delivery process is standardized, repeatable and reliable;
- The whole delivery process is visualized to facilitate team members to understand the project progress;
- More advanced teamwork. From requirements analysis and product user experience to interaction design, development, testing, operation and maintenance, there is less waste compared to the traditional waterfall software team.
How can continuous delivery be achieved through Choerodon?
Choerodon’s platform connects development and deployment modules in series in the form of a CD pipeline. Users only need to preset the corresponding deployment task or manual point task in the pipeline. The integrated code of the target application service can be automatically deployed to the development environment, test environment, pre-production environment, and production environment (the flow to the production stage requires the installation of approval personnel). Then set up the manual point task, can be timely notified to the product owner or tester acceptance and testing of the new deployment through emails and in-site letters.
Create a continuous delivery pipeline
First of all, click Create Pipeline on the menu page of “Deploy – Application Deploy – Pipeline”, and the pipeline creation page as shown in the following figure will appear. Project staff can define multiple pipeline phases as required here, as well as multiple tasks within each phase.
Pipeline infrastructure
When creating a CD pipeline, you need to define the name of the pipeline and set the trigger mode of the pipeline to automatic or manual.
- Automatic trigger: The pipeline is automatically executed only when all trigger conditions are met. If automatic trigger is selected, task 1 of phase 1 in the pipeline can only be used as a trigger for deployment type tasks.
- Manual trigger: The pipeline can be triggered only by manually clicking the execution button. If manual trigger is selected, you need to select the trigger person for the pipeline (multiple options are available). Only the selected person has the permission to execute the pipeline. If there are deployment tasks in the pipeline, the triggering personnel must have the environmental permissions corresponding to all deployment tasks in the pipeline.
Add and set phase
- Add stage; Click the Add button between stages to add a stage successfully; In addition, it is also supported to modify the name of this stage and set the flow mode between stages. If manual flow is selected, an auditor needs to be set for this purpose (multiple options are available, and by default, if one of them passes the audit, the task will pass, and if the first auditor clicks abort, the task will be terminated).
- Task setting; In each phase, you need to set the task execution mode. They are: task serial and task parallel, wherein task serial means that all tasks in the stage are executed successively from top to bottom; Parallel refers to that all tasks are executed at the same time in a stage. However, when the tasks are parallel in a stage, the tasks with manual stuck points cannot be added in this stage.
- You can enter the next phase only after all tasks in one phase are successfully executed.
Adding a Deployment Task
In order to achieve repeatability, reliability and scalability of the deployment process, automatic deployment task types are supported in the continuous delivery pipeline. You need to configure the application service, trigger version type, environment, and instance deployment information as follows:
- If the task type is Deployment, enter the task name and select an existing application service.
- Enter or select the service version type (you can select the default version type or manually enter a custom version type. If this field is left blank, all versions of the application service are automatically deployed by default.
- Choose the environment; Only the running environment can be selected;
- Select a deployment mode (there are two deployment modes: new instance and replace instance).
- Select deployment configuration. The system automatically matches all associated deployment configurations based on the selected application service and environment. You can select deployment configurations based on the configuration information. If the selected application service and environment do not have corresponding deployment configurations, you need to create one on the deployment configuration page.
If this deployment task is the only one in the pipeline, the pipeline will be triggered when the developer submits the code, runs the CI, and generates a version of the application service that meets the criteria (the generated version name must contain the version type defined in the task). When the pipeline is triggered for the first time because there are multiple deployment tasks in the pipeline, the trigger conditions of all the pipelines must be met (service versions that meet the conditions are generated).
Add a human card point task
The manual checkpoint task is used to add control and audit personnel for the deployment task in the phase. The pipeline can continue to execute only after the designated audit personnel pass the review. If the audit fails, the whole pipeline terminates at this task node. The steps to add the manual point task are as follows:
- After selecting the human card point task type, you need to fill in the task name and select the auditor (multiple choices);
- If multiple auditors are selected, you need to select an audit mode, including countersignature and or signature. (Countersignature means that the task is approved only after all the selected auditors pass the audit. If one of them chooses to terminate the task, the task will be terminated. Or sign means that if one of the selected auditors passes the audit, the task will pass, and if one of them chooses to terminate, the task will be terminated, subject to the audit result of the first auditor).
After the manual point task is successfully created, when the assembly line executes this type of task, the auditor will be informed by default via email and in-site letter. After testing and accepting the deployment, the reviewer approves the task and allows the pipeline to continue.
View continuous delivery pipeline records
Each execution of the CD pipeline will generate an execution record, and each record also contains the execution details of all phases and tasks.
On the menu page of “Application Deployment – Deployment”, project personnel can view the number of pipeline deployment record, corresponding pipeline name, trigger mode, executor, running time and running result in the list. Currently, the running results are as follows:
| The results | meaning |
|---|---|
| successful | All tasks in the pipeline are successfully executed |
| failure | A task fails to be executed in the pipeline. Procedure |
| The execution of | There are tasks running in the pipeline |
| To audit | The pipeline is stopping at the point of manual audit, including the manual audit between the point and stage |
| terminated | During manual audit, click to terminate the task, and finally the pipeline is in terminated state |
| deleted | The original pipeline has been deleted, but the execution record remains on this page |
In the record list, actions can be performed for pipeline deployments in different states. For pipelines that fail to execute, the project owner can re-execute all tasks in the pipeline; If the assembly line status is to be audited, the execution can be continued only after the audit by the designated auditor; For a process in execution, the project owner can enforce failure.
Click the number of a record to view the details of the record. In this page, the execution details of the corresponding pipeline will be displayed. It includes the trigger mode of pipeline, trigger personnel, stage details and task details.
conclusion
In summary, continuous delivery is the ability to continuously deploy application services to various environments in the delivery pipeline. Continuous integration, continuous deployment, continuous testing, continuous feedback associated with continuous delivery, and the continuous improvement they bring together are all integral parts of DevOps practice landing.
About the toothfish
Choerodon, as an open source multi-cloud application agile full-link technology platform, is based on open source technologies such as Kubernetes, Istio, Knative, Gitlab, and Spring Cloud to integrate local and Cloud environments and achieve consistency of enterprise multi-cloud/hybrid Cloud application environments. Platforms help organizations manage the software lifecycle by providing lean agility, continuous delivery, container environments, microservices, DevOps, and other capabilities to deliver more stable software faster and more frequently.
See Release Notes and the official website for more details.
You can also learn about the latest developments of toothfish, product features and participate in community contributions through the following community channels:
- Liverpoolfc.tv: choerodon. IO
- BBS: forum. Choerodon. IO
- Github：github.com/choerodon
Welcome to join the Choerodon Toothfish community to create an open ecological platform for enterprise digital services.
This post is by MAO Zhiwei from the Toothfish community of Choerodon.