Alternate Title: Avoid “Black Boxes” and “Works on my Machine”
Even when working on a project by yourself it is important to try and create a build script that will “fully” build your project with a single click. But, you may be asking, why would I bother with a build script if there is only one person working on the project? Well the reality is that there is NEVER one person that works on a project.
There may only be one person working on a project at a given point in time, but if the project succeeds (a.k.a. it has additional releases in the future) there will be other developers involved. Either a future developer will work on the project on their own, or additional developers will join in. I’m of the opinion that the latter is far more likely if a build script already exists and those other developers will thank you (as would I) that they have some transparency into how the code should be orchestrated for a deployment or in other words avoid the “black box” problem.
In addition to just a build script that compiles and perhaps packages for release, a helpful goal that I think a developer should strive for is to attempt to create a package (a.k.a. source code and build script) that can be checked out to any machine and be built immediately. With the caveat that the build tool (a.k.a. nAnt, Bash Script, etc.) is a pre-requisite of building. Alas it’s impossible to have 0 pre-requisites for most build processes, i.e. the OS already has the build tool installed, except for things like a batch file approach to build scripts, which I’m not a fan of. By attempting to achieve this goal a developer helps avoid the “works on my machine” syndrome that is often present when only one or two developers ever work on a project and there is no build script present. It is also VERY helpful for “the new guy” joining the project. I should note that I specifically stated that a developer should “strive” to achieve this single check-out/single click build because often there are some pieces that will require pre-setup or local dependencies to be installed prior to building, such as DB clients or third party plugins. By attempting to achieve the “ever more automated build” goal it can greatly reduce frustration for others down the road.
One last tip to those diving into build scripts, it is helpful to establish a process where the build script is versioned along with the code base. In a continuous integration environment, ideally, a developer can change the build script and check-in and that will trigger a build to ensure that the change to the script did not in-itself break the build.
Top comments (0)