What happens after the build is finished?

From CitconWiki
Revision as of 15:12, 20 October 2012 by Markoa (Talk | contribs) (first draft of notes)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

how are red or broken builds treated in your organization?

how do you deal with the situation where the person who broke the build simply ignores it?

example when bad commits and deploys triggerred system failures - a neutral post-mortem or two later, the person who caused it began to be more cautious

forcing something on people can never work, they need to be in a position to realize that they have a problem

how to assign responsibility?

  • dashboard on a tv
  • hall of shame
  • hall of fame - invert the logic, show the people who break the build the least first
  • build engineer coming to a person's desk
  • the core problem that remains is that people do not feel responsible
  • sometimes it's the separation of "coders" from "testers" that creates opposed camps

make them feel the pain by putting some constraints and assigning responsibility, eg schedule demos that they need to show

projects can work out better when the team is small (eg up to 4 people)

see http://adam.heroku.com/past/2011/4/28/scaling_a_development_team/

but another problem rises when there are many small teams that do no communicate that well any more - you have to align them somehow...

people are infinitely more complex than code, yet we're having such difficult time dealing with a big code base alone

deployment

  • prezi developers have automatic deployment to staging
  • how do you deal with releases that introduced changes to the production db in the context of automatic deployment? no magic solution, must restore somehow perform a restore
  • pierre uses django which has feature rolls(?) so there are no feature branches, new stuff is always deployed but disabled at first