In the previous post in this series, Building Tweets from the Vault: Minimum Viable Product, I wrote about the absolute minimum feature set to get Tweets from the Vault off the ground.

In this post I’m going to write a bit more about some of the technology choices. So… what were they, and why?

Azure + TeamCity + Octopus Deploy

Obviously, I was going to need a hosting platform that was easy to get started with but that could scale if (when? ha!) my app hits the big-time. The app (and the article you’re currently reading) is running on Azure VM-hosted IIS deployed to via Octopus Deploy.

To ship a feature

git add -A .
git commit -m "Added some feature"
git push

TeamCity will pick up that change, build it, run my tests, push a package to Octopus Deploy and then deploy that package to my test environment. A quick sanity-check there[1] and then it gets promoted to the live Azure environment. Using this tool suite a change can go from my MacBook to production via a sensible build + test + deploy pipeline in under two minutes.

For anything more complicated, I’ll use a feature branch. TeamCity will automatically pick up and build refs/heads/* so all of my branches get the same treatment, all the way through to packaging in Octopus and deploying to a test site.

Hotfixes are treated in the same way as feature branches. If I have to revert to any particular revision, it’s simple:

git checkout some-hash
git checkout -b hotfix-some-fix
git add -A .
git commit -m "Fixed some bug"
git push

That build will go straight to my test environment through the normal build + test + deploy pipeline and I can then tell Octopus to promote that hotfix package to production. No mess; no fuss.

In the next posts in this series, I’ll write a bit about Bootstrap and NancyFX.

[1] I trust my test suite. You should trust yours, too - or write better ones ;)