How to realize the continuous release of applications?
01 Continuously publish summary
In the process of publishing, people often encounter many problems:
1. During manual deployment, due to too long publishing time, errors will occur frequently, and you need to manually correct the publishing problem;
2. When the environment is decoupled, due to the large differences among different environments, there is no similar production environment, resulting in prominent environmental problems. Due to the instability of the environment, it is impossible to judge the online situation during the first deployment;
3. When the cluster is published, it needs to be modified manually due to the different configurations of each environment. At this time, the node configuration is almost uncontrollable. If the production environment configuration is directly modified, the risk is relatively high;
4. When multiple development collaborations and frequent updates occur during publishing, they will block each other. At this time, the cost of cooperation in operation and maintenance, development and testing is very high.
It is hoped that in the process of continuous release, it can realize multi person development, simple deployment, stable environment, continuous automatic verification, rapid functional iteration, support the setting of release mode, and ensure functional stability. When problems occur during publishing, it can quickly roll back to a stable version and quickly feed back problems.
Measurement often directly affects team behavior. If the number of lines of code is selected as the indicator of developers, developers will not write the code succinctly for the sake of performance. This phenomenon is called Hawthorne effect.
During the delivery process, cycle time can be selected as the measurement. Cycle time refers to the time from the start of development to the final delivery.
For example, when preparing resources, the period from the time when environmental resources are prepared to the time when the environment is fully available is the cycle time of resource preparation. Now on the cloud, people can directly purchase online after applying for a budget, which greatly shortens the resource procurement cycle.
Release effectiveness refers to the time period from function development verification, preparation for release to customer delivery. It includes the preparation time of the release, the configuration time of the release environment, the grayscale time, the speed of releasing feedback problems, and so on.
02 Continuously release the construction path
In order to shorten the cycle time, it is necessary to realize the automation of the whole process. The environment, software package, network configuration, infrastructure, external services and other functions are all included in version management from the aspects of construction, deployment, testing, and release.
When publishing applications, you need to prepare the running environment required by the software, configure the required infrastructure, external service dependencies, etc. Software delivery can be completed by running the software to the installation environment and configuring the required data and status.
In terms of version management, including requirements documents, test scripts, automation cases, network configurations, database creation, upgrading, initialization, rollback, etc., version management is required.
In addition, the team needs to reach consensus. In the process of continuous release, the team should follow the release specification, continuously improve the whole process, and ensure that the risk is controllable.
03 Practice of continuous release on cloud
Next, let's talk about the steps of continuous release. In terms of environment preparation, input templates, and use existing templates or custom templates to describe the cloud environment. Any input parameter to execute automatic deployment. Finally, check the completion of resource deployment and conduct subsequent management.
This resource preparation process is suitable for enterprises to quickly go to the cloud, deploy in batches on demand, quickly copy resources required by applications, and quickly build applications using existing resources.
In terms of continuous construction, you need to package and upload the service code package to OSS. The user pulls the corresponding software package by entering the relevant environment parameters. Then, pull the corresponding package information to ECS through the O&M choreography. The cloud assistant executes the corresponding deployment script, starts the application, and provides external services.
When the business continues to expand and the machine cannot support the service, it can quickly provide the expansion and contraction of the machine through elastic expansion, so as to achieve automatic deployment.
In terms of continuous release, the rolling upgrade is mainly based on elastic scaling. First, close the capacity expansion activity, and then group the instances to make them standby. The corresponding instance will not provide external services during the publishing process. After publishing, the instance exits the standby mode and provides external services.
Rolling upgrade is suitable for canary release, blue green release, batch release and other capabilities. Create the software package in the O&M choreography, create the expansion group and add the ECS instance, and then execute the rolling upgrade task.
04 Continuous release of applications
Next, let's talk about the principles of continuous release. Application publishing is a low-risk, frequent, low-cost, rapid and predictable process.
In this process, scripting, versioning, replaying and feedback are required. In terms of automation, automated deployment, automated testing and automated feedback should be realized.
In terms of management, version management, dependency management, environment management and configuration management should be improved. Realize fast rollback, fast repeated release and traceability. When problems occur, they can continue to improve, iterate frequently, feed back quickly, and shorten the production cycle.
Improving the traceability and observability of lifecycle delivery can make the release more effective.
As shown in the figure above, the related services that are continuously released mainly include cloud, environment preparation, code building, automatic deployment, and continuous release.
In terms of environment preparation, you can prepare through cloud resource products such as ros, terraform, ecs, acs, oss, etc. During code construction, application configuration management can be conducted through acms and erdc cloud effects.
In terms of automatic deployment, you can deploy and build through edas or OSS. In terms of continuous release, you can customize the deployment pipeline through rdc cloud effect and conduct continuous release through autoscaling.
Q&A link, user Q&A
Q1 The Hawthorne effect is due to the artificial effect caused by the fact that the research objects realize that they are being studied. Can this situation be completely avoided after cloud automation?
Answer: It is necessary to judge which measurement method is better when continuous publishing. Assuming that the measurement index is a wrong index, Hawthorne effect will lead to deviation in the results. If the measurement indicators are reliable, the Hawthorne effect will make the indicators become better and better.
Q2 Because of the resource related, data related, control related and other related issues involved in pipeline deployment. How to effectively solve the problems that may be encountered?
Answer: Pipeline deployment is generally deployed in applications. When setting applications, you need to set resource data permissions. In addition, access control capabilities on the cloud can also be used to enhance.
In the process of publishing, people often encounter many problems:
1. During manual deployment, due to too long publishing time, errors will occur frequently, and you need to manually correct the publishing problem;
2. When the environment is decoupled, due to the large differences among different environments, there is no similar production environment, resulting in prominent environmental problems. Due to the instability of the environment, it is impossible to judge the online situation during the first deployment;
3. When the cluster is published, it needs to be modified manually due to the different configurations of each environment. At this time, the node configuration is almost uncontrollable. If the production environment configuration is directly modified, the risk is relatively high;
4. When multiple development collaborations and frequent updates occur during publishing, they will block each other. At this time, the cost of cooperation in operation and maintenance, development and testing is very high.
It is hoped that in the process of continuous release, it can realize multi person development, simple deployment, stable environment, continuous automatic verification, rapid functional iteration, support the setting of release mode, and ensure functional stability. When problems occur during publishing, it can quickly roll back to a stable version and quickly feed back problems.
Measurement often directly affects team behavior. If the number of lines of code is selected as the indicator of developers, developers will not write the code succinctly for the sake of performance. This phenomenon is called Hawthorne effect.
During the delivery process, cycle time can be selected as the measurement. Cycle time refers to the time from the start of development to the final delivery.
For example, when preparing resources, the period from the time when environmental resources are prepared to the time when the environment is fully available is the cycle time of resource preparation. Now on the cloud, people can directly purchase online after applying for a budget, which greatly shortens the resource procurement cycle.
Release effectiveness refers to the time period from function development verification, preparation for release to customer delivery. It includes the preparation time of the release, the configuration time of the release environment, the grayscale time, the speed of releasing feedback problems, and so on.
02 Continuously release the construction path
In order to shorten the cycle time, it is necessary to realize the automation of the whole process. The environment, software package, network configuration, infrastructure, external services and other functions are all included in version management from the aspects of construction, deployment, testing, and release.
When publishing applications, you need to prepare the running environment required by the software, configure the required infrastructure, external service dependencies, etc. Software delivery can be completed by running the software to the installation environment and configuring the required data and status.
In terms of version management, including requirements documents, test scripts, automation cases, network configurations, database creation, upgrading, initialization, rollback, etc., version management is required.
In addition, the team needs to reach consensus. In the process of continuous release, the team should follow the release specification, continuously improve the whole process, and ensure that the risk is controllable.
03 Practice of continuous release on cloud
Next, let's talk about the steps of continuous release. In terms of environment preparation, input templates, and use existing templates or custom templates to describe the cloud environment. Any input parameter to execute automatic deployment. Finally, check the completion of resource deployment and conduct subsequent management.
This resource preparation process is suitable for enterprises to quickly go to the cloud, deploy in batches on demand, quickly copy resources required by applications, and quickly build applications using existing resources.
In terms of continuous construction, you need to package and upload the service code package to OSS. The user pulls the corresponding software package by entering the relevant environment parameters. Then, pull the corresponding package information to ECS through the O&M choreography. The cloud assistant executes the corresponding deployment script, starts the application, and provides external services.
When the business continues to expand and the machine cannot support the service, it can quickly provide the expansion and contraction of the machine through elastic expansion, so as to achieve automatic deployment.
In terms of continuous release, the rolling upgrade is mainly based on elastic scaling. First, close the capacity expansion activity, and then group the instances to make them standby. The corresponding instance will not provide external services during the publishing process. After publishing, the instance exits the standby mode and provides external services.
Rolling upgrade is suitable for canary release, blue green release, batch release and other capabilities. Create the software package in the O&M choreography, create the expansion group and add the ECS instance, and then execute the rolling upgrade task.
04 Continuous release of applications
Next, let's talk about the principles of continuous release. Application publishing is a low-risk, frequent, low-cost, rapid and predictable process.
In this process, scripting, versioning, replaying and feedback are required. In terms of automation, automated deployment, automated testing and automated feedback should be realized.
In terms of management, version management, dependency management, environment management and configuration management should be improved. Realize fast rollback, fast repeated release and traceability. When problems occur, they can continue to improve, iterate frequently, feed back quickly, and shorten the production cycle.
Improving the traceability and observability of lifecycle delivery can make the release more effective.
As shown in the figure above, the related services that are continuously released mainly include cloud, environment preparation, code building, automatic deployment, and continuous release.
In terms of environment preparation, you can prepare through cloud resource products such as ros, terraform, ecs, acs, oss, etc. During code construction, application configuration management can be conducted through acms and erdc cloud effects.
In terms of automatic deployment, you can deploy and build through edas or OSS. In terms of continuous release, you can customize the deployment pipeline through rdc cloud effect and conduct continuous release through autoscaling.
Q&A link, user Q&A
Q1 The Hawthorne effect is due to the artificial effect caused by the fact that the research objects realize that they are being studied. Can this situation be completely avoided after cloud automation?
Answer: It is necessary to judge which measurement method is better when continuous publishing. Assuming that the measurement index is a wrong index, Hawthorne effect will lead to deviation in the results. If the measurement indicators are reliable, the Hawthorne effect will make the indicators become better and better.
Q2 Because of the resource related, data related, control related and other related issues involved in pipeline deployment. How to effectively solve the problems that may be encountered?
Answer: Pipeline deployment is generally deployed in applications. When setting applications, you need to set resource data permissions. In addition, access control capabilities on the cloud can also be used to enhance.
Related Articles
-
A detailed explanation of Hadoop core architecture HDFS
Knowledge Base Team
-
What Does IOT Mean
Knowledge Base Team
-
6 Optional Technologies for Data Storage
Knowledge Base Team
-
What Is Blockchain Technology
Knowledge Base Team
Explore More Special Offers
-
Short Message Service(SMS) & Mail Service
50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00