Hudson and Automating Development Tasks - Specialmoves
Hudson and Automating
Over the past 6 months we have been using Hudson to automatically build and deploy both Flash and .NET projects. Hudson is a continuous integration server. It monitors source-code repositories and at regular intervals or when it detects changes, it can run scripts. Those scripts can compile code, run unit tests, generate version numbers, deploy to servers and more. Although it’s a relatively new introduction to our studio, it’s rapidly becoming indispensable. Here’s why.
During the life of a project we perform many mundane tasks over and over again. How many times over a three-month project will you FTP a SWF to a development server so it can be previewed and tested? Automating those tasks can have a measurable time saving because you’re not just saving the time that it takes you do the file transfer, the tester is also spending less time waiting for you to upload the file, there’s less distraction and interruption for you as a developer being in the middle of coding yet having to fire up your FTP client, log in, copy one file, let a Producer know that it’s ready, realise that you needed to copy two files instead of one, apologise, then copy the second file. Which brings me on to the next benefit. Reliability.
Reliability and Repeatability
One of the biggest advantages of automating tasks is that you remove human error. Often, the more mundane the task, for example, resizing new design assets or updating a site file, the more there is a chance to slip up. Scripting these tasks up front means you’ve got some repeatability and there’s less chance that you’ll miss things as deadlines get nearer and nights get later.
Aside from the scripting of tasks, with Hudson you also get the benefit of using continuous integration. The benefits being, when a developer commits some code to version control, it is immediately compiled and integrated in to the team’s project code. Straight away we are aware of compile errors. Where it really becomes powerful is when it can run unit tests as well. So, I develop and commit, within minutes I receive an email notifying me that, hypothetically, I have just introduced a bug. Hypothetically.
Some of the time we’ve been able to save by automating tasks, we’ve spent on fine-tuning and augmenting our development process. For example, via an Ant script we can include the SVN version number in a Flash context menu. Aside from having geek kudos, when it comes to external testing this is really useful functionality. A tester can quote the version number on all bug reports. We have also configured Hudson to run a FlexPMD code quality audit, run FxCop to analyse .NET assemblies, and run a “TODO” comment scanner which reports on “TODO” comments still existing in the code.
So What’s The Catch?
While Hudson is open source and free, there is a time cost to installing, configuring and maintaining our continuous integration server. Hudson itself installs quite easily but creating the build scripts (we use ANT), getting Java configured correctly, installing all dependencies for Flex and .NET, these things take time to learn and implement. So I would recommend assessing the scale of your project to see whether it is worthwhile investing time in commissioning a Hudson server. For a 3-day banner perhaps it’s not worthwhile, for a project that lasts for a month or longer, then it definitely is. Once you’ve got the platform set up, Hudson’s interface is pretty intuitive and all configuration is done through the GUI.
Installing and running Hudson through Tomcat is quite simple. Creating your build scripts takes more time. There is an excellent blog that guides you through configuring Hudson to compile .NET code here. As far as Flash/Flex is concerned, we use Flex Ant Tasks. Hopefully in future posts we will share more details of our build files but in the meantime there are plenty of resources out there, including a step-by-step Adobe guide on the Adobe Developer Connection.