Source Control & Development Workflows
It’s been a while since I have written a technical article on our blog, one which doesn’t relate to current business affairs, however one area I am quite particular about when it comes to software development principles is source control. We refer to source control simply as a form of revision control on our code base which ensures strict control over iterative programming across teams within a software development environment.
Without delving too much into the technical details there is a pretty decent article at http://git-scm.com/book/en/Getting-Started-About-Version-Control which covers this.
There are many frameworks and flavours of source control, we originally adopted a self-hosted system based on Subversion (also known as SVN) which was what we referred to as a central VCS and gradually migrated towards a distributed model with Git which is hosted on our private repositories within the cloud-based service, BitBucket.
So enough about the history, what are we actually doing with all of this? Well our source control processes and procedures govern our day to day development and ensures that we don’t end up crossing wires across teams, functionalities or features. The method of committing changes to the central repository during development is quite straight forward and essentially sequential, where things get tricky is when you have a number of parallel activities occurring within the same project by different people. At this point we need to have a clear distinction between the production code running on the live system, the new “untested” code being developed for a new set of features and possibly a number of “hot-fix” implementations being carried out against the live system to resolve identified issues. Now take those scenarios and multiply that by the number of active projects within the organisation and you have a minefield of development tracks, if not managed correctly, could have disastrous consequences.
There are a few workflows which we can adopt for this methodology. We originally used a centralised model whereby all of the commits made by each member of the team were merged together in the central repository. This would often result in merge conflicts which we would have to resolve using code differential tools but ultimately it would facilitate a number of team members working on the same code base, as per the illustration below.
We then moved away from the centralised model, to a feature model, whereby a new branch was created from the central repository (known as the master) for creating new versions of the application or dealing with support fixes. This would allow us to develop those features or fixes in isolation and merge them back into the central repository once we had tested, accepted and deployed these features, as per the illustration below.
We now work with a far more advanced model which caters for on-going development, features, release preparation, releases and separate “hot fix” scenarios. Similar to the branching workflow above, this workflow identifies prescriptive operations for branches from the central code base, the difference being that we do not merge all features straight back to the “master” branch but actually identify a new master known as the “development” branch (in orange within the diagram below) where all features are merged into as development progresses. Once we are satisfied with the development of features on the development branch we will prepare for a release, however we add a new stage to this by creating a branch from development called the “release” branch (identified in yellow within the diagram below) which allows us to do final fixes and preparation for deployment of the new version of the application. It is at the point of concluding our release activities that we merge the changes to the master branch and tag that merge operation as a specific version (identified in green within the diagram below). The final scenario we cater for is if there is an issue identified in a particular version which has already been deployed, we skip the development branch in this process by creating a “fix” branch (identified in purple within the diagram below) which allows us to specifically target a quick fix and merge that change straight back to the master branch, effectively creating a new version. We also make note to merge the fix into the development branch so that it is addressed in a future release as well.
As you can see, as a company we have been through quite a few evolutions of source control and development workflows and we are always assessing how we carry our development within the team and looking for opportunities to improve and optimise in order to ultimately deliver our solutions in a controlled fashion whilst giving us the confidence that we are able to support a wide variety of real world scenarios when it comes to software development projects.
I encourage all aspiring developers out there to not only make sure they are technically proficient in programming and software development but also in software configuration management as it is arguably an equally essential skill to have a fundamental understanding of when you want to operate within a development team creating professional software solutions.