Leadership musings and hackery from the Perl generation...
If your engineers build systems but never get woken up when those systems fail, you don't have DevOps. You have developers who throw code over a wall to someone else. The "Ops" in DevOps isn't a label - it's a commitment to owning what you build, all the way through to 3am when it breaks.
In DevOps, the two-person rule is a widely adopted practice for ensuring accuracy and safety in critical operations. However, Software engineering teams arent the only ones applying similar techniques - what if we could take this inspiration to further improve the two-person rule? Enter Shisa Kanko, a Japanese technique that’s been used to enhance protocols in all parts of Japanese life.
Engineering teams practicing DevOps strive to improve the way they build, ship and operate their software while avoiding customer impacting outages. Parts of this problem can be solved through automation that reviews and monitors your codebase before and after release, taking action before a human operator even investigates an event. One of the hardest parts of reducing system outages completely is that software still involves human, and human involvement always brings its own set of challenges.
Now that we're all configured at Amazon and we've got our solution in a state where we can easily package and deploy it's time to automate it all with TeamCity so you don't have to have any human intervention when you want to fire up a new instance of your website for testing.
Now that we've successfully setup your Amazon AWS account start new machines and serve any WebDeploy packages we'll be using during automation, its now time to get our website project in a state that will work with our Amazon AWS account and this includes some PowerShell Automation to bring it all together.
Over the last year I’ve gone crazy for some of the new automation tooling that developers have had made available to us to help setup continuous integration. The whole idea of infrastructure as code isn’t a new thing, the *nix crowd has had Chef and Puppet for years – last April Amazon added support for batch and PowerShell scripting on Windows EC2 instance initialisation, and this gives us the ability to do some pretty powerful server and website automation such as servers that initialise and install their own services and websites – potentially on command to fire up a new testing instance or automatically handle load.
Continuous Deployment is an time-saving, team-loving, kudos-earning, stress-reducing capability that any team is wise to implement. OnCheckin is definitely aiming to bring this awesome’ness to as many ASP.Net developers as possible by making it fast and easy to setup. Once you’ve started out automating deployment though iteration is the key. Deploying your website early and often is great but with OnCheckin this goes further – Add-ons. And where better to start than helping developers out than with an often overlooked part of web development: Application Security.
Over the years I have had the luck to work alongside many really smart, switched on people in the development community. I’ve learnt from them many intermediate and experienced programming skills. Generally when it comes understanding the very basis of how the internet functions using DNS, most of these very same experienced developers haven’t got a clue. I wrote this post to hopefully help pay back some of the awesome karma they have earned helping me over the years, by teaching them something in return. Lets learn about DNS.