Developers are always content and happy with writing code in rich and feature-full IDEs. Often for a new development team there seems no incentive and value for writing build (or setup or deployment) scripts. However it’s important and imperative to adopt the habit of automating the mundane and essential process of build, setup & running unit test suite; as this helps in saving hours of manual effort wasted, which could have otherwise been used for carrying out further useful work.
After the design of a project is done, a development plan and choosing appropriate tool for creating the build and deployment scripts for the project should also be given considerable thought. It is a good development practice to finalize on a suitable tool for creating the build scripts which can be run from command lines or shell files or batch scripts. This helps in automating the everyday routine of creating daily builds and deployment, both for staging and test environment.
Need for Build Scripts
In teams where there are separate Development and QA (Quality Assurance) teams, it is a daunting task to update the QA team when there are changes in build steps or order or pre-requisite dependencies or environment set-up for deployment. As I have mentioned in my previous post that such changes must be documented for reference and also shared via team-wide mails and wikis; it is often overlooked in a daily deployment scenario and thus time is wasted on trivial known issues. Hence having build and deployment scripts saves time for both development and QA teams.
What kind of tasks can be automated
Anything which can be automated should be automated.
Or in a nutshell, automation of anything which is a routine task and can be done as per listed or documented steps, should be aimed for automation. This includes but not limited to project build scripts, environment check and setup scripts, install scripts, un-install scripts, running unit-test, build-verification test scripts, check-in verification scripts.
For eg. developers often use the Unit-test framework with an IDE to run and verify their source code and feature developed. Similarly, QA teams can create test suites for API testing, code coverage, functional testing, performance testing, etc which can be then called at different points like code check-in or daily built or milestone completion thus eliminating redundant tasks and minimizing un-fit builds.
Some products require a setup step, which can also be automated. Similarly you may need an un-install step to remove the software from the system or an upgrade step for testing the upgrade flow. Such routine tasks can be scripted to save both development and QA time.
Choice of build Tools
There are many options available for doing all the above listed goals. I personally prefer doing things in different scripting tools which meets my goal. For eg. for creating build and running unit test on the product I prefer NAnt. It is targeted for the .Net framework and is similar to Apache Ant. It is easy to use XML-based configuration files, where you define various target tasks like compile, move or copy files or folders, regex helper for modifying file markers, zip/unzip filesets, version binaries. There are also some great custom task library provided by NAntContrib which is community supported and sooner or later make it into the official NAnt task library.
For Java based projects Maven is the preferred primary build tool. It is also a XML-file driven build tool. I have used Maven to build my java project, execute test cases & define and manage dependencies on other projects which is the coolest and the most powerful feature of Maven. It lets you define local module dependencies, dependencies provided by JDK (eg log4j, HTML parsers), or a private custom repository for your own company.
For automated builds and deployments, I prefer Jenkins. I have also used TeamCity and AntHillPro in the past. For all my needs both fitted the bill. They can be easily configured to run check-in build automation, setting up and deploying the daily build binaries to both dev and QA environments. It has various options to tag your builds as per your requirements. To think about it, I will write a separate post on using Jenkins sometime soon. But to sum up, if you are not using automation scripts, I suggest you start using them. It makes life easier.
Key Takeaway
The key point to remember is that we should try to automate repeatable tasks as much as possible. They help in continuous integration, on-demand as well as scheduled automation. Helps catch and report bugs in early stages of development thus improving product quality and saving time & money. There are various other options available which can be used to write automated scripts. They can be a heterogeneous mix. If you do not have anything at present, you can start with putting together short basic build scripts, and keep on improving them over time. Before you know it, you will have a fully automated system, and soon you will realize how have you been doing without it.
Let us know if you have used any other tool or any scenario for automation which you feel saved you team time and effort and we will share it with all.