Source control management

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.

Who is Participating?
Eddie ShipmanConnect With a Mentor All-around developerCommented:
We use a combination of SysAid, for trouble and enhancement tickets; and Mercurial with TortoiseHG Workbench (we develop on Windows machines).

I came from a desktop development environment so I was used to the strange release cycle paradigm and it has worked out for us greatly. We have 4 servers setup like this:
1. one server for as marketing's sandbox to test their content changes
2. one server for use as our (development) sandbox to test cool new enhancements and other changes to the functionality
3. one server for beta testing anything that will go into production. when a release is done, it is basically identical to the production server
4. the production server.

The notification or signoff, so to speak, comes from SysAid ticket comment and status changes.

Hope that helped you.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.