This is the third post in a series about Lean Startup on elmah.io. Check out the other posts here:
- Introduction
- Minimum viable product
- Continuous deployment
- Split testing
- Metrics
- Pivot
I’m on a path to release every change to production. All of my web apps are automatically deployed to Microsoft Azure, using the deployment engine Kudu. I’m using staging environments for the web apps and auto-swap into production after warming up the website (as described here). I still click swap manually on the user facing websites, but that’s something that I’m working on eliminating as well.
Most of the background services on elmah.io are run as Azure Functions. Like web apps, Kudu automatically deploys all changes to Microsoft Azure. Unlike web apps, Functions are deployed directly to production. Why the difference you may think? Well, it’s simply a matter of history. All the services written as Azure Functions, are built with continuous deployment in mind, while the web apps still miss a few points. Furthermore, all the services run async from the normal usage on elmah.io either through a schedule (like daily digest email) or are triggered by messages on an event topic (like handling a new error report from the user).
I sometimes need to do some stuff when deploying new versions of the software (like sending a Slack notification or calling the elmah.io deployments endpoint to make Deployment Tracking work). I use a combination of Zapier and custom Post Deployment scripts. Zapier is a great platform for connecting different services. You can think of it as IFTTT for SaaS applications. Post deployment scripts is a feature in Azure, which can run PowerShell scripts as part of the deployment magic happening inside Kudu.
I’ve used both Octopus Deploy and Visual Studio Team Services with great success in the past. Implementing continuous deployment using one of those tools has often surfaced in my mind, but Kudu works so good, that the cost benefits of switching simply don’t add up.