Source control management
Posted on 2012-08-12
I have started a new job as a web developer for a company that has a very unstable and mission critical web application. ¿
It is a very large and complex system that has been added to over the years and as such has become extremely brittle, easy to break and hard to find the reasons why.
My question revolves around source control management. I’m looking at totally restructuring the way in which all our development, testing and deployment is done.
Small enhancements and minor bug fixes are currently put through a UAT environment and then into live. There is absolutely no source control in place at the moment. I need to implement source control!
All changes have to be signed off by the owners of the changes. This is done by Marketing and other departments or people using CSI (bugfix) software. Signoff does not always occur in a timely fashion. I’m am looking for a mythology for source control that would enable me to manage the release and testing of these items that require sign off.
I’m trying to avoid the situation where a release is held up because one or more people have not signed off on the work done. I’m also not keen to create a million branches and only merge the ones that are needed in.
My first thought is that there is a weekly release cycle for all non-critical bugs and minor enhancements. This code would be managed on its own branch. This would mean that all bugs and enhancements on this branch would have to be signed off my the owners in order for the release to occur.
If anyone else has any ideas or examples of how they manage similar situations in their shop it would be great to hear from you.