Moving from TFS(vss) workflow to Git Part II

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.

Moving from TFS(vss) workflow to Git Part I

Here at work we currently use TFS for, well, everything.  We have made the wonderful -some would say only responsible- decision to move to Git.  This decision will require all manner of stuff to happen.  In this post, I will explore the developer experience.

We currently have certain workflows for check-ins, merges, etc. that are based on the insane way that TFS encourages you to do these things and these workflows will not work with a respectable source control system.  So, first I will lay out the way we currently do things.

We have a relatively small team: three backend developers and a frontend developer.  None-the-less all of us tend to be working on different things at any given time.  We all check in to our Dev branch whenever we feel like it.  We do not employ CI so the state of our Dev branch is never really known until you get latest and build.  Fortunately, it tends to be in pretty good shape despite the absence of procedure or control.

The fun begins when we want to move our code into a QA branch.  The technique we use is to merge specific change sets.  As I mentioned, everyone checks in their changes ad hoc, meaning that everyone is in a different state of readiness.  So, when we want to merge up to QA one person’s changes and not the rest, we look at all the change sets and try to distinguish,  either by reading the commit message or by actually looking at the code in the change set, which are the appropriate change sets to merge.  This process is repeated when we move from QA to Prod.

On the one hand, this seems like an insane proposition that veritably begs for disaster.  On the other hand, due to the hard work and diligence of the team members, we make it work which facilitates our siloed development of different features and bug fixes.  As this is a rather ingrained workflow that has been in place since long before I joined the team, our switch to Git will have to permit some facsimile of this process without polluting or perverting our new source control system.

In the next post I will outline some of the practices that I believe will allow us to be successful with Git.