I just came across this post at Atlassian about workflow automation: Using GreenHopper to Automate Bamboo & Bitbucket (“What the whaaaa?…”).
What put a smile on my face was that just recently I’d introduced to the team the notion of creating a new branch for each ticket they work on, and naming the branch after the ticket – so it’s encouraging to read in this article that that is how Atlassian also suggest doing it. I’ll definitely make more time to read their blog from now on 🙂
The rest of it gives food for thought too – we don’t use the GreenHopper board yet so I don’t think we can implement this ourselves, but the idea of automating the basic GIT functions that the team need to do is appealing. The branch is made for you, so there would be no risk of typos in the name that need to be fixed. The branch is then automatically kept up to date with the master, which is great mostly for the newer team members who might forget to do it themselves.
Then as you complete the ticket the branch is merged into master and closes the branch. Well that last bit is the part where I’d have most trouble I think – it needs me to relinquish control on quite an important part of the process. I treat merges into the master with great respect, and I don’t merge into master unless I’m about to push that work live, because I think that leaving undeployed code in the master for any length of time is a risk. So the idea of something doing that merge for me is a little unnerving. I’m also left wondering how would conflicts be resolved, when the merging is done in the background.
Does anybody use this set up? How does it work for you?