I struggled in how to phrase my question, so let me give an example in hopes of making more clear what I am after:
I currently work on a dev team responsible for maintaining and adding features to a web application. We have a development server and we use source control (TFS). Each day everyone checks in their code and when the code (running on the dev server) passes our QA/QC program, it goes to production.
Recently, however, we had a bug in production which required an immediate production fix. The problem was that several of us developers had code checked in that was not ready for production so we had to either quickly complete and QA the code, or roll back everything, undo pending changes, etc. In other words, it was a mess.
This made me wonder: Is there an established design pattern that prevents this type of scenario. It seems like there must be some "textbook" answer to this, but I am unsure what that would be. Perhaps a development branch of the code and a "release-ready" or production branch of the code?
Best Answer
In my organization, we always tag each production deployment in the repository. Since we use SVN, this tag can become a branch if required, by just committing changes to it. That's exactly what we do if there is a bug in production that needs an immediate fix. In that situation, we check-out a clean copy of that particular revision (the production version) to one of the developers workstation, make the fix, run all the tests and, if all is ok, we deploy the application. Then we commit the changes back to the repository turning the production tag into a branch. That commit becomes the latest production tag.
Once the emergency is solved, we merge the fix back into the mainline and kill that production branch. The production branch becomes a regular production tag again. It can only become a branch if such an emergency happens again.
I'm not sure how easy would be to the same using TFS, but the important lesson here is that you need a stable revision to deploy to production. The current production revision are stable by definition, so you just need to tag them so you can work on them when an emergency comes up. It is also important that you are able to easily set up clean working copies from any revisions in your source repository.
What's important to highlight is that you should never deploy code that isn't ready for production. In the case you described, you should work off of the version currently in production to fix only the particular issue that created the emergency, and not use whatever code is in your developer's current working copies.
Finally, to answer your question, the main software configuration pattern that I think you should follow, which is the base for the method I described above, is called Release Line, following Stephen Berczuk's great book titled Software Configuration Management Patterns.
Edit: I should also give proper credit to Marjan Venema who mentioned a similar approach in a comment that I had not read until now.