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 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.
 I trust my test suite. You should trust yours, too - or write better ones ;)