We have now been using git as the version control software for our projects in the Professional Services Team at Univention for a number of weeks and to great success. In this blog article, I want to give you a bit more information about our decision to employ git, report on our initial, recent experiences and provide a perspective of the aspects still requiring work. In doing so, I hope maybe to provide you with a suggestion or two for your own projects or that perhaps you will also have ideas for how we can implement our requirements even better using git.
TL;DR
- Both the migration of SVN to git and the use of git as a tool in the productive workflow have gone very smoothly.
- The challenges involved in the professional introduction are considerable, particularly with regard to the preparation of the coordinated workflow.
Life before git. When SVN is pushed to its limits
In the past we used SVN, just as in product development, and were largely satisfied with it overall. Then, last year, we started a very large project in which we also cooperate with external developers. In light of the extra requirements, we seized the opportunity to construct our own SVN server in our DMZ in order to facilitate access for the external developers. At that point in time, git didn’t appear particularly necessary, especially as we already had extensive experience with SVN. Approximately a year and a half ago, at the same time as the project was beginning, we introduced the hosted project management tool plan.io, which is based on the Open Source project management tool Redmine. We worked successfully with these resources and developed around 3,000 automated test scenarios for our software, but we also encountered a whole range of problems in software development, which we had to deal with time and time again or are planning to deal with in the near future:
- It is not possible for developers to check in any half-finished changes without disturbing the automated Jenkins tests.
- It is not possible to test changes completely until they are integrated in software.
It is barely possible to track changes that belong together as other developers have made changes to the same pieces of code in the meanwhile. - In future, changes need to be maintained for two different software versions (poor traceability is an issue again here).
Luckily, Linus Torvalds didn’t just invent Linux, he also developed the premium version control system git, which general reports and our own experience so far hinted should be able to solve all these problems and offer a whole range of additional, practical features on top. As our project management tool plan.io offers direct git support, we decided to set about the migration before we had to develop two parallel software versions in the project.
And they’re off! Introduction of git and SVN migration go without a hitch
The first step in the introduction of git was the migration from SVN. In the original project, we had both the documentation and the code stored in one SVN repository. As both parts were quite voluminous, I decided to store them in two separate git repositories in the future. For the migration, we used git-svn, which makes the planned splitting of the SVN repository particularly simple. We did not experience any kind of problems with the migration. The entire history was adopted and enhanced to the git level by including the full names and e-mail addresses of all the people who had ever contributed to the repository. I was able to export the list of people including their usernames and e-mail addresses directly from our UCS LDAP and convert it to the format required by git-svn.
The first, immediately evident effect of the migration is the integration of git commits and plan.io tickets. Alongside the comments on a ticket there is also the commit history for the ticket. As such, quality controls can be initiated directly on the ticket with a review of the code changes – this even works across several repositories:
This part of the migration was completed in next to no time and without any complications at all. Then our internal build system for UCS packages was expanded to allow importing of packages from git repositories.
Challenges encountered during the changeover to git. Humans are creatures of habit….or are they?
From what I’ve observed, the actual challenge of the git migration is getting to grips with git, as it is considerably different from SVN. Here you can see an excerpt from the linear SVN history that we started with:
The biggest advantage of git lies in being able to create release branches AND merge these together with the master branch again. This sounds simple but in fact involves a considerable change in the workflow. As yet, no one has reported another solution for bringing the problems described above under control without working with branches. At the same time, to continue with the arboreal analogy, the development of many branches can also produce a decent thicket, which eventually becomes impenetrable. In our case, the main task in the changeover to git was thus to keep our productivity high despite the changeover and to define the best way of working flexibly with git branches without losing track of things.
We started with the following, simple branch model:
- Every release has its own master branch: ucs-VERSION/KUNDENRELEASE_X/master.
- Every feature branches off from the master branch and becomes its own feature branch. ucs-VERSION/KUNDENRELEASE_X/TICKETID-FEATURE_Y/master
- Once the development is complete, the feature is merged into the master branch.
- Once the quality controls are successfully completed, the feature branch can be deleted.
Here you can find a graphic representation with the corresponding git commands:
So far, the model has left a good impression. A workshop was held with all the developers for the changeover in order to go through the basic commands and try out the branch model in practice. In addition, documentation was compiled describing the individual steps with command line commands. This was very important for guaranteeing that productivity would not be jeopardised by the changeover. All the developers have successfully implemented changes with the new workflow in the past week. We have had no problems so far. A whole host of teething problems are normally encountered when changeovers are implemented, but there was no sign of them this time, even though the branch descriptions were also accepted as safe passwords. 🙂 I was positively surprised by this, and it is proof that we have all been working in unison! Here is a section of our current development phase with the individual branches and merges clearly visible:
Our summary. Now everything else needs to be adapted to git too!
The described use of git is by no means perfect. There are a number of things that we would still like to implement and which could run more smoothly. In particular, in the current workflow, the feature branches are unfortunately still integrated in the master branch without the changes having ever been completely tested. As such, we have yet to get the high error rate in the Jenkins tests under control. Our intention is to generate a test job for each branch dynamically in the Jenkins test, construct all packages from the branch automatically and then perform the tests. This function has since been retrofitted and has now been running productively for several days. I expect that this will make it easier to separate the development of features. To do so, however, the first step is to reduce the existing errors in the Jenkins tests to an almost non-existent level in order to see for real which errors arise during the development of features.
What experiences have you had with migration to git? I am looking forward to your feedback!