Headaches for developers… certainly something we try to avoid. Our Associate Director of Developer shares how switching to GitLab from Subversion has improved efficiencies to handle client needs.
Version control is an important part of any development process. Being able to track revisions, go back to a previous revision and separate code that is in development, being tested and in production are all important aspects of any good version control system. We here at The Buddy Group have been using Subversion as our vcs almost since our inception. In that time we’ve refined our process to make us more efficient and to better handle the needs of our clients. Subversion definitely has its limitations however, and we encountered those often.
We had been hearing great things about git for a long time, and the more we learned about it, the more we liked. There is a long list of reasons why we switched to git, and there are many articles on the web that give very convincing reasons on why to switch. For us, though, the biggest reason to switch was to have a more efficient way of handling quick bug fixes on production, or handling different feature requests that all need to be pushed to production at different times. Git handles this way better than svn. However, it’s hard for any organization, even one as small as TBG, to make significant changes in process. So when we finally decided to make the switch, we had to make a plan and get everyone on board.
Since switching to git, we have noticed an improvement in efficiencies. We can respond faster to bug fixes, and are better equipped to handle client feature requests.
Before we switched, we did some research. We had been hosting our own subversion repositories on an internal server, so we needed to find a comparable replacement. There are many great hosted git solutions such as GitHub, but paying for additional services in these tough economic times is not something that is easily sold through to the powers that be. Luckily, we found Gitlab. If you are familiar with Github, then you already know what Gitlab is. Essentially it’s an open source version of Github that you can host on your own private servers. If you are going to host your own git repositories, Gitlab makes it extremely easy to do. You get a git server that can be accessed via ssh or https and you get a slick web interface that makes it easy to create projects, assign access to users, set up deploy keys and hooks, and a whole lot more. Installation is pretty easy and there are guides for whatever flavor of nix you run.
The other key piece of switching to git was making sure we had an efficient process in place to handle all the different development, testing and deployment scenarios. We found this wonderful article by Vincent Driessen that outlines a perfect workflow for our needs. There are also some very helpful scripts that make using this git flow even easier.
Once we did the proper research and presented the solutions, the team got on board with our new git flow, and with Gitlab. Next we had to plan out how to make the switch. We have several hundred repositories in Subversion, and converting all of them would be too time-consuming, so we made the decision to convert projects based on need and timing. This allowed us to continue working on current projects without any major downtime. As the need to work on a project that’s not in git arises, we can simply convert it before we start development. Luckily, using TortoiseGit, converting a subversion repository to git takes about as long as an initial clone.
While converting the repos was one hurdle, the next was changing the deployments to point to the new git repo instead of svn. There are a number of different methods for handling deployments, and we evaluated all of them. Ultimately, we decided to just do a simple sparse checkout within the project folder. This was more in line with our existing process for deployment and allowed us to keep our same deployment scripts with only minor modifications.
Since switching to git, we have noticed an improvement in efficiencies. We can respond faster to bug fixes, and are better equipped to handle client feature requests. We have also noticed that git makes collaborating on projects much easier. Another benefit of switching was that GitLab has issue tracking built in, so we were able to stop using a third-party issue tracking software, lending to cost savings. The Buddies are all happy with the change and we now have a robust version control system and process that will last for many years to come.