Skip to Content

Changes for page Continuous Integration

Last modified by chrisby on 2024/05/05 17:22
From version 1.9
edited by chrisby
on 2023/11/28 21:32
Change comment: There is no comment for this version
To version 2.1
edited by chrisby
on 2024/03/04 21:48
Change comment: Renamed back-links.

Summary

Details

Page properties
Content
... ... @@ -1,12 +1,12 @@
1 -Code changes are integrated into the main branch several times a day.
1 +**Integrate code change at least once a day.** This means that code changes on a feature branch you are working on should be merged/integrated into the main branch, and main branch changes should be merged into the feature branch.
2 2  
3 3  ### Benefit
4 4  
5 -**Early Integration Is Cheaper**: The longer side branches wait to be merged into the main branch, the greater the risk of multiple integration conflicts. It is easier to fix small individual integration problems iteratively than to fix multiple problems at once. Therefore, continuous integration has the advantage of identifying integration problems early, when they are cheap to fix.
5 +**Many Small Integrations Are Cheaper**: The longer side branches wait to be merged into the main branch, and the larger the differences between them become, the greater the risk of multiple integration conflicts. It is easier to fix small individual integration problems iteratively than it is to fix multiple problems at once. Therefore, continuous integration has the advantage of catching integration problems early, when they are cheap to fix.
6 6  
7 7  ### Guidelines
8 8  
9 -* **Stable Code Only**: Just code that passes all tests shall be merged into the main branch. There are tactics for [[speeding up test execution|doc:Software Engineering.Testing.Enhance Test Execution Speed.WebHome]] to help ensure that this practice can be performed frequently. For example, it is common to run acceptance tests only once a day, at night, because they are so time-consuming, and to fix problems, if any, the next day. All other tests are much faster and can be run frequently during development. The faster, the better.
9 +* **Stable Code Only**: Just code that passes all tests shall be merged into the main branch. There are tactics for [[speeding up test execution|doc:Software Engineering.Testing.Test Speedup.WebHome]] to help ensure that this practice can be performed frequently. For example, it is common to run acceptance tests only once a day, at night, because they are so time-consuming, and to fix problems, if any, the next day. All other tests are much faster and can be run frequently during development. The faster, the better.
10 10  * **Incomplete Features Allowed**: It is normal for the main branch code to temporarily contain incomplete features. Feature toggles are a common pattern for turning off incomplete features through simple configuration.
11 11  * **Never cheat to make a failed pipeline/test suite pass**, e.g. by removing the failed tests.
12 12