I am trying to introduce to my team a more sophisticated branching model than "commit to master and push".
We are a small team of two analysts, three developers and one tester. At the moment, a developer will commit their changes to master
, then build the master
branch on our test environment. They will then notify the tester that the changes are available to test.
My proposed workflow is based on this, with GitHub enabling code reviews via pull-requests on merging feature branches. Each feature or bug has its own branch created, on which the work is done. When the developer is finished they request a merge and their code is reviewed and then merged into the dev
branch.
My question is this: At what point during the new process is it appropriate to ask the tester to test the functionality? As I see it, the options are:
- The tester tests the functionality after the code has been reviewed and the branch has been merged into
dev
- Pro - the review hopefully caught some bugs and saved the tester from rejecting the work
- Con - the team has to wait until someone does the review before the tester can sign it off
- Or, the tester tests the functionality before the code has been reviewed
- Pro - the tester is able to test and sign off the work before the code is reviewed
- Con - if any changes are suggested, the tester will need to re-test the changed code
There is also the question of how the tester would be able to access the feature branch before it is merged. We use TeamCity as a deployment tool, and can specify a branch name to build - but I am concerned that it won't be clear which feature branch is currently 'active' on our test server.
So really this boils down to: when should the tester do their testing, and if it is before the branch has been merged, how should that situation be dealt with?