Skip to Content

Changes for page Continuous Integration

Last modified by chrisby on 2024/05/05 17:22
From version 1.10
edited by chrisby
on 2024/01/13 18:02
Change comment: There is no comment for this version
To version 2.2
edited by chrisby
on 2024/03/08 09:57
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -6,7 +6,7 @@
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  
... ... @@ -15,4 +15,4 @@
15 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:
16 16  
17 17  * Code is properly tested, refactored and simplified.
18 -* Code is implicitly reviewed in real time by pairing it with technically experienced team members.
18 +* Code is implicitly reviewed in real time by [[pairing |doc:Software Engineering.Agile.Extreme Programming.Pair Programming.WebHome]]it with technically experienced team members.