6

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?

Ricardo
  • 153
  • 6
Matt Cashatt
  • 3,315
  • 5
  • 24
  • 35
  • [Related question on StackOverflow (TFS Feature Branching)](http://stackoverflow.com/questions/7697177/branching-for-releases-features-sub-features-and-environments). – Mike Oct 22 '13 at 17:05
  • Thanks @Mike, that was really helpful. So I guess that the subject of my question is development of a "branching strategy", yes? I will use that to google and figure out if there are any well defined patterns/strategies out there. Thanks again. – Matt Cashatt Oct 22 '13 at 17:08
  • Here is another link on SO that was helpful (see the first answer): http://stackoverflow.com/questions/34975/branching-strategies – Matt Cashatt Oct 22 '13 at 17:11
  • 3
    The key in all this is that production code has its own branch. So when QA/QC approves the development branch, it gets pushed to a separate production branch. When you need to hot-fix, you branch off off the production branch. Development is left untouched and any unfinished work in development will not interfer with the hot fix ... – Marjan Venema Oct 22 '13 at 17:11
  • Thanks @MarjanVenema. That is now becoming embarrassingly clear ;). – Matt Cashatt Oct 22 '13 at 17:13
  • We all had to learn it at some time. Most of us the hard way... – Marjan Venema Oct 22 '13 at 17:14
  • If you don't learn the hard way you don't have the horror stories you'll need to teach the new guy. – Mike Oct 22 '13 at 17:19
  • 1
    your question is [answered here](http://programmers.stackexchange.com/a/191194/31260): **"The problem is that you are using a single branch for multiple purposes that are conflicting. You are doing release packaging, low risk fixes, _and_ high risk fixes in the same branch..."** – gnat Oct 22 '13 at 17:22
  • 4
    TFS 2013 supports git, so you can use http://nvie.com/posts/a-successful-git-branching-model/ – Wilbert Oct 22 '13 at 17:38
  • I'd like to add that, when using git, `git add -p` could be useful too for some quick change – Sebastianb Apr 12 '17 at 17:24

1 Answers1

2

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.

Ricardo
  • 153
  • 6