Innovation, our reason for being
Not long ago, our development process was an ant based one, managing dependencies in a not very good way and using a series of custom scripts to prepare and deliver product and project bundles. Merging was really a nightmare, and we lost a lot of time making manual tasks and training new colleagues in our way of doing things. As time passes, I wonder over and over how we could work that way.
I any case, we decided to move forward, changing everything upside down. This involved changing our versioning system and mainly our building and development process. We changed a lot of things, and it was not easy, indeed not easy at all. We needed to think through the important and no so important matters, and how we could improve new colleagues onboarding.
In the next points I’m going to focus on the different issues we had to address
As a matter of fact, changing the versioning system isn’t a task at all. It’s just a change of tool.
Even though that’s right, I would like to highlight some points, just if you are in the same situation,
In any case I don’t regret moving on to Git, it was a step, a necessary one, in the change we were trying to address, improving our building process,
The best thing that I can say about how we were used to working is that it was a home-based solution, point. Dependency management was so bad done, that I don’t know if I dare to say that we had it at all. Bundling our projects was based on shell scripts, variable substitutions and all those things. It worked, but working is not enough, it must be maintainable, it must be repeatable and as new people came to work with us, replacing old ways was a necessity.
If we talk about tools, the change seems not to be so complex, we just began by using Nexus Repository, Gitlab CI process, integrating SonarQube and delivering the bundles through Docker. Quite simple and standard, isn’t it?
Actually, it’s simple at all since, under the hood, there are many processes involved, changes that must be done, and issues that have to be solved in some way, to be redone in a different one in a few weeks or months, after the process is consolidated. So, our change was:
Without any doubt, of all the tasks we performed this was the toughest one. We didn’t want to follow a cosmetic approach since what we were actually trying to solve was not only improving the CI process but ensuring a productivity increase for both our developers and operation teams.
We changed the tool, forgetting about ant and moving on to Gradle. But, believe me, the problem was not changing the tool, but the things we did with it. Just to highlight some of them:
Changing is not easy, but that doesn’t mean that it’s not necessary. Doing always the same, only drives to stagnation, and stagnation only drives to disappearance.
Just to give you some figures, changing everything took us about 1 work year, about one person and a half, we learnt a lot, but mainly we improved a lot, and we now that we have still a lot of work to do.
Embrace change, don’t hesitate to do the things that must be done.