When we implemented the Trunk-based deployment flow, our pipeline to prod sped up a lot. This was really cool, but at the same time, we were producing more code than the QA team could handle, preventing us from deploying specific features to production if there was something already in the queue. We kinda solved this by creating feature branch deployments, but the problem was devs merging to QA instead of deploying the testing envs, causing the issue again.

At some point, I decided to take action on this matter, as the CTO had complained about it several times in the past, and it was time to solve it. After a few hours of evaluating our deployment process, I figured out that our issue was not giving enough participation to the QA team in the process. QA was in charge of E2E testing and automation but was not directly involved in deployments.

The next day during our daily meeting, I pointed out my findings and said that, in order to prevent any further issues, what we needed was to empower the QA team by giving them more participation and decision-making power regarding the deployments. The old process was focused on devs, as we are the owners of the tasks from the moment we move them from TO DO until the definition of Done is met.

Instead of devs deciding when to merge something into master, what I proposed was that after code review approval, the tasks are assigned to QA, and they decide what to do: either merge it into master and test it on the QA environment if they consider it simple enough to test, or deploy a feature branch environment for more complex features. This small change guarantees that our process works seamlessly by allowing QA to decide when something is ready to go. The moment QA says it is good to go, they can immediately promote it to production.

Another nice change introduced was giving more context to QAs by sharing the PRs with them and, in some cases, assigning the code review to them instead of a senior dev. Obviously, not all of the PRs are assigned to them for code review, but now they are aware of what the change is about and the impact it has. In the past, some of my tasks were reassigned to me because QA claimed my code made the checkout or another important part of the website inaccessible, but most of the time, we figured out that those issues were already in production but no one reported it until that moment.

To make everything match, what we do is use the Task ID as the branch name. In that way, QA can find and read the code, decide what to do for testing, and ultimately, merge it to master and deploy. Even though the QA team is now responsible for deploying new features, it is still the responsibility of the Devs to make sure their tasks meet the Definition of Done.

It is great to see how, by introducing small changes to our deployment process, we were able to remove the issues we were experiencing and that the QA team can participate more actively during the process, adding more value to the business.