Montag, 15. Oktober 2012

Build systems > Own scripts

For a long time I though build systems are overhead. You can always write a (insert language of your choice here) script and run it to test or build your software.

Setting up phing to build and test a symfony 2 project of mine really showed me the value: These systems (for example ant, a java build tool very well known) are designed to do exactly this one task, and they are designed to do it very good.

Depending on one another

One thing I really value when using phing (or ant) is that I can execute every task on it's own or together with others and I can rebundle them as I like with just one line in the xml. If the task defines it's dependencies correctly, there is no need for me to know if I have to do something before I run "build" because the build tasks already knows.

For production/staging deployment or when you normally build your project, you might not need to execute only one part of the build, but there are times when you develop or test and then you do (say resetting the database and loading the fixtures) and a full build script sucks (mainly because it's more time consuming or because it interferes with your task at hand). On the other hand, targets make it possible to just run the resetDatabase target and skip stuff which is not needed.

Or think about the time something went wrong in production (it happens) and it would be nice to execute one part of the script, but there was no way, so you where running commands manually, maybe on many servers. 

What did you say?

Another thing I didn't took advantage of with my python build scripts where exit codes. It's very handy to fail a build on exit codes instead of running everything and later discovering that it's not working. Of course this can be done in almost every language, but with most build systems you just have to add a parameter and it's done for you.

Use cases are almost every external command you run (say building database, clearing caches and so on) and tests you do  (unit-testing systems, code convention checks, whatever). If the command fails or the tests show some problem, just printing something to stdout or into a logfile is not enough.

Special tools for special tasks

Looking back, I would have saved myself some hours of painfull work by installing and using phing instead of writing my own stuff.

There is a bigger lesson to learn here: If you got a common task, use a tool which was created to do it. Somebody already did the work figuring out what works and what doesn't. The same is true for software (anybody in need for yet another CMS?) and for processes. Most of the time it's way easier to just use something that already exists and modify it over time, replacing it when it's really obvious that it's not sufficient. Starting by creating something on your own is most likely to fail.

Keine Kommentare:

Kommentar veröffentlichen