Hello, I am Huang Junbin.
In many consulting projects in the past, I encountered many teams who did not use the practice of continuous integration pipeline very well. From the perspective of teamwork, in the process of version release, there are often problems that testing relies on development to manually generate artifacts, and version release also comes from local development.
Moreover, if the project architecture evolves from a monomer to a componentized architecture, as more and more components are separated, the previous build may be able to produce products, but after componentization, multiple components need to be built first, and then the components are integrated. The complexity of collaboration will also be higher.
The final consequence is that the team's collaboration efficiency is low, and the quality of the version cannot be controlled. The daily development work of development students is often interrupted, and they become veritable "packaging engineers".
How to solve these problems? The best way is to create a reliable and repeatable software release process, and automate the entire process as much as possible, thereby improving the overall integrated release efficiency. Reduce low-value repetitive work through automation.
Today we will learn together the core practice of continuous integration - pipeline. I will take the Sharing project as an example to show you how to design and configure a pipeline, and finally use GitHub Action to build a continuous integration pipeline.
Continuous Integration Pipeline
A continuous integration pipeline is a software development practice. As shown in the figure below, whenever the code is submitted for development, the pipeline will be triggered to execute the corresponding steps. These steps usually include scanning and checking, building, testing, and deployment. If the submitted code does not meet the checks set on the pipeline, the execution of the pipeline will fail and the code will not be merged into the warehouse.
So what value can the use of continuous pipeline bring to the team?
On the one hand, there is a significant increase in efficiency. Before using the continuous integration pipeline, the build and release of the version had to rely on the local build. If multiple versions need to be built in a day, the efficiency is very low. With the assembly line, we can automate these low-value tasks for us. In addition, collaboration norms can also be formed within the team, and everyone is subject to the version pushed by the pipeline, which can reduce unnecessary communication.
On the other hand is the obvious quality improvement. There are many uncontrollable factors in the locally built version, such as the development of the local build process, whether the latest code is pulled, whether the signature is correct, etc., may affect the quality of the final product.
With the continuous integration pipeline, we have a unified construction environment and a standardized construction process, effectively ensuring stable product quality. In addition, we can set up corresponding quality access control on the pipeline, such as static code inspection, automated test verification, architecture guard verification, etc. When the submitted code does not meet the requirements, it can not be allowed to enter the warehouse, which helps the team to discover related issues as soon as possible. mistake.
Of course, to make the pipeline work best, the key is for the team to be able to pay attention to the running status of the pipeline and respond in a timely manner. Below I will share with you 2 assembly line disciplines that need to be followed in practice.
The first one is that if the pipeline fails to build, the code is not allowed to be submitted, and it should be repaired as soon as possible. When the pipeline construction fails, we should immediately check the cause of the failure and fix it as soon as possible to avoid affecting the version. If it cannot be repaired in a short time, the code should be rolled back in time, so as not to affect the code integration of other members of the team.
The second is to ensure that the last pipeline build is successful before leaving work every day . We call this discipline CI Red Overnight. Usually, we have to ensure that there is at least one version available for testing every day, so as not to affect the next day's test and related personnel to get the version for verification.
Sharing pipeline design
For a componentized architecture, since multiple components are separated, it is more obvious to manage the release and integration of components through automation. If this part of the complexity cannot be transferred through automation, splitting components may be another burden for the team, requiring frequent manual management of component build releases, component integration releases, and other issues.
Therefore, we need to design a pipeline of component architecture to automate component management. Next, let's combine Sharing to see how to design the pipeline.
First of all, we need to classify the pipeline and split it into component pipeline and base pipeline.
The design of the component assembly line is mainly divided into 4 operation steps, namely quality access control inspection, code inspection, component product management and release notification.
The specific steps are as follows.
1. After the component developer submits the code, the pipeline quality access control inspection is automatically triggered. The quality access control includes code scanning, compilation, and automated testing. 2. The code is merged after the architect in the team inspects it. 3. Publish the latest component version to the maven product library. 4. Notify the relevant stakeholders of the construction results and products.
The design of the base assembly line is mainly divided into 5 operation steps, which are submitting the component integration list, performing quality access control inspection, code inspection, releasing the product to the version library, and finally confirming the release.
The specific steps are as follows.
1. The product team submits the component integration version list according to the version planning. 2. Quality access control includes code inspection, compilation, integration testing, performance testing, etc. 3. The architect in the team inspects, and the product manager confirms and merges the code. 4. Publish the latest application version to the product library. 5. After the team confirms, select the channel (internal test, gray scale, application market, full volume) for release.
In the actual process, we can flexibly adjust each step of the pipeline according to the project situation and the perfection of internal tools. The design of the pipeline should be the same as the code, which can be continuously iterated, not static. For example, generally speaking, the final release stage will not be automated, and manual testing and confirmation is required before the pipeline is triggered for release and deployment.
Example of using GitHub Action to build a pipeline
There are currently many continuous integration tools, such as Jenkins, GitLab CI, GitHub Action, AzureDevOps, etc. Since the Sharing project is currently hosted on GitHub, we use GitHub Action to demonstrate how to build a pipeline.
Let's first take a look at how to configure the pipeline based on GitHub Action. GitHub Action uses a yml configuration file to describe the build status of CI, just create the corresponding yml file in the .github/workflows directory.
You can refer to the following code. For your convenience, I have noted specific comments on each configuration.
//配置工作流的名称
name: Sharing CI
//配置当master分支有PR或者代码提交时会触发该流水线
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
//配置运行的任务
jobs:
build:
//配置运行的服务器环节，一般使用默认
runs-on: ubuntu-latest
//配置流水线的步骤
steps:
//配置系统的构建环境
- uses: actions/checkout@v3
- name: set up JDK 11
uses: actions/setup-java@v3
with:
java-version: 11
distribution: 'temurin'
cache: gradle
//检查Gradle运行环境
- name: Grant execute permission for gradlew
run: chmod +x gradlew
//执行静态代码扫描，使用lint检查
- name: Code Scan
run: ./gradlew app:lint
//执行代码架构检查
- name: Arch Test
run: ./gradlew app:testDUT --tests com.jkb.junbin.sharing.ArchRuleTest
//执行功能自动化冒烟测试
- name: Smoke Test
run: ./gradlew app:testDUT --tests com.jkb.junbin.sharing.SmokeTesting
//构建版本
- name: build
run: ./gradlew app:assembleRelease
//推送版本到artifact制品库
- name: Upload apk to artifact
uses: actions/upload-artifact@v3
if: always()
with:
name: sharing_app
path: ${
{ github.workspace }}/app/build/outputs/apk/release/*.apkAfter completing the configuration of the pipeline, when the code is merged, it will trigger the running of the pipeline, and you can view the corresponding build status in the Action option of the project.
In addition, in addition to automatic triggering, you can also click to enter the details to manually re-trigger the execution of the pipeline.
After the pipeline is successfully executed, you can view the built artifacts in the details.
It is especially recommended to use configuration files to define pipelines . On the one hand, changes and codes of pipelines can be included in version management. In addition, since configuration files and codes are managed together, development colleagues can pay more attention to pipelines. design.
At present, mainstream continuous integration tools all support the way of defining pipelines using configuration files, but the syntax of different tool configurations is slightly different, and the overall pipeline design is universal.
Summarize
Today we learned about the relevant practices of the continuous integration pipeline. Continuous pipeline is a software development practice that aims to create a stable and repeatable process for software release through automation.
The effect of the pipeline is obvious. It helps us reduce low-value repetitive work in terms of efficiency, such as local compilation and packaging, and also reduces unnecessary communication between team members.
From the quality point of view, the unified build and release environment will make the whole environment more reliable and reduce the accidental risk caused by manual operation. In addition, combined with the pipeline to increase the quality access control, the code quality can be checked before the release of the version, and the code that does not meet the specifications and requirements can be avoided from being merged into the code warehouse.
Of course, to make the pipeline play its best role, it is necessary to rely on the team members to follow the discipline of the pipeline to ensure that the pipeline is not red overnight, and can be repaired in time when the operation fails.
For the pipeline design of the component architecture, a hierarchical and hierarchical approach can be adopted. Specifically, it manages the construction and version management of components by designing the pipeline of components, and then designs the integrated pipeline to manage the integration and release of components.
Finally, I also showed you how to build a continuous integration pipeline through GitHub Action. GitHub Action uses yml configuration to define the pipeline. This method is more friendly to developers. You only need to describe the steps in a specific syntax format. Yes, and this configuration file can also be versioned together with the code. In practice, it is recommended to use this configuration file to define the pipeline.
The next lesson is the last lesson of the continuous delivery chapter. We will learn about measurement in the R&D process and see how measurement can help us discover problems and make continuous improvement, so stay tuned.
thinking questions
Thank you for finishing today's content. Today's thinking question is this: Does your project have a continuous integration pipeline? What problems did you encounter during use?
Article source: Geek Time " Large Android System Refactoring in Practice "