How should one use branches to be able to test:

  1. on local environment (during development),
  2. on a branch for testing with real environment (QA-testing),
  3. testing by customers on pre-production branch,
  4. and finally merging to production?

We have the following branches: prod (customer production branch), dev(pre-production branch), staging(for QA), and local developers' branches.

For our current workflow, we have:

  1. For development and local testing, done in developers' branches.
  2. After code review, merge those local developers' branches to QA's branch.
  3. After QA tested, merge changes to pre-production customer branch (customer will test)
  4. Customer merges to production branch.

Problems appear on the second step. For example, we have some major tasks and some tasks that can wait. And developers already have done some major tasks and those tasks are already on step 2, but suddenly customers decide that some of the "can wait" tasks need to be done now and those changes should be merged right in pre-production branch so QA and customers could test it right away. Now customer liked all changes and he merges changes to production.

After all this we have:

  1. prod and pre-production are the same.
  2. staging branch is behind
  3. developers always start new tasks from the production branch
  4. a developer tested his task and wants to merge to staging (QA's branch)
  5. also some other developers finish some "can wait" tasks and QA is already testing them, so they are in staging branch
  6. But because branches are different he might have conflicts with other developers' work. But his work is a major task.
  7. Now he needs to fix conflicts. That means to update some changes from staging in his branch and merge to staging for testing.
  8. It results in a branch which started from production and has some chunks of code from staging (that have probably not been tested yet).

What we should do in such cases? What should a normal workflow look like?

  • 1
    I'm not sure whether source control workflow questions are on-topic for pmse. I am fairly sure 'What should we do?' is too broad and 'what is a normal workflow?' is too opinion-based. though.
    – Sarov
    Feb 14 '18 at 15:01
  • This question should be migrated to sqa.stackexchange.com
    – Alexey R.
    Feb 14 '18 at 16:09
  • I'll take a shot at an answer - I don't think this has anything to do with testing or branching strategies - I'd suggest those are symptoms. We'll see if the answers helps.
    – Daniel
    Feb 14 '18 at 18:29

As the comments mentioned, questions about testing or branching strategy may not fit here, but to me it sounds like those are just symptoms. What I read from this is that you have a process and work takes N days to get through that process. However, your customer is looking to make more rapid changes. In other words, your decision cycle for pivoting to new work is longer than your customer will tolerate.

Some branching strategies and testing strategies may reduce the impact of this. For example, parallel feature branches can allow for concurrent work to impact other work less, but it doesn't fix the problem.

In Lean, we would call this a problem with batch size. To illustrate a simple example, let's say a factory makes widgets in batches of 1000. With prep and manufacturing, it takes 1 week to complete 1000 widgets. But what if the customer wants to change the widget type every 2 days. If I try to do this parallel in the same line, disaster will almost certainly be the result. So I either have to tell them no or shrink my batch size to, say, 200. If I can get 200 done in two days, new I can change widget types when my customer wants or, if they don't change their mind, just do another 200 of the same type.

Work like programming isn't exactly like manufacturing, but the same thing applies. If your batch size is too big, and therefor cycle time is too long, you need to shrink batch size of work to become more adaptive.


This is definitely a process issue. The separation of parties is causing complexities which is resulting in long cycle times. With more collaboration and modern techniques, these cycle times will decrease. With improved collaboration, they will decrease more. The way the internal members work is probably more simply addressed. Of course simple does not necessarily mean easy.

By adopting a test first mentality, the hand offs will be decreased and work will be less error prone. Collaboration is required for this to be successful. Before any work begins (feature, enhancement, bug fix, etc.), the developers and quality assurance need to design together. Begin with use cases and test scenarios; this sets common understanding and expectations. From there the solution can be designed while creating a plan for what type of tests (unit, integration, functional, etc.) are needed and how they will be provided. Practices such as Test Driven, Behavior Driven, and Acceptance Driven development can be helpful. Pair and mob programming can reduce the need for code reviews and improve shared knowledge. Sometimes more formal code reviews will still be beneficial. Don't pass tickets back and forth: sit down together and talk when issues arise. All of this also reduces the need for as many branches since development and testing are occurring simultaneously. Another internal gain can come from Continuous Integration and Continuous Deployment (CI/CD). Merges don't create conflicts, they reveal them. Mo' branches, mo' problems.

Having the customer involved is also a great complexity reducer. They can be involved with ensuring the need is understood before each bit of work begins. Requirements1 are often not enough and sometimes the enemy. The sooner the customer can review the work, the better. Context switching is a productivity killer. It can be very time consuming and frustrating to go back to code that was completed weeks or months ago, especially if technical practices for clean code are not utilized. It's best to deliver small increments frequently so that the customer remains engaged.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.