Continuous Delivery
Drupalcon Amsterdam 2014
Our goal in this session is to bring enterprise Continuous Delivery (CD) practices to Drupal with a comprehensive walk through of the totally awesome, recently open-sourced CD platform called “Go”: Download Go Open Source. The “Go” project started as “Cruise Control” in 2001, rooted in the first principle of the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.
We’ll start with an outline of the principles of CD practice, and then move right into implementation. The focus of this session is to show just how easy it is to get a Drupal build up and running in “Go”, and along the way illustrate the very nice benefits of delivering in a pipeline. We’ll look at why “Go” can be a game changer in bringing stability to agency practice and for selling Drupal into big projects.
We’ll cover:
-
Core concepts of building a Go pipeline
-
Setting up a delivery pipeline
-
Configuring Build Materials
-
Configuring Build Stages
-
Configuring Build Artifacts
-
Configuring Jobs
-
Configuring Tasks
-
Drill down to familiar Drush commands
-
Implementing basic principles of CD practice
-
Test and preview on production before cutting over a release
-
Zero downtime releases
-
Safe and easy rollback options
-
Making the release a business decision rather than technical decision.
-
Take away objectives
-
How Go’s Trusted Artifacts can take the ambiguity out of the build
-
How to get your money’s worth out of test automation, with an emphasis on BDD
-
Outstanding support for managing dependencies between different projects.
Devs who use Drush, have some grounding in devops, and at least know what an all-in-code delivery is about are going to take in the most from this session. Even so, there’s will be a lot of value in this session for people in less technical roles such as QA, BA and product owner, because CD practice is as much about the interaction of the team as it is about tools and techniques. Everyone on the team needs have some foundation in CD practice and an idea of how those practices map to a delivery pipeline. We’ll keep our enthusiasm for the tool in balance with the importance of engaging the whole team in the delivery process.
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.