Hi everyone, I hope you all had a great spring/Easter break.
If you've been following our company/product blog, you know that we have a few big features coming up: myBalsamiq, the components feature and a new skin for Mockups. Each of these features has the potential for increasing our customer base substantially, so we need to be ready for it.
We took advantage of the downtime last week to migrate our website, blogs and source code to a more scalable, modern and reliable infrastructure. Oh, and it's must faster too! :)
It was a pretty big effort, so we thought we'd share what we did and how we got to this point, in the hope that it will help you if you're just starting out.
A bit of History
The chart above maps the 4 transitions that took us to this point.
When I was first starting up my good friends and advisers Michael Fitzpatrick and Chris Tennant generously offered to lend me space on one of their servers. They run ConnectSolutions, a very cool company which offers top-notch real-time communication solutions (you should DEFINITELY check them out, they're awesome), so they had server-space available. Their typical slices had 4Gb of hard drive space, which I thought was plenty!
I installed Drupal (for the website), WordPress (for the blog), Perforce (for source-code repository) and CruiseControl (for continous integration, i.e. turning the source code into the applications you download from our site). I also installed MySQL so that Drupal and WordPress could save their data in it.
For the videos on the website I just used YouTube at this point, adding Vimeo briefly (I liked their UI, but their Terms of Service are incredibly un-business friendly).
The first migration: moving the build machine
Right around the time when Marco joined last year, we decided to move the build machine to its own server. Compiling our many different products is a CPU-intensive operation, and that's not a good thing if that same computer has to be serving your web pages at the same time.
On top of that Perforce, which is free for up to two clients (one on the build machine and one on my laptop), was way too expensive for us, so we switched to Subversion. It behaved much like Perforce with a centralized repository of code and check-in/check-out model, plus was mature enough to have great GUI clients like Versions, so we went with it.
For the new server we chose to get "a slice" (a virtual piece of a server) on Slicehost, which we had heard about due to their great customer service.
One added benefit of the move was that from then on our code was backed up daily automatically (I had not set up backups on the Windows server because I was using my laptop as backup...I know, not good, but such is life). Slicehost makes it incredibly easy to turn on backups, it's a "set it and forget it" kind of thing.
Regarding hosting video, because I was unhappy with Vimeo, I wrote a simple FLV player and started hosting some videos myself. This gave me more control but meant more work, and those video files take up a lot of hard drive space (remember, I only had 4Gb to work with, which by now started to feel pretty small).
Our Little Company Grows
With Luis and Mike rounding out the team at the beginning of the year, we decided to each have a blog so that we could share our experiences with you better and hopefully get your feedback along the way.
The only drawback of having five different blogs means that we needed to manage 5 different WordPress installations, each needing to be backed up and updated regularely. Plus we needed to have a single theme to share, each with its separate sidebar. Anyways, a lot of maintenance work.
I asked Mike to take all of that on, but after a lovely chat with one of my heroes at SXSW I have come to realize that outsourcing this maintenance work would be the best way for us to do.
Another side-effect of having Luis and Mike joining full-time is that we now have more people committing code and working on different features at the same time. Luis encouraged to look at Bazaar and Hudson and gave us a demo in person when he came down to Bologna last month. Slowly but surely, I came around.
What happened last week
Right before SXSW, our old web server was straining under the load, so the night before I left for Austin I got another slice and prepped it all up (firewall, ssh, apache, mysql). BTW, I love it how things that seem so scary and hard the first time you do them can become so painless after you do them a few times.
At SXSW I met one of my heroes and he told me his new startup was basically a managed WordPress service on steroids, so I thought, why not migrate our blogs to their service at the same time?
And "while we were at it" (the 5 most expensive words in any remodeling), why not make the move from SVN to Bazaar and from CruiseControl to Hudson?
I figured if we're going to break everything, let's just do it all at once and get it over with?
Well, it was a tough week, but it's over. I bet there will be broken links to fix in the next few days, but so far, I'm really happy we made the move.
Our builds are much more streamlined, easier to manage and MUCH, much faster (we only build the skin's SWF once instead of 8 different times, for starters). Hudson's web interface is very usable, and the software tells us the build is ready via Instant Messenger, which is kind-of cute.
The website feels VERY fast to me, I guess having some hard drive and more ram really makes a big difference, who knew! :)
As I was going through the 50 web pages that make up our website (I'm not counting the blogs), I also moved our videos to Brightcove, which we're also very happy with so far.
As for Bazaar, it's awesome. The ability to have your own local branches is really liberating. Just the fact of not having to fear branches as a concept any more is worth the move. I started a feature, didn't like where it was going, so I parked it in a branch. Marco is working on components, on its own branch, while I can continue to fix bugs and do weekly releases. Mike is redoing the CSS of myBalsamiq, in his own branch. I pull his changes once in a while, but Luis doesn't have to. So cool
The people at the WordPress hosting company, which I cannot mention yet, are giving us tremendous support, making managing 5 different blogs much, much easier. They back up everything (which, if you remember, I still hadn't done more than once or twice manually), and they'll be able to handle any load we can throw at them. I'll blog more about them when they go live.
So, we're set up for our next phase. I can sleep better at night knowing that everything we do is backed up (a first! shame on me!), knowing that we are running as lean and efficiently as we can, and knowing that we have room to grow.
Signs pointed to an issue with our code signing certificate. I contacted the TC TrustCenter support (who issued the cert) via phone, which was totally useless. The guy didn't even ask what happened, he just opened a ticket and 6 hours later I haven't heard back.
Until we get this fixed we cannot ship updates to Mockups, so you can imagine how I felt all afternoon.
I posted on the Adobe Air pre-release forums but heard nothing there either.
To my surprise, the person that answered my chat was extremely knowledgeable and was able to tell me exactly what the deal was.
So I'm sharing it now for those of you in the future who hit this rare issue. Do not panic, your pain is temporary.
So here's the deal: when you sign your Air application with a certificate, it turns out that adt goes out to the interwebs and checks a Certificate Revocation List, i.e. a server that keeps a list of expired or blocked certificates.
Makes sense, except that today ChosenSecurity/TC TrustCenter has had an outage of some sorts that took down their CRL server. They're working on it, and it should all go back to normal tomorrow.
In the meantime, a workaround is to DISCONNECT FROM THE INTERNET and sign your application then. In this case adt falls back to a cached version of the CRL, et voila'! I tried it and it works.
This reminds me of something my "Distributed Systems" professor taught us back in college: "a rigorous, well accepted definition of a distributed system is one in which someone, somewhere, does something...which prevents you from getting your work done".
Yup, check! :)
People from the future: If this article helped you, put a w00t in the comments! :)
The Balsamiq Tech Blog is where our dev team shares our open-source libraries, tips and tricks for programmers and lessons learned while building Mockups on all the different platforms we support.