In my previous post, I outlined our current VSS-inspired workflow. Here, I will outline a Git workflow that I believe will provide the isolation that we need without the danger or overhead of cherry picking commits to merge up.
To start with, I believe we should use the fairly well established “git workflow” pattern with a few minor modifications. Most of this is outlined there, but I will address a few issues here.
At the outset, with we will have a Dev branch. This branch will represent finished features that have not yet been to QA. From this branch, each feature will branch ( as a verb ) down into a feature branch ( noun ). The feature branch will be maintained until the feature or fix is considered complete and ready to go to QA. During the developer’s daily process, the Dev branch will be merged down to his feature branch at least once a day, and possibly more often, depending on the amount of work going on elsewhere that needs to be integrated. Once the developer’s feature is completed, he will merge it up to development, making it available for deployment to QA and merging to other feature branches.
Two points to make about the above: (1) the Dev branch will always be in a state that is ready to push to QA, and (2) the reason that the feature branches merge down from Dev often is twofold. First, new completed features may be committed by other developers at any time, QA fixes and hotfixes will be being merged down into Dev, also at any time. The features will want to have an accurate picture of the Dev branch. Furthermore, frequent down merges will make the final up merge considerably easier, ( albeit at the cost of many small conflicts in the down merges. Nevertheless, this is much preferred over having a bunch of conflicts to resolve all at once ).
While I believe “git workflow” covers the QA and Prod workflow, a quick synopsis follows. At some point, someone says “Hey! I just finished my feature and would like to have it QA’d”. After he merges into Dev, he can then merge Dev into QA knowing that all features in Dev are in an initial completed state and are ready to merge up to QA. QA may find errors with the new features. The feature owner, at this point, branches off of QA, fixes the problem, merges up to QA and down to Dev, and QA tests again. A similar process is used for doing hot fixes on production. branch –> fix –> up merge –> down merge to both QA and Dev.
So, now our developers can commit all day long, as they well should, without worrying that their commits will inadvertently make it to production. Perhaps an even nicer step would be to make available an environment in which a feature branch can be QA’d. This way, the back and forth of bug fixes could take place off-line, and when a feature is merged with Dev, it will be in a much more complete state. However, I’m not sure what would be involved with getting multiple, disposable testing environments up.
One caveat is that all the features that are merged with Dev must be cleared to go into production in the same push. Once they are in the main line there is no easy way to tease them back out. There is a workflow that would facilitate this practice but (a) it is pretty much an incremental (albeit large) change to the proposed workflow so we can evaluate it later, and (b) it is somewhat complex and unless we are very sure that we need this flexibility I feel simpler is better.
In a future post I will look at some of the actual steps and commands that developers would be using given the proposed workflow.
No comments:
Post a Comment