Alright… so unless you you’ve been living under a rock for the last couple years, you know that TDD, Source Control and Build Automation have fully hit the Flash design and development scene. It seems as though everyone is talking about it. A lot. And then commenting on it. A lot.
For those that come from a traditional Computer Science background, this sort of talk is like second nature. For those of us with a Graphic Designer brain trapped in the body of a hoodie wearing developer, it’s like command line jargon soup wrapped in a veneer of pocket protector CYA. Regardless of your preconceptions, it’s hard to argue with results. This sort of agile/test driven development generally leads to good results. The Iona Group has been using TDD, Source Control and Automated Builds in varying degrees for a about year now, and I can say that our stuff is better faster stronger (harder – Daft Punk!), less buggy and more often then not ahead of schedule far more frequently, now that we are using it.
This isn’t mean to be an article extolling the virtues of the process, or even a specific break down of how the individual pieces (SVN, Issue Tracking, Hooks and Automation) need to be implemented on a piece by piece basis. There are a lot of specific posts on how to use SVN, or how to write a unit test, etc. What I’d like to do here is give a you a topgraphical/flowchart view of how this process works in our case, and some info on how we are leveraging the hardware and platforms to do it. This seems to be like a secret sauce that everybody keeps to themselves, so the shared knowledge about the overall setup for such a configuration rarely gets shared due to intellectual property or security concerns.
In regards to our setup, I’m sure that this system is simplistic in many people’s views, but for our size and purposes, it works really well. This system is primarily used with developing PHP web apps, CMS sites and Flash/Flex/AJAX RIA. Of course the standard HTML, CSS, JS, XML get run through the system, so it’s pretty flexible. Finished binary assets (Graphics, etc) also get checked in, but the graphic design process files (PSD, AI) remain on the separate file server on our internal network.
A little on our team. We’re about 75/25 split… most of us being on Macs. We use the Creative Suite for all our production work and use Eclipse as a primary IDE, though I still use BBEdit for casual text editing. (Casual text editing? You know, like with a linen shirt on and drinking a mojito or wearing a scarf). We have XAMPPinstalled on our machines because it has a full Apache, MySQL, PHP stack on it and is fully cross platform, as opposed to WAMP or MAMP. Everything about XAMPP is awesome, except for the stupid stok photo models on their site.
Our local dev servers are virtualized Linux boxes in some tidy racks that our IT Director graciously keeps running for us. They’re pretty rock solid and haven’t ever given us a problem that a reversion to a snapshot couldn’t fix. They are Apache servers (though we do also have some Windows IIS server for when they are needed, too), running PHP 5.x and MySQL 5.x along with Tomcat and Red 5. Standard fare, really.
We use SVN for version control. Specifically, we use a hosted SVN service at Assembla.com. They handle our issue tracking, project wikis and Scrum. It really is a fantastic package and well worth the money. It’s more feature rich and as easy to use as Unfuddle and I have never once experienced an outage like some of my friends have using other services. If you are interested in trying them out, I highly recommend it. They offer a 30 day trial. During signup, enter ‘chadu’ in the “Referral code” field to get a $5 discount on your first paid month. When we first signed up, we had a Mantis Bugtracker database with thousands of issues in it. They took our SQL file and imported it for us. Pretty sweet.
The really cool part comes when you start tying the things together with post commit hooks. Assembla (and SVN in general) allows you to fire post commit actions to publish files, do things like automate builds etc after you have done you home and independently run your local tests, etc. Very cool indeed. This helps take the human error part out of file migration from a development server to a system testing server. You won’t forget to upload that JS library, etc if it was included in the commit. Very nice. After a promotion of a successful build, any number of other post commit hooks can fire off shell scripts to RSYNC a directory back toa file server for cold storage/backup purposes.
We like the power and flexibility, and we really like the burndown charts and metrics… It just makes reporting that much easier for us.
In the creation of the process we use, I made a couple diagrams to help document it all. It’s not really proprietary info and I think a lot of people can benefit from seeing it diagrammed out this way. Dan Roam has a great book called “Back of The Napkin” and I truly believe in the power of a good drawing to help people understand a concept.
So, here is a step by step picture of the issue tracking and testing process…
So, what do you think? Are you applying this sort of process to your Flash work? If so, how’s it working out for you? If not, does seeing something like this help you get closer to it?
Alright… so now that you have a bit of a grasp on the process, how do you go about setting up the environment and handle the progression. What machine does what and where is it located? Here is a simple view of what we are doing for most sites.
I’d like to hear from you if you are doing something similar to this. I’d also like to hear if your set up wildly deviates from this. Let me know your thoughts.
If you are interested in a higher quality PDF of the above files, click here to download it.
This setup has greatly increased our quality level and productivity. When you add in things like data safety (multiple file backups, full version control, tape backups and offsite storages), it makes everyone feel a lot more secure, too.
Posted on January 22, 2010