canmove, Confirmed users
6,439
edits
No edit summary |
|||
Line 10: | Line 10: | ||
* We track configuration updates to our masters on [[ReleaseEngineering:BuildbotMasterChanges | BuildbotMasterChanges]]. Any change to a production Buildbot Master should be tracked on this page. | * We track configuration updates to our masters on [[ReleaseEngineering:BuildbotMasterChanges | BuildbotMasterChanges]]. Any change to a production Buildbot Master should be tracked on this page. | ||
* Patches should not be checked in until you are ready to update the master with them. This helps to avoid situations where an urgent fix needs to go in, and a random unrelated patch ends up getting enabled at the same time. | * Patches should not be checked in until you are ready to update the master with them. This helps to avoid situations where an urgent fix needs to go in, and a random unrelated patch ends up getting enabled at the same time. | ||
* All affected masters running production instances must be updated. | |||
* Production masters should never contain local changes. Even if you are just testing something you should check it in and pull it rather than making the change locally. Having temporary changes in the version control history is useful when debugging things later. | * Production masters should never contain local changes. Even if you are just testing something you should check it in and pull it rather than making the change locally. Having temporary changes in the version control history is useful when debugging things later. | ||
* After landing a patch and reconfiguring the master, you should rebuild some old builds of affected components. This will help narrow down if problems come from changes to the masters, or product code changes. | * After landing a patch and reconfiguring the master, you should rebuild some old builds of affected components. This will help narrow down if problems come from changes to the masters, or product code changes. |