The CI concept of “frequently and quickly checking software quality” has proven to be a good development practice. This paper tries to sum up some experiences along this line of thought.
A typical developer process is as follows:
1. Frequent, as often as possible. If an automation tool is not used frequently, its value will be greatly reduced.
2. Quick. If an automated tool is used for too long at a time, its value will be greatly reduced.
According to the above principles, the comparison of each stage in the process:
| phase | Occurrence frequency | Whether it is suitable for CI | Common CI item |
|---|---|---|---|
| Local codes | high | no | / |
| Local commit | high | Suitable for conditions: you need to ensure that your local and online environments are consistent. Many people code for Windows environments, which may not be suitable | Lint checks for static checks for secure coding checks for unit test compilation |
| push | high | Suitable for | Lint checks static checks security codes checks unit tests compile other checks (automation run time shorter) |
| Initiate the merge request | higher | Not suitable for a merge request after the launch may also push code, not good to determine the trigger point | / |
| Code review | In the | Not suitable for manual review | / |
| Merge the merge request | In the | Suitable for | Smoke test Indicates an interface test |
Based on the above tables, my experience is as follows:
1. CI in push phase must be done
2. The CI of merge Request is recommended, or it can be advanced
3. CI in the local COMMIT phase can be done as soon as possible, but the high probability of production will not be higher
So it can be summarized in a picture:
