Convince a lone developer to use a separate build tool instead of the IDE one-click build

Question

In my years of programming Java and more recently Scala, I've never used Ant, Maven, Gradle or any of those build tools for Java. Everywhere I've worked there was a build manager who took care of all of that -- I'd compile locally with the IDE for development and unit testing, then check in the source code and notify the build manager who did what was necessary to compile everybody's files for the shared environment.

Now that I'm between contracts I've been working on my own self-funded project and it's getting to the point where it could be good enough to actually make money. I even have a potential investor lined up and plan to show them a beta version in the next few weeks.

But all along I just click the build button on the IDE, and it creates the Jar file and it works just fine. Of course, the conventional wisdom suggests that I "should" be writing my own Ant/Maven/Gradle scripts and using that instead of the IDE, but what are the concrete advantages of that in my situation (working alone)?

I've done some reading about how to use those build tools, and it just looks like I'd be writing hundreds of lines of XML (or Groovy or whatever) to do to what the IDE does in one click (the IDE-generated Ant XML for the project is over 700 lines). It just looks error-prone and time-consuming and unnecessary for my situation. Not to mention the learning curve, which would take away time from all the other work I'm doing to get the product ready to show people.

Answer 1

I'd suggest you look into using Maven as opposed to Ant. If your IDE can build your project in one click, then it's likely that Maven can also build your project with virtually no custom configuration.

And to answer the question, simplifying the deployment process is one concrete example. If you're building a distributable locally that means that you have to manually deploy that distributable on your production system, and implies that you probably had to do a fair bit of manual configuration on the production system to get it ready for deployment (installing Tomcat, perhaps, or copying over dependencies and resources required by your application). This can be time-consuming, and may make deploying updates become a tedious, manual process. It also allows the potential for any minor configuration differences between your production platform and your development environment to cause obscure, difficult to track down errors.

So anyhow, what I do to get rid of this manual drudgery is that I configure my project to build with Maven, and I configure my pom.xml file with all the information required to (in the case of a Java web-app) find and download the correct version of Tomcat, install it locally, set up the correct Tomcat configuration files, deploy any project dependencies and the project WAR file itself, and then start Tomcat. I then create a simple shell script (and also a .bat version for Windows) that uses Maven to build and start the server:

mvn clean install cargo:start -Dcargo.maven.wait=true

So instead of packaging up a deployable on my dev environment and then manually pushing it up to production, all I have to do is sync from the version-control system onto the production server, and then the production system itself builds, installs, and runs the deployable (and does it in a way that is identical to how it is done on any development system, minimizing the possibility of platform-specific errors or misconfigurations). And whether in the development or production environment, all I do to build and start the server is:

./startServer.sh #or startServer.bat for Windows

And to deploy an update to the production environment the process is just:

1. Stop the running server instance, if any.
2. Run svn update -r<target_release_revision>.
3. Run ./startServer.sh.

It's simple, easy to remember, and not at all possible to do if I were to rely on using my IDE to build the deployable for me. It also makes reverting to the last-known good deployment a snap, should a rollback ever be necessary.

I can't even count the amount of time this approach has saved me over attempting to manually manage the deployment and configuration process.

And of course, another answer to your question is automatic dependency management, but I believe that's been covered already by other answers.

Answer 2

As long as your code is in source control, using the IDE to make your distributables is fine.

As a one man shop, is your time better spent adding new features to your product, or writing build scripts? Something tells me its not writing build scripts.

Answer 3

Sure, it's harder to see the benefits when you're working alone. Personally, I've worked on plenty of solo projects and not only would I write a build script, I go through the trouble of setting up a CI Server (like Jenkins).

There's overhead of course, why would it be worth it?

• A reproducible build, not tied to the IDE (or your machine, if you run it externally). If a build server runs it, other machines can run it.
• The fun begins after building and unit testing (by the way: are you sure you test before every commit? I sometimes forget). Generate documentation, build installers, run your favorite code analysis tools.
• Your favorite CI server lets you see graphs of code coverage, unit test failures, etc. over time. Does your IDE do that?

For my current project, the script builds, runs static analysis tools, compresses js/css, unit tests, and packages into a web archive. Jenkins runs it after each commit and deploys the project to a test server.

I took the time to set this up (the build script is maybe 300 lines by the way, haven't touched it in months) and can say it's worth it, even for one person. For more than one person, it's necessary. My involvement in the build/deployment process consists of the commands "hg commit" and "hg push."

Answer 4

Benefits of Build Tools

It's a short summary just showing the tip of the iceberg, and you won't necessarily notice the important of all this unless you need to do with a combination of many projects, large projects and medium to big team. But if you have faith and try, you'll reap the benefits.

They facilitate your development lifecycle and as they allow you to:

• organize and structure your projects consistently and effortlessly
• re-use good practices across projects and easily and quickly kick-start them,
• integrate multiple projets in a single build,
• automate your continuous integration process,
• share your project with others
  • without enforcing them to use a specific toolkit or IDE (apart from the build system),
  • and without surprising them as they'll expect a standard build
• automate and facilitate the maintenance of your product
• automate your product's release process

If We Apply this to Maven...

For those of you in the Java world and who use Maven, by reading this you naturally associated each point with:

• Maven's structured project convention
• Maven Archetypes
• Materializing a project from SCM and reactor builds
• Jenkins/Hudson/Bamboo/other support + Maven's support for integration testing practices
• m2eclipse, native IntelliJ or NetBeans support - or mvnsh for the command line
• versions-maven-plugin
• maven-release-plugin, buildnumber-maven-plugin plugin and versions-maven-plugin

And of course, Maven (but other tools as well) gives you dependency management, and that's a huge time and space saver for you (factored to the number of people in your team) and your SCM.

Everything's Relative:

I'm using Maven as an example because I think it is the most comprehensive and "batteries included" build system, but it doesn't mean it's necessarily the "best". It does fit all the tickboxes listed above though, and when looking for a good build system, I compare it to this list and Maven. However, Maven is not always very flexible - it is however very extensible - if you deviate from your standardized process. It boosts your productivy in the general case (once ahead of the learning curve), not if you fight it.

Answer 5

Here are my top 4 reasons to use build tools:

• dependency handling (avoid errors)
• testing (your change did not break other modules - much easier to test)
• safe commits
• easier to deploy local distributable (no one has time in QA env to wait for the builder to build your project and its dependencies)

Answer 6

In the book Pragmatic Programmer, Andrew Hunt and David Thomas say that 'checkout-build-test-deploy' should be a single command.(Chapter : Pragmatic Projects). You wrote..

I even have a potential investor lined up and plan to show them a beta version in the next few weeks

Then, I am sure your team is going to grow.. It is even more important to have automatic test-deploy abilities done.

The large XML (script) you saw, is typically a one time job. Most of the time, the same scripts can be uses across many projects.

It is not clear how large is the project. If your integrated tests/acceptance tests takes large CPU/memory you may consider using another machine as your test server. You could also deploy host of tools to analyse the source code/byte code.

Answer 7

I would argue that, for a lone developer, having good process and structure like scripted builds is vastly more important than when you are on a team. Reason being you don't have teammates to call you out when you cut corners. A CI server running your build script makes for a great uncompromising teammate to keep you honest.

Answer 8

As your code base grows, you will want to add a test suite. My experience is that this should be done sooner rather than later, and that your nightly (or whatever) build should run all the tests every time. Start small, the auto-generated XML is probably fine. When you're scared to change something for fear of breaking something else, that's a good incentive to write up a few test cases.

Answer 9

A non-IDE build makes it easy to rebuild old versions without worrying about reconfiguring your IDE the way it was at the time, lets you perform the build non-interactively so you can maintain a nightly build for people to test, or find out quickly if you broke tests without having to remember to run them and wait for them to complete.

It also lets you perform builds in non-GUI environments, e.g., ssh'ing to a server, and allows you to switch IDEs without worrying about losing the ability to build your software.

Some build tools help you to automate tagging and deploying releases, come with decent defaults for generating code coverage reports, etc.

When you add more people, a build tool will make sure you're not vulnerable to someone else's poor IDE configuration. I regularly do screenshares to fix colleagues' Eclipse installations because they don't use build tools (working on that).

The ultimate reason though is that it is something that doesn't need to be done manually, so don't do it manually. Everything else falls out from that.