What happens after the build is finished?
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
