Versioning of Code is an extremely important process in Code Development. Hence, a version control system which complements development and supports versioning, code merging and collaboration in an effective manner facilitate seamless code sharing and speeds up the entire process without the worry of even a single bit of code getting lost.
There are various versioning system(s) in the market. However, I would be sharing my experiences and learning while migrating from subversion to Git and how the one inspite of serving us for years and its wide spread adoption had some shortcoming(s) and the other we’ve recently migrated and is the fast-rising star tackles our day to day issues and smoothens the process of development.
The Right Question?
The question is that after using Subversion successfully on many projects and most importantly a cost (of migration (obviously)) involved to the process we would be inclined to ask “If Subversion has met our version control needs for many years, why should I change?”. And, as topic experts and I would say, that is the wrong question. The real question is “How can a Distributed Versioning Control System (DVCS) make what I do today even better?” In the case of Git (although the same things could be said about Mercurial), it’s faster and it enables advanced workflows via features such as branching, forks, and pull requests. In theory, these workflows are all possible with SVN; however, the difficulty of merging in SVN compared to Git makes them untenable. And that is the main benefit of Git and DVCS: lightweight branching and easy merging. These enable your default SVN workflow better than SVN does.
To understand how we work, let’s have a look at how we develop code at Naukri. Following the most commonly used workflow to cater to parallel development and release we have what we call a “trunk”, the stable branch. Then we have branches & tags directories / repositories which holds the copies of working branches and released tags. We maintain and contribute bug fixes to a branch while developing new features. When we commit bug fixes to the branch we add them to the “trunk” too. Because SVN merge is known to be a pain and works solely on revision history — not actual content — a lot of people avoid it or use it infrequently and not as part of their day-to-day workflow. How many projects have you worked on where stable and development branches have started to diverge, or diverged so significantly that the effort to bring them back together is a serious project cost? I have certainly worked on projects where this has happened. And when I speak to other developers, it’s a frequent occurrence for them, too, when using SVN.
However, this is not the case with Git. It makes merging of entire branch into the “trunk” or “master” as it is called easy. In fact, it is our default branch / workflow.So, even if we do not intend to use Git-specific features immediately it starts showing from day one. And, eventually we can start using advanced workflows to cater to enhanced productivity and rollout.
Before the switch to DVCS, our products were released but achieving CI/CD was a distant dream. However, now with Git in place we’ve already got eyes on achieving CI/CD in near future.
The Migration
It’s not neccassary that the migration needs to be an overwhelming task. However, for it to stay that way we need to carefully plan, analyse and execute the steps. But before we proceed, there are things we need to be aware of in addition to external factors that would be very vital in planning.
First, it will take time. Since, the entire repository along with all the commit will be replicated.
Secondly, we should prepare for surprises because when in the battle field we should not beat ourselves if we have to kill, but the target should be to continue on with the quest.
Technicalities
Following are the steps we employed to migrate code from Subversion to Git successfully.
-
Identify the right tool
Although, git-svn is the default tool which we could have used to move the code, but after careful inspection of the code base and structure we went on to use “svn2git” which is a tiny script written in Ruby to move code from Subversion to Git while keeping the trunk, branches and tags where they should be. It uses git-svn to clone an svn repository and does some clean-up to make sure branches and tags are imported in a meaningful way, and that the code checked into master ends up being what’s currently in your svn trunk rather than whichever svn branch your last commit was in.
-
Prepare the script(s)
So, in our case the task didn’t stop at identifying the tool. We were required to write scripts (in bash, so that they can be easily executed on commandline) to speed up the process and remove manual efforts as much as possible.
-
Identify the Git Repository Management Tool
Git in its raw form in not useable for effective access control of code. In simple words to unleash the beast we need to have a perfect Git Repository Management Tool.
-
Devise an effective workflow
The entire process stands defeated in case we are not able to devise/employ a workflow that caters to the true potential of using Git. However, most importantly we need to keep in mind that we do not change the workflow too much too quickly.
-
Movement of Infrastructure
With every repository successfully ported we started moving our infrastructure from SVN to Git.
-
Updations to the release scripts / tools
Last but not the least the movement is to be considered complete once we start deploying our code from the new versioning system.
The Human Side
So, remember me talking about the external factors impacting our migration process. And, here it is that are “The developers ready for the change?”. To ensure this we also have to plan some important steps.
-
The team(s) needs to be trained
Since its the team that is going to be working on the versioning system a very systematic and well crafted training sessions needs to be prepared and conducted across various teams. The training should be crafted in such a manner that instead of an additional resistance we get full support from the team because that’s going to be very fruitful in case of any surprises during the migration process.
-
Clear picture on the migration process & status updates
Just like any other project we should have status and progress updates shared with the actual end user and it is needless to say the benefits of having that in place.
-
Git Champions
Now since we are no Superman or a Spiderman. No matter how much you prepare or how much you educate, developers will run into issues when they start actually using it. Left unattended, these issues will reduce productivity and can spiral into hostility to change.
We marked a few developers as “Git champions” during the trainings. Any time people had issues – didn’t understand something or just wanted to ask, “What did I just do?” or “How did it work?” — they could pull in a Git champion to help them. This was critical to making the change as seamless as possible.
In practice, we found the major difficulty people encountered was not the differences between commands, but the differences in the conceptual model of working copy, local repository, and remote repository. I would say it took two to six weeks for each developer to reach the same familiarity with Git.
The final words, we are now on Git and everyone is loving it.
Related Posts
Posted in General
The All-New Naukri iOS App (6.0)