Skip to Content

Changes for page Continuous Integration

Last modified by chrisby on 2024/05/05 17:22
From version 2.16
edited by chrisby
on 2024/05/05 17:22
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,7 +1,5 @@
1 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 -For example, at the beginning of the day, each developer merges the latest main branch commits into their current feature branch, and at the end of the day, each developer merges their feature branch commits into the main branch.
4 -
5 5  ### Benefit
6 6  
7 7  **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.
... ... @@ -14,7 +14,7 @@
14 14  
15 15  ### Code Reviews
16 16  
17 -Requesting and providing code reviews, as on GitHub or GitLab, is a convenient feature for making code reviews asynchronous and remotely available, but it is not the most time-efficient approach for agile teams that do not need these features. For those teams, it is better to maintain high quality code by following these practices:
15 +Requesting and providing code reviews, as on GitHub or GitLab, is a convenient feature for making code reviews asynchronous and remotely available, but it is not the most time-efficient approach for agile teams that do not need these features. For these teams, it is better to maintain high quality code by following these agile practices:
18 18  
19 19  * Code is properly tested, refactored and simplified.
20 -* Code is implicitly reviewed in real time by [[pairing up|doc:Software Engineering.Agile.Extreme Programming.Pair Programming.WebHome]] with technically experienced team members.
18 +* Code is implicitly reviewed in real time by pairing it with technically experienced team members.