Confirmed users
2,456
edits
ReleaseEngineering/Buildbot Best Practices: Difference between revisions
ReleaseEngineering/Buildbot Best Practices (view source)
Revision as of 21:53, 21 May 2009
, 21 May 2009→Check-in Policies
| Line 7: | Line 7: | ||
== Check-in Policies == | == Check-in Policies == | ||
* '''Patches should not be landed during code freeze periods''' | |||
* 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. | ||
* 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. | |||
* If you have a patch that affects multiple masters you should update all of the masters when you land your patch. | * If you have a patch that affects multiple masters you should update all of the masters when you land your patch. | ||
** This is less strict for staging masters. Eg, you shouldn't update a staging master if someone is currently using it. | ** This is less strict for staging masters. Eg, you shouldn't update a staging master if someone is currently using it. | ||