Search code examples
gitbranchworkflowrelease

Git workflow to test feature branch

I am looking for some guidance on how developers can test their own feature branch in a new Test environment. We have set up a new TEST server / TEST Database and we would like our developers to test their feature branches in this environment. This is how we envision the workflow.

  1. Developers will create their feature branch from master branch.
  2. Once they are ready to test their feature, they will merge into develop branch (no peer reviews) and build and deploy to TEST server from this develop branch.
  3. Once they are happy with their testing, they will create a PR from their feature branch to merge into master, after peer reviews.

Is this approach feasible ? We have 5 to 6 devs in our team. Currently each developer deploy directly from their feature branch to this TEST server and that causes the changes by developer overwritten by the others. So we thought of adding this develop branch to avoid the issue mentioned above. One issue I can see with this approach is if both Dev A and Dev B wants to test their changes and if Dev B's changes causes the app in Test server to crash. Then Dev A has to wait for his testing until Dev B fixes the Test environment. Any pointers in the right direction would be helpful !

Solution

  • Your workflow is fine. Some suggestions:

    1. Obviously you can call your branch names whatever you'd like, however, I would recommend calling your test branch something other than develop, only because that name is a standard branch name used in Git Flow, where it is intended to be the starting point for new development, and will always be merged into master, eventually. People familiar with Git Flow might think develop means something other than the way you intend to use it. I would suggest you instead call it next, which is what the maintainers of Git call the test branch you describe, in gitworkflows.
    2. Reset your next branch periodically from master so that all the test code that doesn't make the cut gets purged. Depending on how long it takes to validate the code you can shorten or lengthen your reset frequency. At my company we currently reset next every Sunday.
    3. When developer's branch off of master for new work, if master is ahead of the last time next was reset, when those branches merge into next they will bring in all the new commits from master along with the new commits to be tested. Depending on how the merges are done, this may cause confusion (for example in the context of PRs into next). If you are using PRs for that merge and the additional commits are muddying the change list, consider having them merge in the latest master first, followed by a merge of their own branch so they can isolate their own changes in a separate merge.

    Tip: When one developer breaks the build of the next branch, if they cannot immediately fix it, the easiest thing to do is simply revert the merge commit of their branch, which effectively undoes their merge.