Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save evangoer/5167667 to your computer and use it in GitHub Desktop.
Save evangoer/5167667 to your computer and use it in GitHub Desktop.

I wrote this for a colleague at work, but I thought I'd share it here for those that are confused as to the role of a build tool. To those that have not spent years working with various build tools, it may be tempting to find one that is written in the language you are using (i.e. Phing, Ant, Rake, and Grunt come to mind) or perhaps you are easily persuaded by things that have a lot of features (Gradle immediately comes to mind).

To be honest, build tools are just glorified shell script wrappers. Some more complex than others. At the end of the day, a build tool should do four things to be useful and not get in the way:

  1. Run your scripting tasks (where less abstraction layers are better than more).
  2. Allow you to define dependencies (like, always run the task to delete all of the build artifacts before running the task that generates code coverage).
  3. Give you a simple way (preferably without needing to install a fancy GUI/IDE) to look at what build steps will be run without running them.
  4. Issue a sane exit status code when any of the defined steps fail.

Consequently, #4 is all that Jenkins (or Travis CI, or just about any CI server) cares about. If you have #4, your CI server can report whether the build failed or succeeded. The further away one gets from these core fundamentals, the more layers are necessary to get anything done. At that point, good luck finding your way when anything goes even slightly wrong.

FWIW, I prefer GNU make; however, I've been known to sling some Phing, Ant, or Rake where appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment