How does QA work with trunk-based development?

Question

When doing Trunk-Based Development what gets deployed to QA environment and when?

Let's say there are two commits with Feature A and Feature B on the trunk. Should QA manually choose to make a build from commit with Feature A and deploy to QA server? What happens if a bug is found in Feature A? A fix would come to the trunk after the Feature B, therefore the next build deployed to QA would also include Feature B. Should QA then test Feature A and leave Feature B untested in that particular build?

Or should we always deploy the latest build from the trunk to QA with all the latest features included? But in that case, as developers are pushing new features non-stop to the trunk, more and more features would end up in QA after every new build and the testing would never complete and nothing would ever be released to production.

Answer 1

There are a variety of different approaches you can take.

If you're producing periodic releases (such as providing software to others), then the most common approach is to merge into trunk after passing some set of standards (tests, code review, etc.) and then when you're ready, create a frozen branch off of that where you perform QA tests and apply any bug fixes that are necessary. This usually necessitates having feature flags so that developers can merge portions of code that remain inactive until they're finally ready.

If you don't have periodic releases, then typically the approach is to require all requirements (including QA) to be met before merging. You may still choose to allow inactive code to be merged incrementally, but you may need QA approval before merging code that turns the feature on. So you'd run a build against the branch and send it to QA for testing.

Some organizations that do trunk-based development don't do QA and have developers be responsible for their own code. This is common in organizations which provide software as a service. Usually teams are assigned subsystems and changes to a subsystem require that team's approval. Because the developers are responsible for the maintenance and deployment of their entire services, they are incentivized not to cause or permit incidents that they themselves must respond to.

All of these approaches are common; however, you can really apply any approach here which meets your needs as an organization and also meets the needs of both your developers and QA folks. If you're not sure about the best approach to take, come up with some possible approaches, and talk to some senior developers and QA folks at your organization about what will meet your needs best. And also remember that if you come up with an approach that doesn't work, you can change later to a different one that works better.