Build Reports For the Project Team
Reading through Jez Humble and David Farley’s new(ish) book “Continuous Delivery” at the moment. It’s just great to read a book where the authors are really speaking your language. The concepts are simple and correct. There are aslo a few new ideas in there that I’ve not thought of before. But most of all I like the way it gets me thinking about how to implement some of the concepts in a “challenging” atmosphere. Not all companies understand the value of Continuous Integration, let alone Continuous Deployment/Delivery, but this book lays out the concepts in such a simple, straightforward way that it seems hard to believe that anyone would not see the advantages in them.
I picked up on one idea which I’d like to start implementing ASAP – and that is to provide feedback to project teams about the state of the builds and environments involved in that project, throughout the whole project lifecycle. I think that might help the rest of the project team understand the importance of delivery, by drawing attention to and raising awareness of the builds and the deployment environments. I can well imagine that some project team members won’t even know what they’re looking at when they’re presented with a build report, but there’s no reason for this. Everyone on the project should be interested in the build reports, they should have a vested interest in the quality of the code and the state of the deployment environment. These are real, tangible things, not abstract concepts, so they should be presented as real, tangible things for everyone to see.