Friday, November 8, 2019

Groovy in the Enterprise in 2019

It's been 10 years since I've updated this blog. Since that time, I've see the use of Groovy broaden across our enterprise in important ways.

Automated tests, automated builds, continuous integration and push-button deployments are part of our company's everyday life. Groovy is an integral part of the world-class CI/CD pipeline at our company:

  • Gradle lets us encapsulate our enterprise development environment conventions. It's been easy to create custom Gradle plugins that support our integration with SonarQube, Artifactory, Docker EE, AWS and Azure. Having the full power of the Groovy programming language available to us in our build scripts is priceless.
  • Groovy DSL Jenkins makes it easy use define our Jenkins pipelines. Being a Groovy DSL enables us to write custom build libraries that augment the provided DSL.
  • The value of CI/CD is directly dependent on automated tests in our projects. We use Spock extensively for unit, integration, functional, UI, and end-to-end tests.
  • For legacy web systems, Geb and Spock has been a great way to verify functionality as we enhance older systems that weren't developed with unit tests.
I still use Groovy as a better Java for building web services and micro-services when using Spring Boot or Micronaut. I also continue to use Groovy to rewrite and simplify batch processes.

However, one thing that has changed is that I've become a little more opinionated about using Groovy for application code. I strongly believe that less code is better than more. Also, fewer library dependencies is better than more. Lately, I've been trying to use the GroovySQL JDBC facade instead of an ORM whenever possible. I also try to use JsonSlurper and JsonOutput with lists of maps directly when reading and writing JSON instead of object mappers. I've started using ConfigSlurper for managing environment specific configuration for apps that don't need otherwise need Spring.

Finally, I've found using Groovy as an alternative to Java for the application code significantly lowers the barrier for entry into our development ecosystem. This is important for developers who are coming from universities where they used Python, code schools where they learned Ruby+JavaScript, or legacy developers who have year of experience with SQL and 4GLs. 

Today, Groovy doesn't seem to generate the amount of hype it did when I first started using it but that doesn't mean its usage is fading. Since becoming an Apache project, Groovy continues to evolve in interesting ways and new releases are a happening on a consistent basis. According Paul King, there were 103 million Groovy downloads in 2018, and it is currently being download approximately 16 million times per month. There are hundreds of commits per year and the number of unique committers is higher than it was through the first nine years of the project. Given these numbers, it appears that I have become part of a huge group of users that is quietly using Groovy now more than ever.