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.

Constantly over the past few years I’ve thanked my lucky stars that I’ve had continuous integration and deployment setup for the web sites I’ve been working on. It is one of the few development opinions where I break the “religion and politics” laws of social etiquette. I feel incredibly strongly about the benefits that having a good Continuous Integration and Deployment story can bring to a project and it’s team. Sadly, not everyone has been able to experience the awesome sauce of CI/CD. I’ve been working hard to change that.

When writing testable code your first port of call is often to abstract any dependencies and make them easy to mock. This is the same for any of your codebase that talks to FTP servers. Testing the way your code behaves under real world conditions makes integration tests important regardless of abstraction though. Here’s a simple trick to test FTP code in the wild.

Microsoft developers hear a lot about tools that will make them write faster, more efficient, more refactored, more unit tested code all the time. People don’t often talk of tools that help you to visualise your project’s growing code smell though – among other reasons, everyone’s inner sense of pride may be a behind this, however unless you or your employer has forked out the $11,879 odd dollars for Visual Studio Ultimate Edition you don’t have much to go on without more than the basic reporting on Cylcomatic Complexity, Dependency Depth and Class coupling reports that come in the pro and premium editions. These don’t really help you pin point any of your architectural problems that well – something  where NDepend proves itself to be a diamond in the rough.

Jetbrains’ build server software TeamCity is an awesome product to get up and running with continuous integration and deployment, however with its ease of operation it leaves a few nice to have business features aside. One of these is Scheduled backup – and if there is anything that your career has probably taught you to date, it’s that when things break, having a backup is priceless.

TeamCity is one of the greatest tools to hit the Continuous Integration world, with free licensing for 20 build configurations and an easy to use interface it ticks all the right boxes (not to mention ease of use for Windows Users) – but once you splash out on an Enterprise license and grow your installation to house many build configurations you start to want more power, and this is when a second build agent is your ticket to freedom.

When updating a project’s Database Schema as part of your deployment strategy, you want to automate as much of the process as possible to avoid human errors. If you have a Visual Studio Premium installed on your build server, generating schema update scripts is easy to achieve with the built-in database tools that the IDE contains. I will show you how to do this easily and also automatically deploy the changes to your destination server with the awesomeness of TeamCity.

I have recently had a couple of interesting discussions with a different people on twitter and “the real world” about the use of third party build dependencies such as unit testing frameworks, database versioning tools and other command line executables in your build. The topic of these discussions has been about where these dependencies should be located, inside your project, or installed on your build server.

Last week i had the awesome honour of being at a tech talk on Continuous Delivery by “the great” Martin Fowler, Neal Ford and Evan Bottcher, put on by Thoughtworks here in Sydney. I have spent the last two years of my life evangelizing on the benefits of Continuous Integration and Continuous Deployment to anyone who would hear me all on my own terms and entirely self taught in the dark. I have selected snippets and ideas from other peoples documented ways on how they achieve Continuous Deployment, but the experience of listening to pioneers in this space was a truly awesome experience.

These days IIS has so many bells and whistles installed that it can be hard to find the settings panel that does what you want it to do (or if you’re an IIS 5/6 guy like me you may just get lost in general some times). The one thing that is lacking as a feature in IIS is log file recycling. If you manage an IIS installation of any decent size, you’ll know first hand how quickly log files can fill up a server’s hard disk, and bring it to its knees if not managed properly – how do i take care of this?

SQL Express is pretty awesome as a light weight database server, and when Microsoft released it using the same database engine as the full version they did the world a huge favour. I have seen SQL Express in use on a lot of Virtual Private Servers & development boxes, but in most cases users don’t backup their databases regularly because of the missing scheduled jobs functionality that doesn’t ship in the Express version of Microsoft SQL Server. Like most limitations there is an easy way around this.

Test Driven Development, Behaviour Driven Development, Extreme Programming and many other new-age hippy development methodologies have spread through the development world like wild fire. I believe there is room for one more in the shape of Build Driven Deployment/Automated Deployment - A new source of confidence in the development world. Time to go out and spread the word.

Having a good Continuous Integration setup is the gift that keeps on giving, but what about your database? For most web applications these days, your database is a large part of your application – so why is versioning it such an uncommon thing? Because it’s time consuming and complicated – two requirements that Continuous Integration love conquering with a one-two punch.

Deploying in an automated fashion using Continuous Integration doesn’t happen instantly, and depending on the size of your application, your continuous integration deployment can get caught in a state of unknown/in-between if a user visits your application half way through deployment. This can be far from optimal, but ASP.Net has a trick up it’s sleave in the form of the App_offline.htm file.

Having a good Continuous Integration setup can be one of the highlights of any developers daily grind. Regardless, it can be seen as almost pointless if your automated deployment setup still needs a physical person to upload the files to your server if it is offsite. Adding FTP/SFTP to your CI process is the solution to this.

One of the continually high risk and sometimes fiddly operations in web deployment is a web application’s deployment, and yet a lot of people working in smaller teams seem to have become stuck in the land of cowboys because the task of automated deployments seems either too difficult, too time consuming to setup or is perceived as un-needed. I’m about to attempt to prove all of these things wrong, while at the same time allowing you to get back to doing what you do best: write code.