What are the steps to do a Balsamiq Mockups release?

We do a lot of releases at Balsamiq.

After all the code is in and all the devs and testers give the build the go ahead, what are the steps to get the new release out the door?

In this video you see Peldi going through the steps for this release.

The video is sped up 2x, and only minimally edited. Grab a cup of coffee, go full screen, sit back and enjoy! :)

If you see something we could improve, let us know in the comments below, we're all ears! :)

Music credits: songs by "The Bird and The Bee", from their excellent "Ray Guns Are Not Just the Future" album.

Prepping for Growth

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.

Onward!

Video: A first look at Bazaar

· Posted by peldi in Videos · 7 Comments

Hi there. So Luis came to our office in Bologna for a couple of days, which was great.

We took the opportunity to take a look at Bazaar, the source-control system used by Ubuntu, mySQL, GNome.

Luis likes it more than Git, and we've been using SVN all this time, which I hear is "the old way" of working.

Anyways, we thought we'd record the session to share it with you...who knows, it may be useful if you're like me and still don't "get" these new ways of sharing your code...

Warning: the video is unedited and 48 minutes long.

In the end, I wasn't totally convinced but I'm willing to give it a try. We'll port our myBalsamiq code-base to Bazaar after our next beta refresh release and see how it feels.

What do you think? Will we ever go back to SVN?

Peldi

Error creating AIR file: Could not BER decode the CRL.

Today, out of the blue, our Mockups for Desktop build started failing with the cryptic error above.

A Google search didn't turn up much, while a Bing search returned this seemingly abandoned Flex bug (#FB-16236).

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.

I did eventually find a solution though: I went here: http://www.chosensecurity.com/adobe-air-certificates and since the links on the page were broken I reluctantly clicked on "Chat Now", at least to tell them about their broken websites.

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.

Hurray!

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! :)

Peldi

People from the future: If this article helped you, put a w00t in the comments! :)