While looking into options for hosting, virtual private servers, etc., I remembered hearing about AppHarbor and decided to check it out. Note that this is all based on Git, so if you aren’t familiar with Git (protip: you should be), you might to start there. Watch this space for an upcoming series introducing Git to those coming from the TFS/SVN world; in the meantime you can check out the documentation or this TekPub production.
Note: devstoprocks is just used in these screenshots as a sample. It doesn’t really exist, or if it does, it’s not ours.
When you first arrive, you’ll want to look for this button near the bottom right of your browser:
You’ll be prompted to fill out a truly minimal amount of registration information: email, username, and password. After taking action on the confirmation email, you’ll be ready to get started.
Creating your first app
As is often the case, the hardest part is coming up with a name. In fact, that’s the only part.
Pushing the app
AppHarbor will create a .git repository that you’ll want to commit to, and it’s not too difficult to see where it is.
Even if you’ve never used Git before, I think their instructions are pretty easy to follow. Since they’re on your app’s dashboard at this point, I’m not going to fully duplicate them here. The basic idea is
- Create your solution
- git init so that the .sln is in the root
- Add a remote to the repository AppHarbor created for you
- git push it up
Test Driven … Deployment!
This is where it gets really interesting. In the image below you’ll see a table of builds. Every time I git push to my AppHarbor remote, it triggers a build.
What’s going on here?
- This is where you can see the time that the build was deployed.
- Note that this build is “active”. That’s what’s out on your site right now. It may not necessarily be the latest build.
- You can see the details for any build. This is particularly useful when the build fails. You’ll get full details of what errors occurred in the build or your unit tests!
- You can always restore a previous version of the app providing that it was a successful build.
Failure is not an option
Note that I said, “providing that it was a successful build.” If the build failed – even if it was just a broken unit test – the build is disqualified. To my knowledge, this is not just a default; there is seriously no way to deploy a build of degraded quality. This is of course predicated on the condition that your tests are properly reporting your build quality.
“The old version was better”
Even if your build succeeds and all the tests pass, there’s no accounting for taste. If you or your [collaborators, customers, managers, stakeholders, …] don’t like the fluorescent magenta that just got added to the css, you can always go back to a previous version with a single click (see point 4 above).
What’s that about WatiN?
I had stepped away for about an hour and a half, and then I decided to check on automated browser testing with WatiN. I haven’t had much luck with that, and the recommendation seems to be to put those tests in a separate project, make a secondary .sln file that doesn’t include that project, and push that one to AppHarbor. I’ve seen that recommendation here and here. I’d be interested to know if anyone has any other ideas.
Using your own domain
AppHarbor will set up a URL for you right away, but it will be something like http://project-777.apphub.com. Do you think Facebook and Twitter would have taken off with an URL like that? I don’t either, and it seems that the guys behind AppHarbor feel the same way.
When you’re looking at your app, you might notice a lot of settings to the right-hand side of the secondary bar. Let’s take a look at hostnames.
You’ll be told what IP to use in your A record. AppHarbor won’t update it for you, but they will bind the hostname you provide to your app. That’s it. You’re good to go.
Would you pay FREE DOLLARS?!
Your first server is free, and AppHarbor will also give you a 20MB SQL Server or MySQL database for free. As your app scales, you can always pay to add additional servers, upgrade to a 10GB database, etc., but there’s no reason not to give this a spin and get started today.
AppHarbor could very well be a revolutionary deployment and hosting solution and is at least a fun toy to try out. It’s insanely satisfying to git push from the command line, read output telling you that a build was queued, and then watch it in the web dashboard.
It took me much longer to draft this post than it did to do everything I’ve done with AppHarbor. It took me literally five minutes to register, create the app, and deploy it three times to experiment with unit tests. Granted it was a skeleton app with one test, but the point of this exercise was to evaluate AppHarbor and not to spin up a new project.
This post originally appeared on The DevStop.