Skip to content →

Category: Development Process

Principles for building a Successful Continuous Integration System

Below is a list of the core principles that have defined the  CI solutions that I have built over the last few years.

Use the lowest common denominator in technology for scripting

This has meant that the main workflows have been written in PowerShell rather than MSBuild or Nant as its more accessible, a terser language, can use .Net framework directly & debuggable.

I have seen too many systems that need loads of dependencies installed before you can run a build e.g. Using Ruby as a build language

Everything should be in source control

As a developer I want to install VS & SQL, get latest, build and go.

That means no “installed” dependencies, they all need to be mapped into the source tree or pulled in from Nuget

No build masters

The build should be something that everybody understands, can fix and improve

Team leads should be the custodians of a project build as they are the people that should have  the big picture view of a project

You broke it you fix it

Exactly what it says on the box. It does not matter if its a code, unit test or build script failure. If you changed something that means the build has stopped working then you fix it.

Same build for local as remote

A lot of build systems hold the configuration on the server, I believe this to be wrong.

I want to be able to run the same build that’s on the server on my local machine before I commit
Everything the build server does should be available for me to me locally.

Dashboards & emails are great but a flashing light is better

The last system I built had a flashing tractor light and a USB Santa drumming Christmas tunes when the build was broken, makes things a little more fun!!!

The below books really shaped my attitude to CI and contain invaluable information.

http://pragprog.com/book/auto/pragmatic-project-automation

http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912

Leave a Comment

A/B Testing – Should you use it and if so, when?

Imagine making a change to your site based on a gut feeling and then moving on to the next thing without actually being able to prove categorically, that the change had a positive influence on your business. Perhaps you don’t have to imagine that – you do it every day! So imagine being able to make a change and actually measure whether it has made a positive or negative impact on your KPIs (Acquisition, Activation, Retention, Referral, Revenue).  All the big companies (Google, Microsoft, Facebook etc.) are using A/B testing to enable them to measure each change. But when do you use it?

A/B testing presumes that you’ve already bottomed out your problem solution and are now working on scaling, or product market fit. So in essence you know what your product is and now you need to optimise it. Those optimisations could be big or small and we would advocate for being bold in trying out big changes to get some strong measurements back out to learn from. But here’s a presentation that gives examples of what you can do with A/B testing and why a test someone else has run should not necessarily be used to determine what you do.

[gigya src=”http://prezi.com/bin/preziloader.swf” allowfullscreen=”true” allowscriptaccess=”always” width=”500″ bgcolor=”#ffffff” flashvars=”prezi_id=huzarjynislw&lock_to_path=0&color=ffffff&autoplay=no&autohide_ctrls=0″ ]

Leave a Comment

A working app in production in a week?

I strongly believe that the only way to build successful products is to get them in front of your customers. This can often be rather difficult when it comes to setting up a project as you have to buy production hardware, set up a delivery process etc, something that is often ignored at the early stages of a project and as a result the architecture that gets built becomes expensive to manage and the cost of change starts to increase. To prevent this from happening I start with a delivery runway.

You could consider the runway the equivalent of a production line in a car factory. You could build the car in your shed in an adhoc process, but this will not scale as you want to build more. So I look for and adopt technologies that make sure that the first line of code written is deployed into a working production environment. Further to this, I like to deploy to production everyday or even multiple times a day. By reducing the amount of change thats deployed you reduce the amount of risk associated with it, reduce risk and we reduce cost. That means more money to spend on the features of your product that will make a difference.

Having run many enterprise scale solutions in the past it is incredible how much time/cost can be consumed in compiling a release together when a delivery process is absent. Doing this at the end of a long term development cycle creates such a barrier to delivery that it makes many software products uncompetitive. By embracing change and building an infrastructure to deliver that change we can adapt to market shifts.

I am definitely not the first to implement a continuous deliver process and the below presentation from Chad Dickerson CEO of Etsy explains the process and value with a few graphs thrown in.

Leave a Comment

How to justify an agile process?

I often get asked “How much will it cost?” and “How long will it take to build?” which are really difficult questions to answer when you dont have all of the information. This is often compounded  Agile world because the person asking the question may not really understand everything they are asking for.

Why? Building great software is really hard. Infact most software projects fail. As a result it seems pretty obvious to me that we need to change the way we think about projects and that can start with the commercial negotiations.

The below slide deck from the CFO of SolutionsIQ explains, in real money terms, why agile projects win hands down. It also includes graphs and stats that provide a more quantifiable reason to use Agile instead of the Waterfall process

Leave a Comment