How many times have you heard people say - “[Your favorite build server] is just a glorified cron job!”? I am sure if you think about this statement for a few minutes, you’ll find that there is something wrong with it. If it is true you could just start using a cron job. But you don’t! There must be more to it then.
The reason you don’t just use a cron job is because scheduling is just one of the things that a build server does. Build servers help you with artifact management, build outputs, trends, reports and much more. I like to think of a build server as a tool which helps in:
Orchestration
Model workflows
Schedule work along workflow
Manage and move around artifacts
…
Information Radiation
Results - did the work pass or fail
Console output
Reports
Trends
…
Scheduling (what a cron job does) is a very small piece of Orchestration. That’s the straightforward, well understood part of a build server. Build servers do not get credit for a lot of features that are just assumed. Most people use their favorite build server everyday to answer questions like
“Who broke the build?”
“What changes are in this build?”
“How often do we deploy to an environment?”
“How have we done in terms of test coverage over the last 2 months?”
and many more!
In fact, a build server should be considered good only if it does an awesome job at both Orchestration and Information Radiation. Such thought has influenced us while developing Go so that it can help both with modeling your build-test-release process and giving you insight into how your build progresses to production.
Think carefully the next time you call a build server a “glorified while loop”. That tells people that you are not giving your build server the credit it deserves.
See how the newly released Go 12.3 can help with Orchestration and Information Radiation awesomeness.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
