How to choose the right Build Tool for your Project

Before a new application is released, that “raw” software code has to be compiled and turned into an executable binary. That packaging process is a complex task and involves more than just compiling the source code, for example checking and resolving dependencies, running tests, and copying the application to its final destination. Since it's not very efficient to do this manually, you should consider using a build tool to automate the process. 

So, how do you find the right tool for you and your team? Choosing a build tool is one of the most important decisions developers make—well, apart from deciding on a text editor or an integrated development environment (IDE), a Version Control System (VCS), and a Continuous Integration/Continuous Delivery strategy. You use the build tool every time you compile your code or get it ready for deployment. Considering the significance, you should select it carefully, so here are some suggestions on how to decide on a build tool for your projects.

In this article I’m going to answer the following questions:

• What exactly does a build tool do?
• How do you test a build tool?
• How do you integrate Build tools into your CI/CD pipeline?

What exactly does a build tool do?

Build tools are programs which help you to build an application from source code. In other words, they compile and package the code to turn it into an executable form. Most of these build tools help to automate processes by offering the following features:

• Dependency Management: build tools can download additional software, like external libraries or frameworks.
• Compiler: build tools transform a program written in a programming language from source code into object code.
• Package Creation: build tools bundle software packages which can then be installed, often on multiple platforms and computer architectures.
• Automated Tests: some build tools can test software applications, for example, run certain scripts, tools or use other test automation frameworks.
• Automatic Deployment: some build tools can help to make a software available to its intended users, i.e. deploy applications to test and production environments, etc.

That's quite a comprehensive list of features, and not every build tool supports all of them, but it all comes down to one thing: build tools are often a developer's single point of contact with the CI/CD system.

How do you test a build tool?

A build tool can make your life as a developer easier, not just when starting a new project from scratch. Imagine, you're migrating an existing project, for example, either legacy code or someone else's work. So, how to pick the right tool? If you look at the Wikipedia article on List of build automation software, you’ll notice the variety: there are plenty of build tools on the market, some open source, some closed source. They all have different approaches and methods, their pros & cons. Some build tools run on the command line, some can be triggered inside an IDE or by continuous integration programs. 

It’s a good idea to test one or more build tools, before you decide on one that works best for you. If you’re working in a team, make sure to discuss this with your fellow developers and get the team involved.

Before you choose a build tool, you should ask yourself the following questions:

• Can you trust the software? How long has the tool been around, and do you know other developers or teams who use it?
• Is it free and open source software, or is the build tool proprietary software? If so, what kind of license does it use? 
• Does the vendor offer upgrades, bug fixes, and professional support?
• Is there a bug tracking tool or some kind of community forum?
• Is there a fully functional evaluation version for your tests before you purchase the build tool?
• Does it support other tools you use, for example, your favorite compiler, version control system, etc.?
• Can you understand the documentation, and are the manuals complete? 

Once you’ve decided to put a build tool to the test, you can create a sample project and see how things work for you. This can easily take more than a day, especially if you want to run tests, play with dependencies, write additional scripts, and test the integration with other software you use. Make sure to set up the sample project with your CI/CD tool to check if it builds ok. 

Do the results look ok? Then migrate to the next step, and use the build tool for a real project to test things in a real-world scenario. Again, don’t forget to talk to your team—everyone should be happy with the decision.

How do you integrate Build tools into your CI/CD pipeline?

Some build tools might run out of the box on your local computer, others have to be installed on a remote server, i.e. on the build machine. As I said above, a lot of build tools run on the command line. They can also be used by continuous integration tools: after you’ve checked your code out of a repository and moved it to a clean build machine.

If you’re a DeployBot user, then I have some good news for you: it’s very easy and straightforward to use build tools in DeployBot, as they can run inside protected Docker containers. Our Docker containers provide build tools like Node.js, npm, Yarn, Grunt, Gulp, Sass, Bower, Apache Maven, etc. If you’re not happy with the predefined Docker images, feel free to search for images on Docker Hub and use a different one.

Conclusion

Choosing the right build tool is as important as choosing a programming language, a text editor or IDE, the CI/CD tool, and the rest of the software involved. So, let’s return to the initial question: how do you decide on a build tool? Keep in mind that every tool you choose should make your life easier, not more complicated. Pick one that helps you to accelerate the building process, reduce errors, and improve the quality of your applications. 

Happy hacking!