Ant to Gradle Migration

Ant to Gradle Migration

Ant served us very well and was our only build tool for last few years. Last year we decided to move on to new build system as we were adopting micro services architecture and dev ops culture. That means we were building brand new services and also carving out independent services from current monolith application. This requires modern, flexible build tool that helps in faster development. Maven and Gradle were two choice. I did look at some other choices but was afraid if we would get all the support we needed or not. I ended up choosing Gradle since I really like to program my build tool than putting it in xml. Also Gradle was gaining ground and large community support was good enough for me to trust and go on with it. 

We are done with entire migration now and here some of my thoughts on this migration.  

Ant build.xml

Very early on we took decision not to invoke existing Ant's build.xml from Gradle's build.gradle. We not only wanted to move to new build system but also wanted to cleanup unused features and functions and phase out Ant completely.

Libraries

We had ton of libraries in our source repository. There were multiple version of same library. Also checkout process was taking long time since entire library was getting checked out with source code.

We installed our own maven local repository using Nexus' repository manager and moved all our libraries to it. This process helped us to get rid of old unused libraries and have consistent versioning and naming of all the current used libraries. All our new micro services used Nexus repo to manage their own libraries.

Multi Module

Most of our new micro services were multi module projects. Make sure that all the functions and tasks are present in parent build.gradle and only very basic information is available in module build.gradle. Avoid copy pasting of task from parent to child module. Its far better to refactor and reuse the same task across all modules. Treat build.gradle as source code and write unit tests.

Gradle Wrapper

I always use gradle wrapper. You should check in your gradle wrapper with your source code so that all the developers and CI/CD tools have consistent gradle version.

Write custom plugins

Always review your build.gradle and look for patterns. Is it becoming too big? Are you copying build.gradle from one project to another and just tweaking a bit? Are you struggling to test and maintain it?  You probably have lot of customization which you can carve out into plugin so that all the project can import and use it. 

Comments

Popular posts from this blog

Capstone Data Science Project - SF Restaurant Analysis

7 National Parks in 15 days road trip