This project has moved and is read-only. For the latest updates, please go here.

Branching Plan for SAAS Application Maintenance Team

Oct 17, 2014 at 4:11 PM
Hello,

I am completely new to branching and I am trying to figure out which strategy best suits our existing deployment process. We are a team of 5 developers working on an SAAS app. We practice kanban Agile development. Our application was developed in classic ASP. We do not develop new features for our application but we do a lot bug fixing and code refactoring and maintenance. We also do a lot SQL Server Stored procedure, User defined functions refactoring and creation. We do weekly deployments of our changes to the Live environment. We use TFS for source control. Here is our deployment process,

1) After fixing bugs or creating/refactoring a Stored procedure for an ASP page , it passed to another developer for code review
2) If it passes Code review, it deployed to QA test environment
3) If it passes QA testing, it deployed to a Prelive environment for further regression testing
4) It is deployed to the Live environment once signed off by QA

While different tasks/bugs are being tested by the QA team, more development work is going.

I have downloaded and read the version control guide by ALM rangers and am a bit confused as to which branching plan to adopt.

So far, I am considering one of these
1) Branch by Code promotion
2) Basic branch Plan – (We will have a Main Branch, Dev Branch and a maintenance branch for hotfixes)

For the Basic branch Plan, Bug Fixes will be done on the Dev branch and deployments done from the Main branch .Any bugs flagged up after deployments will be fixed in the Maintenance branch.

I am abit confused with the Branch by Code promotion. I considered it because I felt it closely resembled our deployment structure.I know it involves promoting a codebase from Development to QA and then to production as they become more stable at each level. My other question is once a codebase is promoted from Development to QA, can new development start in the Development branch and then FI to the QA branch?

Here is our TFS structure
$/TeamProject1
Database – contains Stored procedures, UDFs, delployment scripts
WebServices – One solution with 25 VB.net projects with interdependencies
Windows Services - One solution with 10 VB.net projects
WindowsScript
Website – Contain two different website.One for our EMEA customers and the other for our local customers
Shared Libraries –
Third party DLLs

Can anybody make any recommendations based on all the information, I have provided? Please let me know if you need more information.
Oct 17, 2014 at 5:37 PM
Nice description of your situation. The one thing I'm unclear about is whether your team typically swarms a common problem together in a team-like fashion, or whether they split up and work on different pieces of work. Bugs tend to be somewhat isolated from one another, or if related, can be handled together at the same time. But refactoring can cross many modules and be very disruptive to others.

Regarding the Branch by Code promotion strategy, you asked "once a codebase is promoted from Development to QA, can new development start in the Development branch and then FI to the QA branch?"
Answer: Yes

One of the tricky things about branch plans is that they interact with your process. If you hold the process constant, you can easily see which branch plan is better for you. If you are willing to reconsider your process, then you have more choices. This gives you more room for creative design of the process and branch plan, but it is harder to contemplate.

From the manual
The Code Promotion branch plan will work well for your organization if you meet some of the following criteria: 
    1. You have a single major release that is running in production. 
    2. You have long running testing lifecycles. 
    3. You wish to match your branches to your various deployment environments (not required). 
    4. You want to avoid code freezes, and still have isolation for your planned release. 
Your description seems to match items 1,2,4 perfectly. So this would be a good plan. In contrast, if all members are all working on highly coupled stuff, then it is better to swarm over the code together all at once and not split up the team. This latter model would favor the basic branch plan more.

You see how the branch plan interacts with the process? Do you want everyone working on a single feature or maybe split the group in two and have one team nursing their product thru QA while the other team is doing basic development of the next feature?

The "Branch by Feature" plan supports even more fragmentation in your development effort. But it aggravates the challenges that come with multiple branches.

If you have refactoring to do that could be very disruptive, then you will benefit from something like Code promotion branch plan, where part of your team can nurse the release thru QA and onto Production while someone else does radical refactoring in Dev. Just make sure that the teams in QA and Prod only make the most essential and minor changes. You don't want two ambitious changes going on in parallel. That would make merging a headache. Imagine how disruptive it would be if a developer in the QA branch decides to start a new refactoring there. Then when they go to reverse-integrate, they disrupt the dev team in the dev branch. You should only promote it when it passes your quality checks and code reviews, just as your process describes.

Good luck.
And remember, you can try out one branch plan and then change later if it does not work well. But remember to keep an eye on the dance between process and branch plan. If it is not working, you can also ask "Should we divide up the work differently? Should we encourage more or less collaboration?" These changes are just as much fair game as the branch plan.
Oct 17, 2014 at 9:44 PM
Hello David

Thank you very much for taking out time to give me a very detailed response. I really do appreciate your help.

Please can I just answer a few of your questions to give you a better insight into our development environment?

"The one thing I'm unclear about is whether your team typically swarms a common problem together in a team-like fashion, or whether they split up and work on different pieces of work. Bugs tend to be somewhat isolated from one another, or if related, can be handled together at the same time. But refactoring can cross many modules and be very disruptive to others. "

Each member of the team works on a different bug or problem or refactoring task. Each problem/task/bug fix assigned to a developer might be in a different stages of the development lifecycle (Code review,QA testing or Prelive testing). Most times the QA team have several bugs waiting to be tested in their Kanban Queue. I forgot to mention that some of the bug fixes take priority over others. These are issues reported by our external customers and then escalated to the second line support team and then assigned to a developer. These escalations always take priority over any ongoing development work. It sounds like all these will further complicate our branching plan.

“If you hold the process constant, you can easily see which branch plan is better for you.”
I did not quite understand what you meant here about holding your process constant.

It seems like the Code Promotion plan might be the best strategy for us. If we do adopt the Code promotion plan, we are going to have one or two developers working on refactoring and other bug fixes and also dealing with feedback from QA testing and Pre live testing. There will definitely be situations when we would need to do a fix to the codebase in the QA branch. I know it will create a merging headache how else do we manage this?

Please anymore suggestions will be greatly appreciated.
Oct 17, 2014 at 10:58 PM
Forget my comment about "hold the process constant." I think it was just confusing and not worth explaining.

The important point is that you clearly understand that your choice of branching plan will affect how you divide up the work. And your choices about dividing up the work will affect the branch plan that you prefer. They are like dance partners. And other practices also interact. If your developers follow rigorous practices of TDD or at least automated testing, and do feature reviews early with the customers or their proxies, then the code will be of high quality and less likely to come back from QA. But if the developers do minimal testing and leave it to QA, then time is wasted correcting things that might have been caught early. And these long-duration QA cycles encourage you to isolate the QA release by using a branch. This is an example where improving your coding and testing practices can make a simpler branch plan actually work better.

My point here is that for a given set of practices, a certain branch plan will be optimal. But if you find yourself working with a complex branch plan, then examine the underlying sources of friction and ask yourself whether you can't use a simpler branch plan with improved processes.

I think using the Code Promotion plan should be fine as a starter. Remember, you can change later if you desire. Just keep talking among yourselves and you will learn the best combination.
Marked as answer by adaezeo on 10/18/2014 at 1:22 AM
Oct 18, 2014 at 9:22 AM
Thank you very much David for your detailed explanation and ideas. We will implement the Code Promotion Plan and hopefully it be adequate for our development lifecycle. Thanks once again for your time.