The Transition from SVN to GitLab

SVN is Simple

Subversion is a source control system that is fairly intuitive, even to those not too familiar with source control.

There is the concept of “checking-in” source code to the common location so production or other developers can use your code.  The main branch is normally called “trunk”.

Branches might be used to develop a new feature or to signal development specific for a certain release.  Development can also occur in branches as well as the trunk.

Tags are used to take a “snapshot” of the code at that current time.

For developers using Windows, there are TortoiseSVN and TortoiseGit tools out there.  These provide a GUI to Subversion to make it easier to view history, check-in code, or check-out code.

Tortoise
Windows has ‘Tortoise’ for SVN and Git.

Subversion worked perfectly well for our team.  The decision to try something new occurred when we started wanting more software quality.

We Wanted More Software Quality

As part of better software practices, we wanted documentation, code reviews, and continuous integration setup with our projects.

For code reviews, another developer and I had used Code Collaborator from a previous company.  While this tool worked well, it was another thing to manage and setup.

For documentation, we used Confluence and Sharepoint.  Again, these tools work fairly well.  It was one more place to go and another tool to learn.

Documentation

Same deal with continuous integration.  We use Jenkins – yet another tool to learn.

There is absolutely nothing wrong with learning these different tools.  They all work quite well.  But when we started using GitLab, we realized we could start rolling all of these things into one platform (or at least most of them).

GitLab Offered That Quality

Are you familiar with GitHub?  If not, check out an example from one of my repos.

GitHub

GitLab is quite similar to GitHub.  It allows you to have a similar interface without forcing you to use the cloud (although I believe it has that option).  It also bakes in more features.

Right from the front page of the repo, you immediately have documentation.  GitLab also allows each repo to have its own Wiki.  Those Wikis (and the README file, which puts documentation on the front page of the repo) allow pictures and all other sorts of features.

In addition to documentation, code reviews are baked into Git source control.  By creating a branch for a new feature or bug fix, you can create a merge request when done.  When a merge request is created in GitLab, it automatically creates a web-based diff of the new changes.  Reviewers can make comments and collaborate with the author.

So in addition to eliminating the need for another tool for documentation, GitLab also eliminates the need for a separate code review tool.

Although we chose to stick with Jenkins, GitLab also provides its own continuous integration tool.  This tool can show red or green checkmarks next to your repo based on the build status of the most recent commit.

All these features are huge, because they eliminate the high barrier to entry with some code quality features, such as online code reviews or continuous integration.

Users of those features also only need to be familiar with one tool.  Everything is contained in one package.

Conclusion

The choice to move to GitLab for our team was a good one.  In addition to all the features mentioned above, we started sharing code more.  The open-source nature of GitLab helps with code sharing.

There are some tools out there that are definitely worth every penny you pay for them.  GitLab happened to be worth the cost for our company.  If you are in need of a common platform for the above-mentioned needs, I highly recommend it.  There are free and paid versions of with different feature sets.  Check it out!

Leave a Reply

Your email address will not be published. Required fields are marked *