Written by Technical Consultant Stewart Osborne Linux Automation specialist, RedHat Certified Engineer and DevOps Practitioner.
One of the core principles of the DevOps movement is that of increasing the “flow” of software from development through to production. Decreasing the lead time for features to be deployed is a large part of what allows truly agile organisations to respond quickly to opportunities in the market and out-manoeuvre the competition.
When it comes to increasing the rate of flow, an organisation’s choice of version control software can often prove more of a constraint than an asset. Problems like snowballing storage costs, delays in branching & merging processes, and a lack of integrated automation can lead to ever-increasing lead times. Development and testing work is tempered by delays in branching, merging and deployment of code and – as is the case with so many core technologies – the longer it is in place, the worse the problems get.
Here at DevOpsGuys, we’re huge fans of Git. There are a number of reasons for our love of this brilliant version control software:
- Git handles Branching and Merging very efficiently, allowing new branches to be created instantaneously and with minimal storage & compute requirements.
- Git has well-supported integration options for most commonly used build, deployment, and automation tools.
- Git leverages a distributed version control model, increasing code availability and maximising recovery options in the event of a failure.
These advantages give Git the ability to accelerate the rate of deployment by allowing for increased parallel development & testing work to be completed. This blog is intended as an overview of things to consider when planning to migrate your version control software to Git. I’ve tried to include as many hints and tips as possible, based on lessons we’ve learned over the years. No two organisations are the same and Git migrations will be unique to a plethora of factors, but we’ve found the guidelines below help us to be successful in the switch to Git.
Involve all the right people – Yes, all of them!
Depending on the implementation of your existing version control tool, it will be necessary to include representatives from various different delivery teams to coordinate the migration to Git. Identify relevant stakeholders by gathering metrics on the use of version control in your organisation. Determining which users and teams currently use your existing tool should give a good indication of who needs to be represented in the forthcoming migration planning meetings.
Establish a group of stakeholders that are able to represent the interests of all of your version control users and the systems which directly utilise the VC tooling. Remember to include representation from relevant security and access control teams to establish how Git can be integrated with any existing LDAP/AD solutions. Desktop and user support groups should also be represented to discuss client software rollout of Git and your choice of IDEs. This group will have the relevant organisational knowledge to understand the potential impact to each delivery team for each stage of the migration and should be able to highlight potential constraints in advance, to minimise disruption.
Give your group a name. Set up regular meetings and start planning your migration to Git.
Scope and Scale – Identify and visualise the work!
Depending on the size and maturity of your organisation, changing your version control tool has the potential to be one of the most complex and disruptive changes that you could make. It is imperative that the scope of this change be well understood before work begins, in order to minimise disruption caused to the organisation. All relevant teams should ideally be involved in – or at least aware of – any ongoing work towards the migration to Git from the beginning.
When scoping a transition to Git, begin by mapping your software delivery pipeline in its entirety from a high level, and identifying the various functions that your existing version control software performs for you. I would always recommend performing this as a workshop or series of workshops, with representatives from each delivery team present to feed in relevant information.
What you will likely find is that your existing version control tool is more tightly integrated into your organisation than you realised. Not only are developers and engineers using the tool to commit new code, but various stages of software build & deployment processes are likely dependant on this tool.
Areas that are often overlooked include:
- Build and Deployment scripts that reference code repositories
- Automated testing “hooks” for code commits
- Integrations with 3rdparty tools like Jenkins, Octopus Deploy, Jira, Slack, etc
- IDE selection & integration
Each of these areas will yield additional pieces of work which will need to be completed in preparation for a migration to Git. This should give you a draft backlog with which to start your migration work and give you an idea of the time and effort required to make your Git migration successful.
In part two, Stewart talks training: When should your git training begin and who should be included in this training? There’s also a handy list of recommendations on what your training should include.