The future of CI/CD with Gradle - moving forward.
April 13, 2017
The future of CI/CD with Gradle - moving forward.
Score 10 out of 10
Vetted Review
Verified User
Overall Satisfaction with Gradle
In my organization, Gradle is being used in conjunction with Jenkins, to support a model of Continuous Integration. It is being used across a distributed organization, encompassing three geographic locations. It addresses the business model of CI/CD. With Gradle we were able to automate the building of a complex backend application, supporting a variety of branches, daily builds, and distributed development teams.
- Gradle's methods to manipulate files is very flexible. It minimizes the amount of code one has to write to copy, move, or expand zip or tar files.
- Gradle uses Groovy, which is a Java like language. This allows for most computer engineers to come up to speed fairly quickly, for writing or maintaining gradle code.
- Gradle also supports DSL (Domain Specific Language), which is based on Groovy. The DSL language allows engineers to automate build jobs that otherwise could be very cumbersome to maintain or modify.
- The Gradle documentation is available online, and it is quite comprehensive. However, more real life examples could be useful.
- In a distributed development environment, once we established a strong CI/CD model, Gradle proved to be a great choice to automate the various processes. Gradle also provides much flexibility, which is essential in today's development environment. The important benefit is that the CI/CD engineers can support development's needs quickly and reliably. This in turn supports faster testing and deployment, which generates higher ROI.
I have participated in a variety of build environments, from basic shell scripts, to ant, and to maven. All of these tools have a place, sometimes perhaps in legacy code. But moving forward, I would never go back to other more primitive tools (never say never...). The more I learn and use Gradle, the more of an advocate I become.