Chapter 2In addition to the steps, which are listed previously, there are usually other tasks
that must be executed before an application can be deployed to production servers,
such as files must be copied to a final destination, documentation updated, and so
on. In a non-trivial project there are always many laborious tasks that we should try
to automate.
Build system principles
Developers love writing code but in reality only a fraction of our time is spent in
front of a text editor. In addition to the fun part (designing, talking with peers,
coding and bug fixing) there are tons of fatiguing tasks that must be executed often;
sometimes very often. Building an application is one of those tasks that must be run
again and again so it should be as fast and painless as possible. Here, we discuss
some principles governing the design of our build system.
Automate everything
The authors of this book are really bad at executing manual, repetitive tasks over
and over again. We are slow, make mistakes, and to be frank, get bored easily by
the chore of building. If you are anything like us you will easily understand why
we strongly believe in automating every possible step of the build process.
Computers are good at doing repetitive work for us; they don't take false steps,
don't need a coffee break and don't get distracted. Our machines won't complain if
we offload the majority of the recurring tasks on them! Time invested in automating
every possible step of the build process will pay off quickly, since we will be saving
time every day!
Fail fast, fail clean
A typical build process will consist of several distinct steps. Some of those steps
will execute just fine most of the time, while others will be failing from time to
time. Tasks that are more probable to fail should be executed early in the process,
and break the build as soon as an abnormality is detected. This assures that more
time-consuming steps are not executed until basics are covered.
We learned the hard way how important this rule is. Initially, the build system for
the sample application was executing automated tests before jshint. We often found
ourselves waiting for all the automated tests to execute; just to find that the build was
broken due to invalid JavaScript. The solution was to move the jshint task to the very
beginning of the build pipeline and break the build as early as possible.