All project repositories in our software department were migrated to Git. Here is what I have learned from leading this migration project.
During the last year, my team and I migrated over twenty software projects and the teams, that develop them, from Mercurial to Git.
While this seamed like an easy job to me at first, I quickly realized the hidden challenges in this undertaking. In this post I will summarize our reasons, our approach and my experiences gathered in the process of migrating the code base while training the teams on the new git workflow in parallel.
This first part will concentrate on the technical migration while the second part will focus on the trainings.
In my current project at my place of work we had a serious problem: Long build times and slow unit tests.
What do I mean with long? On our Jenkins a full build with unit tests needs approx. 1:20 hours. On our developer notebooks, the build without any tests took the same amount of time.
For me, coming from the nice and beautiful Java world at the university where builds execute within seconds or at least minutes, this was incredible. Hence nobody in our team has executed all unit tests locally for a while. Even worse!
Since I was new to QT projects and hadn’t any experience with qmake, the makefile generator that comes with QT, I decided to invest a rainy weekend to see what is possible. Luckily my first successes look so promising that my team and I decided to spend even more time on build time reduction in the following sprint.
In this post I will summarize what helped us and what didn’t.