On Streamlining Merges and Builds

SONY DSC

The author doing a CVS merge.

It’s not often I blog about my job, but I’ve taken inspiration from the idea of writing more about technical challenges.

I was musing the other morning as I was preparing for a merging session, how what used to be a long winded manual process at the command line has been reduced to a single click in a web browser for each project, thanks to BitBucket’s merging ability.

The old way we did things would involve a command line merge in our legacy version control system, which is CVS. But on our team we’ve been making the move into Git, with builds and unit testing automated with Jenkins and Artifactory.

Anyone who’s used CVS will know what this is like. Having to specify which points in the timeline you’re merging between, the manual resolution of conflicts, sometimes even from CVS’ own tags which it rewrites within each file! The long wait to commit your merged code into a busy central repository which only allows one lock at a time. Rince and repeat for a large project with lots of modules and development branches and you can lose a whole morning.

After using Git for personal projects, I found CVS’ interface at the command line cumbersome enough to write my own tool in my spare time to improve the experience, but I looked forward to the time when we could make the move to something more modern.

Our team had wanted to move away from CVS to Git for a while, but there were always roadblocks which seemed to get in the way. A lack of time and / or team members to work on this. The need to first of all implement our modules in Artifactory. The time team members needed to learn these new technologies.

But thanks to the clever people I work with on our team, and some clever and helpful people on other teams who had already made the jump with great success, we’ve managed to work past many of these roadblocks.

What struck me about where we were before and where we are now is the sheer amount of time we stand to save. Before, a manual merge could take hours followed by the time to produce a build which involved pulling files back down from our heavily used CVS repository in London.

And now? We don’t even need to touch the command line. Development branches in Git can be reviewed within BitBucket directly in a web browser using pull requests. And the merge? It’s a single click of the “Merge” button and the job is done. I’ve not even yet come across a BitBucket merge which needed manual intervention to resolve a conflict.

And then there’s Jenkins, which goes ahead and updates the snapshot of the current build by itself, so if we want to check out the builds it’s now instantaneous with no need to even hit the repository directly. Amazing.

Releasing a customer build is a little more involved, but again doesn’t involve navigating the command line. Completed builds are automatically packaged as RPMs for easy deployment. It’s becoming incredibly streamlined.

I do wonder if future team members will lose the opportunity for experience they could gain from doing these kinds of things as manual processes. There’s something to be said for understanding what’s going on beneath the hood when things are less automated. But, this is offset by the fact that we can release builds more frequently, which means quicker deployment of new features and fixes for the customer. We’re still a way from continuous end-to-end deployment, but the dream is within reach!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s