Friday, October 11, 2013

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.

No comments: