Review of SnappHQ

Introduction

I recently had the opportunity to try Snapp, an elastic cloud Platform-as-a-Service for .NET applications. It's the first PaaS that includes a configurable staging and production environments for .NET applications.

Getting started with Snapp was really easy. I just went to www.snapphq.com, clicked "Signup", filled in three form fields (email, password, confirm password), agreed to the terms and conditions and I was ready to get started.

The first thing I did was create an application by clicking the "Create Application" button

 

and then filled in the application name and application description.

I named my application "SimpleApp" and it only took a few seconds for it to be ready.

Next I clicked the "manage" button and I was taken to this screen.

From here I was able to access the staging and production environments, the Publish/Rollback tool, user management and add-ons. Currently the only add-on is the MS SQL database, but the team is working on building an add-on ecosystem.

Snapp provides two development environments: the staging environment and the production environment. In your development cycle you would usually first deploy to staging, run the tests and check if your updates work, and then deploy to production. Snapp makes this very easy to do.

As soon as I created an application I was provided with hostnames for both environments. The staging hostname was staging-SimpleApp-1236.sn-app.com and SimpleApp-1236.sn-app.com for production. It took about five minutes for the hostnames to become available through DNS.

I was now ready to publish my application to the staging environment to try it out. I went to the staging area

and enabled the Git deployment method.

You can also choose between the ASP.NET version that the staging environment will run, enable or disable exception handler, set the number of workers for the webapp (the current beta version limits you to one in staging and three in production), and enable or disable other deployment methods, such as FTP, Web Deploy, and TFS.

I created a very simple "Hello World" ASP.NET application that was just a single Default.aspx file. I then clicked "Manage Git". The Manage Git page provides information on how to push your app to staging. It's pretty simple if you've used Git in the past.

Since I started with a fresh application, I first initialized a new Git repository.

c:\snapphq>git init
Initialized empty Git repository in c:/snapphq/.git/

Next I added the Default.aspx file to the repository.

c:\snapphq>git add Default.aspx

Then I committed the changes to the repository.

c:\snapphq>git commit -m "first commit of simpleapp"
[master (root-commit) aacef3a] first commit of simpleapp
1 file changed, 14 insertions(+)
create mode 100644 Default.aspx

Then I added the remote Git location for the staging environment.

c:\snapphq>git remote add snapp https://git.snapphq.com/staging-SimpleApp-1236.git

And finally I pushed my master branch to the staging environment.

c:\snapphq>git push snapp master
Username for 'https://git.snapphq.com': peteris.krumins@gmail.com
Password for 'https://peteris.krumins@gmail.com@git.snapphq.com':
Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 325 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://git.snapphq.com/staging-SimpleApp-1236.git
 * [new branch]      master -> master

As you can see, Git prompted me for the username and password, which can be really annoying if you're pushing often. The workaround is to include the username and password in the remote Git location like this.

c:\snapphq>git remote add snapp
https://YOUR_SNAPPHQ_USER:YOUR_PASS@git.snapphq.com/staging-SimpleApp-1236.git

In my case it looked like this.

c:\snapphq>git remote add snapp https://peteris.krumins
%40gmail.com:MY_PASS@git.snapphq.com/staging-SimpleApp-1236.git

Now when I made more changes to my app and pushed to staging I was not prompted for the password.

After I had pushed my application to staging, I navigated to the staging URL http://staging-simpleapp-1236.sn-app.com/ and my app was working!

I refreshed the staging area page and it was nice to see the live statistics page that displays the number of requests and bandwidth used.

Now it was time to push it to production! I went to the Publish/Rollback area and clicked the "Publish" button.

I was then greeted with a dialog box that allowed me to enter the notes.

Once I finished entering the notes I clicked "Publish" and a few moments later the page refreshed and I saw a success message.

To make sure it actually succeeded I visited the production's URL http://simpleapp-1236.sn-app.com/ and, indeed, my app was running!

Note that pushing to production should only be done through the Publish/Rollback tools. You can access files in production through FTP, but you don't want to upload files directly to production as it would mess up rollback. For this reason it's recommended that FTP is off for production.

Snapp also supports custom hostnames for the production site. If you go to the production site manager

and click "Manage Hostnames", you'll be able to add your own hostname for your app.

Now I decided to make a change to my application, so I edited Default.aspx, committed the changes to the repository, pushed it to staging again, verified that the changes work, and published my application as v1.1.

It was successful and now the Publish/Rollback page showed the following.

As you can see, v1.1 was now the active version and I was offered an option to roll back to v1.0 in case of an error. Speaking from experience, things do go wrong and having the ability to quickly roll back changes is fantastic!

Snapp also supports multi-developer environments. I was trying this out on my own, but if I had a team of several developers that were using Snapp I would set up an account for each of them in the User Manager area.

Let's say I had John Doe on my team. I'd click the "Create User" button and give him access to the staging environment through FTP, Web Deploy and/or Git.

Once I've added John Doe, he'd be able to setup his remote Git URL to https://johndoe:pass@git.snapphq.com/staging-SimpleApp-1236.git and be able to push to staging. It would still be me, however, who'd have the access to push to production. He would also be able to push to staging through any FTP client if he prefers or straight from Visual Studio through Web Deploy.

It was a great experience trying out Snapp and you can try it out for free too at http://www.snapphq.com. To get started you can also watch the "Getting Started With Snapp" tutorial on YouTube or ask for help on Snapp's forum.

My favorite thing about Snapp is that developers can easily push the code to the staging through Git and see the code live in just a few seconds (probably because my company also built a similar deployment system that allowed us to get code from Git to staging in seconds), but there’s always room for improvements.

One thing I would like to see in future versions of Snapp is support for multiple Git branches and multiple staging environments. When working in a team, developers usually work on different features in different branches. Deploying individual branches to show the changes to the team before merging them to the master branch would rock!

Another feature that I wish Snapp supported is pulling from Snapp’s Git. Currently you can only push to Snapp. Pulls would be a great feature to add, as it would enable one developer to push a quick bug fix to the staging environment while another developer confirms that the bug fix works. Then the developer could immediately pull the fix from Snapp’s staging environment to his own repository.

About me:

Peteris Krumins has years of experience as a programmer, systems administrator, start-up manager, and all around hacker. He is the co-founder of Browserling and Testling, and he runs the popular programming blog www.catonmat.net.