| |||||||||||||
ELC: SpaceX lessons learnedELC: SpaceX lessons learnedPosted Mar 8, 2013 0:44 UTC (Fri) by giraffedata (subscriber, #1954)Parent article: ELC: SpaceX lessons learned
In his team, they have a full-size Justin Bieber cutout that gets placed facing the team member who broke the build I've been part of projects in the past where people were paralyzed by fear of breaking the build - where they spent unjustifiable amounts of time developing code just to avoid Justin Bieber. A better approach is to have the code control system automatically detect the build breakage and back out the change that caused it, send a polite notice to the person responsible for the change, and let work proceed. It's also helpful to pay some attention to what makes the build so fragile.
(Log in to post comments)
ELC: SpaceX lessons learned Posted Mar 24, 2013 18:19 UTC (Sun) by jedbrown (subscriber, #49919) [Link]
Tweaking workflow can also help make new features much less stressful. For example, if you use topic branches with a 'master' and 'next', most merges with a chance of breaking are to 'next' (topics only go to 'master' after having "cooked" in 'next' for a while). Since no other developers base their work on 'next' (it's really just used for integrated testing), a broken 'next' is far less disruptive than a broken 'master'. Additionally, reverting a merge on 'next' does not imply messy history because 'next' is rerolled after a release.
|
|||||||||||||