Our Git workflow and Build Process - Part 2

In a previous post I discussed our Git workflow.   In this post I am going to discuss how our build process works with our Git workflow.

To recap here is our build process, Figure 1

Figure 1

As we work on features we are always in a feature branch.  So for example, web-11 is an actual feature branch that we completed.   So when we worked on web-11 we committed changes to it.   As we commit two git hooks come in to play.

Here is a picture of the git hooks, Figure 2

Figure 2

These hooks are installed manually into the repositories hooks folder.   Both of these hooks are simple .NET 4.0 console applications.    To ensure that Git can call the hooks you need to remove the file extension (remove .exe).

commit-msg hook

• The commit-msg hook simply adds the name of the feature branch into the commit message.   
• I put the feature branch name at the end of the commit message in between pipe characters, just for easy parsing.  So |web-11| will be at the end of the commit message.

post-commit hook

• The post-commit hook looks at the previous commit,  and parses the feature name.   
•  Once it has the feature name it gets the files that occurred during the previous commit and writes each change to the database, tying each change to the issue key in the commit message.
•  I am using the wonderful library LibGit2Sharp to get the information about the commit.   I can post the code if anyone desires.
• Our database code is in a database project within our solution.    I check to see if any of the files checked in are part of the database projects path and if they are I update a field saying whether it is database code or not.
• I add everything about the commit to the database,  files added, modified and deleted.

Build Process
At this point you can see we have the following information for each committ;

• We can easily query our database to see what code was committed for each issue.  
• We can see what files were added, modified or deleted for any issue.
• We can also see what files are database code because we have marked a flag on each row.   I also log the path to the file committed, so we could tell if the file is database code or not because it would live within our database project path.  But it is easier to have one field we can query to find this information without parsing the filename.

As I mentioned in part I of this series,  we use Bamboo to perform our builds.     Bamboo is a great tool for build automation.    If you don't have access to Bamboo you can still do what we are doing.  Under the hood Bamboo is simply calling MsBuild to perform our builds.     I don't mean to simplify Bamboo here, because it does provide many wonderful features, but under the hood it is calling our MsBuild scripts.

Build Process - Database code

So when we build to our qa environment we know that our qa branch has all the features we want to deploy to qa  (see part I).   This means we can use MsBuild to build our qa branch and deploy the code but what about our database code?  How do we build that?

Here is what we do:

1. We note which features were merged into the qa branch (web-11, web-19,etc).
2. We enter those features as variables in bamboo.  These variables are passed to our MsBuild task as parameters.
3. We created a custom MsBuild task that performs the following job;
1. Query the database for the features that were passed into the build.
2. Get the database code for the features.
3. Execute each of the database code features against the database inside a transaction

Microsoft.SQlServer.Management objects to the rescue
That third step took me awhile to find the best solution for us.

I looked at various technologies for executing database scripts such as ADO.NET or the sql management studio command line.    Both of these technologies had limitations, for example ADO.NET had difficulty with scripts that contain go or using statements.   The sql management studio command line couldn't execute each script within a transaction.

So what to do?   Google saved the day of course.  The Microsoft.SqlServer.Management objects to the rescue.   So our custom MsBuild task uses the Microsoft.SqlServer.Management.Smo.Server object to execute all database changes within a transaction against the database.

So that is how our git workflow and build automation works.   If anyone is interested in the code let me know and I update the post or add a new post with the code.

Thanks for your time.