locked
Process for bug fixes? RRS feed

  • Question

  • We currently are following the simple branching plan for our website project:

    DEV
    MAIN
    RELEASE

    Dev represents vNext work, MAIN represents what is currently on the QA/Staging environment and Release, of course, is what's in production.

    When bug fixes come in, what's the appropriate place to fix them? My first thought was to fix them in the environment they stemmed from. That is, if a bug is reported in production for example, we fix the bug in the RELEASE branch. That's fine, except what happens when the bug fix must go through a more rigorous QA process? I fix the bug in the RELEASE branch and check in my changes. Do I then need to Merge the changeset from RELEASE back up to MAIN, then deploy MAIN to the QA server for review? I can't fix the bug directly in MAIN or DEV, because they probably have new features that aren't ready to release yet. How are others handling bug fixes in their branching structure?

    Monday, September 13, 2010 5:19 PM

Answers

  • Sorry for the stream of consciousness here ... my above thought won't work. I tried this and had some nasty merge conflicts to resolve when I merged to MAIN. 

    What we've decided on is to create a child branch of RELEASE called HOTFIX:

    DEV
    MAIN
    RELEASE
    HOTFIX

    When we work a bug from production, we'll (FI) from RELEASE to HOTFIX. We'll then work the bug in the HOTFIX branch and check it in against a Workitem. The contents of HOTFIX will be deployed to a QA site where testers can review. Once we have signoff, we will (RI) from HOTFIX to RELEASE, and back up through the other branches. This way RELEASE maintains a copy of code that is in production, but QA has a place to review changes to production code.

     

     

    • Marked as answer by jabell Monday, September 13, 2010 9:06 PM
    Monday, September 13, 2010 9:04 PM

All replies

  • Another option I thought of is to fix the bug in the DEV branch, then merge just that selected Changeset to MAIN for review. Once the bugs are signed off on from QA, I could merge the selected Changeset again into RELEASE and push to production. Would this strategy work?
    Monday, September 13, 2010 7:11 PM
  • Sorry for the stream of consciousness here ... my above thought won't work. I tried this and had some nasty merge conflicts to resolve when I merged to MAIN. 

    What we've decided on is to create a child branch of RELEASE called HOTFIX:

    DEV
    MAIN
    RELEASE
    HOTFIX

    When we work a bug from production, we'll (FI) from RELEASE to HOTFIX. We'll then work the bug in the HOTFIX branch and check it in against a Workitem. The contents of HOTFIX will be deployed to a QA site where testers can review. Once we have signoff, we will (RI) from HOTFIX to RELEASE, and back up through the other branches. This way RELEASE maintains a copy of code that is in production, but QA has a place to review changes to production code.

     

     

    • Marked as answer by jabell Monday, September 13, 2010 9:06 PM
    Monday, September 13, 2010 9:04 PM