For the second part of this series I'm going to take a bit of a detour away from the code. One of the things I'm seeing a lot of recently is projects where a huge amount of work is going into shippable features, but not actually shipping anything until the end. Of course you can't ship a 1/2 done product, but you could start shipping a minimum viable product and just because you're "an enterprise" doesn't mean you can't get value from Lean development methodologies.

The happy by-product of shipping early, is that you are forced to think about the deployment process early. Where is this product going to be deployed, how, when? Do you need extra licenses? Do you want to be able to scale it up or out? Will you be able to?

Agile, DevOps, and other associated movements all have one thing in common - it's okay to fail, but do it quickly, and learn from it. If you're not building, testing and deploying your product ASAP then you have a 2, 6, or 12 month lag in your feedback loop. If you start on day 1 with a deployable product, then your stakeholders can start playing around with it from there and give quick feedback before you end up at the end of a misdirected 12 month long project.

With the rise of cloud computing you can easily integrate your source control provider into automated pipelines that will build and publish a website on every check-in. Azure makes this so easy that when you are faced with a situation where you can't use the process it's just downright unpleasant.

Sometimes you will want to have your own build pipeline stack though whether it's for reasons of security, trust or convenience. In these instances I would highly recommend the following products:

1. Git Source Control (Such as GitHub)
2. TeamCity Build Server
3. Octopus Deploy

There's not much you can't do with these three products, each one providing best-of-breed functionality for their particular area and they're easy to integrate with each other to form a good flow.

Keep it Simple

The key to a reliable and repeatable continuous delivery process is to keep things simple. If you can't build it on your local development workstation then you can't expect it to build on a build server. The gold-standard experience is what people refer to as the "F5 experience" - where you can sync down the code, hit F5 and have the application run straight away in Visual Studio. Sometimes this isn't possible, but it's certainly what you should be aiming for because if it's annoying to work in the project developers will get frustrated and less productive.

A recent example of this is a website solution which had around 10 projects in it. There was a hand-crafted build process using a variety of MSBuild tasks like copying files around, building things, then deleting unwanted files under some build configurations. The output was going to a special "build" directory which meant you couldn't just hit F5 and debug the application. By cleaning this process up and consolidating the projects down to just a couple it has reduced the build time from around 8min to less than 2. It's also enabled the use of a single startup project which in turn has allowed the use of the inbuilt Visual Studio debugging support.

What Else?

One thing I haven't really covered here is issue tracking. Github has basic issue tracking, or you can use Visual Studio Online with Git as well - if you go down this track then you get fully integrated work item tracking and agile boards as well.

Anther topic I haven't covered at all is automated testing. My friend and colleague Sam Thwaites is an expert in this area and I'm hoping to convince him to write a blog post on how to integrate this into the flow. Generally we have been using TeamCity to orchestrate the workflow of automating test processes and then pulling the data back into TeamCity for archival and easy access.