Automated Building and Releasing With Ant
This blog post was initally started in January 2005. I've learnt some more since then, and I'm including some of the lessons I've learnt from automation at Ephox and InvoicePlace in this post.
It is well documented that having your build automated is a good thing.
I would extend this, saying that the automated deployment of applications is important too. The big benefits in my experience are repeatabilty (that is ensuring that deployments always happen in the same way), and consistency of deployments. Automating the process helps to fulfill the import goal of laziness as well.
Often getting this right can take a while. The hard work starts by analyzing the deployment process, iteratively looking for bits of work that can be automated.
This can usually be done with a combination of custom ant tasks, external program calls, and console utilities. For all ant's wrinkles, it is a relatively useful tool, and there are a number of useful tasks available.
Here are some of the tasks that I have found useful in getting the build working.
The ant SQL task is great. It makes it possible to build/update databases, from simple flat files containing SQL statements.
The CVS task is good. In combination with Paegent from Putty, repositories requiring ssl access can be accessed easily as well.
IBM has a custom version of ant that can be used to deploy to WebSphere. I have found that with a combination of ant tasks, and tcl scripts any task that is required for deployment can be performed. This is best done in a build file that is seperate to the main build.xml, isolating the Websfear dependencies.
A combination of ant (exec task), wget (command line http client), and phpmyadmin(php based admin tool for mysql databases) can be mangled together to interact with mysql databases in ways that aren't easily possible with the ant sql task (the sql exported by myphpadmin isn't compatible with the sql task).
The buildnumber task is useful. It gets the current build number from a properties file, makes it available as a property, then increments the property.
The moral of the story is that it is there is no good reason not to automate building and deployment. It possible to do many great things with the large number of ant tasks available. Writing your own isn't that hard, and calling out to external programs is easy as well. Really it is hard to find any excuses for not automating a build. The only excuse is time and effort, and the savings gained can almost certainly offset this.
October 4th, 2007 at 8:19 pm
To re-invent the wheel is a waste of time. To improve upon the wheel is prudent and wise. Eagle Technology has a work order and asset tracking system (ProTeus) which not only can improve building maintenance and energy performance, but also ties in automated building controls via BACnet protocol to optimize the performance, and make proper procedures knowledge which is maintained by the facility not the employee who retires or goes to another job.
Anyone who builds or retrofits and does not integrate maintenance management system with the building automation system is missintg an important component in sustainability and GREEN buildings initiative.
Anyone can build a building and get LEED certification. It takes a leader to keep it in peak operating condition day to day, and have all the documentation of suggested and actual maintenance recommendations in a central database.
October 4th, 2007 at 8:53 pm
The above SPAM has been left as an entertaining tribute to someone who came so close to coming on topic, but missed.