Development Environment 8

This is an installment in a series covering the different components of a typical development environment. You may want to read Part 1Part 2Part 3, Part 4Part 5, Part 6, and Part 7 before reading this one.

The Automated Build Tool

This is one of my favorite topics in software development, because it lends insight into the potentially exponential self-actualization opportunities of this occupation; it is similar to compilers in that respect.

I was going to digress a lot (stopped at just over 300 words into the subject) into how the automated build tools are a marvelous example of coding tools to make coding easier, but I think I will address that in another post, because the deadline looms ever closer.

So, the role of the Automated Build Tool is to run all the steps we need to go from code to binary, and it does so by using the tools in our toolchain. In order to do so it needs to know how to invoke every one of those tools, and this is commonly achieved by typing the commands we would be running time and again to achieve our tasks.

In a single execution, our Automated Build Tool may run the static code analyzer and record the stats (letting us know if something is out of the parameters we’ve set as acceptable), then run the compiler on the code (which is sometimes a very convoluted process, and almost always needs to have a particular order respected), then maybe run some of the compiled binaries on other binaries (automated tests, anyone?) with perhaps some profiling happening at some point. Running any of those steps may involve invoking an interpreter.

This kind of process is something that is tedious to run by hand, and is done very often to test code being written or modifications being done to an existing codebase, because detecting an issue now costs less time than detecting it with a bigger time investment placed into code.

The automated build tool is at the forefront of everything related to Continuous Integration and Continuous Delivery. Because the tasks are often complex, the files containing the instructions can be enormous and confusing, and less than nice structures may arise to support behavior which is poorly covered by the Automated Build Tool itself.

Now follows the usual list of gratis tools of the category. These lists are by no means exhaustive:

  • ant
  • maven
  • gradle
  • grunt
  • bower
  • make
  • cmake
  • scons

Usually it’s a good exercise for a software developer to write a proof-of-concept build tool, perhaps one attuned to a particular programming language that can solve the dependencies among files in a project and build them in order. It is useful to notice that the tools that make software development possible are themselves software development projects, and that we can make tools to ease our life and make us many times more effective.

That’s all for Today. Tomorrow, we will talk about IDEs.

 

Leave a Reply

Your email address will not be published. Required fields are marked *