Build Automation, and the Tools: Gradle, NPM
We’re human, and we are lazy. Human intelligence makes us always think about saving time from repetitive tasks. That’s why we had more than one period of the industrial revolution, which had one purpose: giving such tasks to restless, effective, and powerful machines. Because we humans think this way, we could enjoy a lot of modern things in this age — for example, coca-cola.
As developers, we are also good at saving ourselves from repetitive tasks. I know a lot of us are writing code for some daily routines. Personally, one funny example is that I was writing a JavaScript script to help me automatically delete my comments on a Q&A website. That’s how we could make our life more beautiful by automating even a very tiny thing.
That’s why a lot of teams are using build automation for enhancing their production now. Actually, we could still see a lot of small teams doing everything manually: building, environment preparation, testing, releasing, etc. Some developers think it’s a very easy thing since it’s just some clicking and dragging, but when they see a big-enough web application, they’ll find they have to manually do:
- Compiling the CSS3, JS6+ code to ensure the compatibility;
- Compacting source and static files, like CSS, JS, HTML, and images. It will accelerate the loading speed.
- Linting/Formatting: we want to maintain the same code style in one product.
If someone really wants to do such jobs manually, it’ll be not painful for me to look at them compacting more than 2000 lines of code, five times. However, everyone doing that will hurt. That’s why we have automated building tools, like Gradle and NPM, to help us finish such tough and repetitive pieces of work. Now, let’s introduce, and compare some functional points between them!
Dependency Management
Dependency management should be considered one of the most important pros for the build automation tools, since no one wants to install the libraries one by one on the prod environment.
Gradle uses the build.gradle file to indicate the dependencies. It is written in a language called Groovy. the dependencies declaration looks like this:
dependencies {
implementation 'org.hibernate:hibernate-core:3.6.7.Final'
...
implementation '<group>:<name>:<version>'
}and for NPM, we use package.json, a JSON-written file, to tell the dependencies:
"dependencies": {
"aws-sdk": "^2.1225.0",
"bcryptjs": "^2.4.3",
...
"<package-name>:"^<version>"
}We could see that both Gradle and NPM give us a chance to indicate the versions. This is crucial, since an update might make a widely used function(method) deprecated; it might shut down the whole prod environment if the team failed to notice it. Also, refactoring the code to fit a new version is not a quick job, and it’s not a good idea to delay the release only for this reason (we’re not as famous as Cyberpunk 2077). So keeping everything in their specific versions, and changing the version number when we ensure the code works in the new version is a better way. Additionally, they use a similar way to gain the dependencies: downloading from the remote registry, and saving them to the local cache folder.
Defining and Executing Tasks
In Gradle, the custom tasks can be defined in build.gradle file in Groovy in the following way:
task <taskname>{
group "Custom task"
description "your task description"
doLast{
<do something...>
}
} Then we could run gradle <taskname> for this task.
For NPM, we could also define user scripts as tasks, which means that we could add shell scripts to the scripts part of the package.json file:
"scripts": {
"<script>": "<shell command>",
},Also, there are already a lot of built-in tasks(scripts):
- For building, we have gradle build vs npm install (I always use “npm i”). One thing we should be aware of here is that Gradle is a Java tool, so it runs in JVM, and the code will be compiled. However, NPM is a JavaScript tool that runs in Node.js environments, and JavaScript code is not being compiled with.
- For testing, we could run gradle test vs npm test.
- For running, we have gradle run vs npm run.
- Both Gradle and NPM offer us approaches to override the tasks(scripts), so we don’t have to tell the users to use a custom command to properly run our project, but just override the command for run.
An Example of Benefiting from Build Automation
Aetna, one of the US leading healthcare companies, was experiencing some pain points during their development and product delivery. They want to observe more about the build and test process. Also, the teams have some communication problems during the failure troubleshooting. Another problem is the growing business and coding base is challenging their productivity.
After introducing Gradle (they have the enterprise version), they experienced an observability growth with the increasing code base. The automation tools also offered test management support, which resulted in faster building and testing, along with more transparent and fluent communication.
According to Atena’s words, and the reviews from other companies, the companies are obtaining an “immediate” benefit from the Gradle automation tool. That’s also a reason why a lot of companies are using such a technology: in short, time is money.
Feel free to comment or ask me anything about this project! If you find my blogs helpful, I’ll be very grateful if you follow me or share my blogs with your friends. Thank you for reading this!
References
https://gradle.com/enterprise-customers/commercial/
