This is Automation Sparta - Umbraco UK Festival 2012

Update: Due to unforeseen time constraints and it being that time of year, I'm going to have to consolidate these posts (mostly) to formal-ish posts on The Cogworks Blog. Those posts will be more business, less waffle any. I wanted to have some less formal personal blog posts regarding this topic, so I'll still be doing the odd one here and there. The Cogworks first post on Sparta starts here.


This post is the first in a set of posts outlining Automation Sparta - a No Configuration setup for Web Development.

"What I'm talking about is automation of the configuration of your automation"

I presented an automation setup yesterday at Umbraco UK Festival 2012, and that quote of mine got a lot of people's attention.

In this post I'm going to talk (very high level) about standardised naming, and how it lead to the realisation that setting up Web Development environments in general can be automated.

It all started earlier this year I joined The Cogworks. Compared to other agencies I have worked at, they had great processes for efficient development and deployment of web applications. They had a some really good templating and automation (eg. Team city build and deployment, and a solid Visual Studio template). This takes away human error, adds consistency yadda yadda. But I also noticed that there were a lot of manual tasks required to configure each process.

I came to realise that inconsistencies in naming between projects was slowing us down. Specifically repositories, databases, IIS sites, folder names, and DNS across the entire Project Universe (environments for Dev, Staging, Live etc).

I've seen this in every agency I've worked in. In any given project (depending on who the developer is), they choose one of these naming schemes: My Project, my project, MyProject, myProject, myproject, my_project, my-project. In one project the database may be called MyProject_Umbraco, in the next it could be Umbraco-myProject.

So the goal was to define and standardise naming for everything in the Project Universe.

When the naming of code repositories, databases, IIS sites, folder names, and DNS across each Project Universe is standardised, you start to realise that much more can be automated. In fact more than anyone in this industry has ever considered. You start to realise that you can automate the creation of your entire Project Universe.. in 1 click! Which is what I demonstrated.

But it doesn't stop there. Once you have automated the Project Universe, you can think about the development setup.

Normally before you even start to code you must:

• Create a code repository (and check out)
• Create a database (with login)
• Create and configure a Visual Studio solution with connection strings, smtp etc.

This is the analogy I gave for the setup required before you even start to program:

Ok, now I can start to program....


Anyway...So now we've automated the creation of our code repository and the development database. We already know the connection string. So why cant we automate the insertion of the connection string into our web.config? Well we can. An MSBuild transform does that for us when we run a Team City build.

So that means we need to automate the insertion of the connection string into the MSBuild file. How do we do that? Easy! Use C# string replace. Template your MSBuild transforms, then use string replacement. Do this for all your environment transforms. You already know the database connection strings! I dont think I can overstate how powerful this one step is. Templating your build scripts opens up a world of possibilities with automation. Think about all the glorious project specific things you can automate now in a build script?

But why stop there? Since we have a Visual Studio template, why not automate project renaming? Ie project files, solution file, namespaces.

So configuring a Visual Studio solution from a template comes down to replacing strings in some files, and renaming a few files and folders.

The result is an application which creates your Project Universe, and spits out a Visual Studio solution with everything ready to go.

Now we're talking about a No Configuration Setup. Yes that's right. A No Configuration Setup for development and deployment of web applications. To be more precise... a setup which has automated configuration of development and deployment, based on standard consistent naming.

"What I'm talking about is automation of the configuration of your automation"

Our exact setup may not applicable to everyone. But from what I've seen in agencies, I think all agencies can adopt an approach that gives the same result. I.e. A No Configuration Setup.

I hope all of this information gives you food for thought about what you can and should automate.

Over the next few weeks I'm going to blog about exactly what is involved in each part of the automation. I'll even give code samples.

If you're interested, keep an eye on this blog and The Cogworks blog