As I said in an earlier post, at SRMvision, we use feature branches to isolate our work and be able to publish it to our production environment with a clear change history.
One thing we use since the beginning (at the subversion time, pre-git era), is the control of our ticket tracker (Trac) from our commit messages. We have the following verbs to control our tickets (synonyms are available, but we rarely use them) :
- see #NUM to link to a ticket
- fix #NUM to close a ticket
Repository references to commits are automatically added into ticket's history in our Trac instance.
To be sure of the quality of our code, we set up a custom workflow in Trac. Once a dev/bugfix is done, we set the corresponding ticket to the "Testing" status. The next step is simple, either the test passes and the ticket is closed, or it does not and it returns to the developer. So, we added another verb to our commit handler : "test" to automatically set a ticket to the "Testing" status.
Our adoption of feature branches has forced us to rethink our workflow. Passing a ticket to "testing" while it is not even merged into our "testable" branch was really polluting Trac. That's why we added the status "Fixed on branch" to allow us to differentiate really testable ticket from not ready ones.
We finally adopted the following mecanism, keeping only our three verbs (see, fix, test) :
- test on a branch other than master, ticket's status is set to "Fixed on branch"
- on a branch merge to master, "Fixed on branch" tickets are reopened and set to "Testing"
- on the branch master, test sets the ticket to "Testing"
On a classic development, we can have 50 "Fixed on branch" tickets that automatically pass to "Testing" once merged onto master. Using this technique allows us to check if every single ticket related to the feature has been correctly handled from development to quality testing.
If you want to deploy a similar technique in your environment, files we are using are available at the following address : https://github.com/CedricGatay/sandbox/tree/master/trac-git-hook
You will find the following files :
- post-receive : git hook, to copy into the hooks/ directory of your "central" repository (the one connected to Trac), triggers delayed launch (1 minute later) of the next script (avoiding to block the commit),
- trac-post-commit-hook : Trac hook parsing commit messages to control tickets
- trac.options.ini : excerpt from Trac configuration file allowing to customize workflow
Please notice il will be necessary for you to edit script settings referring to git repository in Trac (called 'git-clone' for us) and paths corresponding to your environment.
