Skip to Content

Changes for page Continuous Integration

Last modified by chrisby on 2024/05/05 17:22
From version 2.7
edited by chrisby
on 2024/05/05 17:14
Change comment: There is no comment for this version
To version 1.10
edited by chrisby
on 2024/01/13 18:02
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -6,17 +6,13 @@
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.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.
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.
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  
13 13  ### Code Reviews
14 14  
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 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:
16 16  
17 17  * Code is properly tested, refactored and simplified.
18 -* Code is implicitly reviewed in real time by [[pairing up|doc:Software Engineering.Agile.Extreme Programming.Pair Programming.WebHome]] with technically experienced team members.
19 -
20 -### Developer Branches
21 -
22 -One possible workflow is to create a new branches from main branch, one for each developer in the team. Therefore they are called developer branches and can be named after the team member they stand for. At the beginning of the day, each developer merges the latest main commits to his personal developer branch.
18 +* Code is implicitly reviewed in real time by pairing it with technically experienced team members.