Zend sponsored and attended the 1st Pipeline Continuous Delivery Conference in London on 8th April 2014. We met and spoke with folks from the BBC, investment houses, Nomura, Volvo, media agencies, etc. – a good mixed crowd, mostly technical. The conference offered a great collection of sessions. Here are a few take-aways from them.
Dave Farley headlined the conference and led with his view of the evolution, reasoning and need for Continuous Delivery – as you would expect, his insights were fascinating. He referenced studies from McKinsey, KPMG, etc. to state the simple fact that most software projects were delivered badly. One McKinsey report stated that 17% of the projects were so bad that they threatened their organisation’s survival(!), and overall only 2% of projects were delivered as the business desired. Dave also spelled out that the evolution of Continuous Delivery was based in the tried, tested, and trusted scientific method of Characterization, Hypothesis, Deduction, Experimentation (basically iterative, proven, and reliable); and how old industrial approaches like the Demming Cycle (Plan/Do/Check/Act) which revolutionized the Japanese industry post-war had a direct influence on Continuous Delivery.
He provided more stats on the comparison between Waterfall and Agile/Lean/Iterative approaches, to help define what really works – drawing to the conclusion that minimizing the time we’re exposed to the risks of human intervention is best, and quicker feedback loops at all levels ensures better results.When he compared the relative cycle times (time taken to get even the smallest change into production) of a waterfall project vs. Continuous Delivery the result was impressive: 103 days vs. 57 minutes.
We also attended a talk by Allan Kelly on Conway’s Law, which also provided some fascinating insights. According to the talk, organisation design has a very strong influence on any system design – e.g. if the org has a database team, server team, etc. you will find that projects are initiated along these lines (i.e. a database tier, a server tier, etc.). Even before a single line of code is written, the org structure has set up a big team.A large team will result in a large design, a large project, etc. – when usually small would have been enough.
Allan gave some guidelines for Continuous Delivery, as for example:
- To include all teams (dev, test, project management, etc.)
- To keep communication paths short
- No divides – no Us and Them mentality
Overall, Pipeline was a very good and informative event – and there’s something else that we could take away from it: i.e. how much the automation & insight built into Zend Server fits with the Continuous Delivery ethos and vision.
- If you have a PHP environment, and want to adopt Continuous Delivery, then Zend Server will automatically provide the 1-click deployment, the standardization of environments, the single point of reference/control/monitoring for all teams, the ease of communication between dev & ops, the traceability and accountability that’s needed to ensure issues are resolved quickly (code-tracing being amazingly useful in reducing the arguments that occur between teams when there is a production issue!).
- And, crucially, for the larger organizations, Zend provides the commercial support & backup of both Zend products and PHP that is essential to running a low-risk and hassle-free production operation.
Put simply, if you have PHP, then Zend Server will take you from 0% to 75% on the Continuous Delivery adoption path – and will free up your teams’ time to do more productive things for your business, will lower the risks of your deployments, will ensure any problems are resolved quickly and without fuss, and ultimately will make your business stronger and more able to accommodate whatever the future throws at you.
Image Credit: Chris O’Dell via Flickr