Steve Smith

On Tech

Category: Continuous Delivery (Page 7 of 7)

Pipeline Antipattern: Uber-Artifact

17 June, 2012 / / 4 Comments

Pipelining inter-dependent applications as uber-artifacts is unscalable

Achieving the Continuous Delivery of an application is a notable feat in any organisation, but how do we build on such success and pipeline more complex, inter-dependent applications? In Continuous Delivery, Dave Farley and Jez Humble suggest an Integration Pipeline architecture as follows:

Integration Pipeline

In an Integration Pipeline, the successful commit of a set of related application artifacts triggers their packaging as a single releasable artifact. That artifact then undergoes the normal test-release cycle, with an increased focus upon fast feedback and visibility of binary status.

Although Eric Minick’s assertion that this approach is “broken for complex architectures” seems overly harsh, it is true that its success is predicated upon the quality of the tooling, specifically the packaging implementation.

For example, a common approach is the Uber-Artifact (also known as Build Of Builds or Mega Build), where an archive is created containing the application artifacts and a version manifest. This suffers from a number of problems:

  • Inconsistent release mechanism. The binary deploy process (copy) differs from the uber-binary deploy process (copy and unzip)
  • Duplicated artifact persistence. Committing an uber-artifact to theartifact repository re-commits the constituent artifacts within the archive
  • Lack of version visibility. The version manifest must be extracted from the uber-artifact to determine constituent versions
  • Non-incremental release mechanism. An uber-artifact cannot easily diff constituent versions and must be fully extracted to the target environment

Of the above, the most serious problem is the barrier to incremental releases, as it directly impairs pipeline scalability. As the application estate grows over time in size and/or complexity, an inability to identify and skip the re-release of unchanged application artifacts can only increase cycle time.

Returning to the intent of the Integration Pipeline architecture, we simply require a package that expresses the relationship between the related application artifacts. In an uber-artifact, the value resides in the version manifest – so why not make that the artifact?

The Strangler Pipeline – Introduction

18 May, 2012 / / 0 Comments

Continuously Delivering greenfield and legacy applications en masse

I recently gave a talk at Agile Horizons 2012 on behalf of my amazing employer Sky Network Services, detailing our yearlong Continuous Delivery journey and the evolution of our Strangler Pipeline. As a follow-up I intend to write a series of articles on our pipeline, as it is a narrative far removed from the “pipelining a single greenfield application” model often found in Continuous Delivery experience reports.

Sky Network Services is an agile, innovative technology company that produces telecommunications middleware for BSkyB. Despite a plethora of talented technical/non-technical staff and an enviable reputation for delivering quality software, an in-house analysis in mid-2011 identified a number of problems:

  • Many applications used different methods of deployment, start, stop, and database migration in different environments
  • There was little visibility of which application versions were progressing through the test environments at any given time
  • Releasing a minor bug fix for an application necessitated a re-release of the parent platform
  • Development teams and Operations teams were constrained to separate silos

At this point we were attracted to the Continuous Delivery value proposition, albeit with the additional challenge of scaling our pipeline to manage an estate of legacy/greenfield applications that in the past year has doubled in size.

In this series of articles I aim to cover:

  1. Challenges – how we solved the more common Continuous Delivery challenges
  2. Scaling Up – how we scaled our pipeline to manage our ever-growing application estate
  3. Legacy and Greenfield – how we simultaneously release legacy and greenfield applications
  4. Autonomation – how we established a Continuous Delivery transformation across a Waterscrumfall organisation

The Merit of Metadata

19 April, 2012 /

Metadata increases feedback and ensures value stream integrity

In Continuous Delivery, Dave Farley and Jez Humble describe the Lean production principles that underpin Continuous Delivery, and how a pipeline encapsulates a value stream – the journey a customer feature undertakes from discovery to real world consumption.

In a pipeline each stage represents a step in the value stream, meaning that for application XYZ an example value stream of [Development -> Acceptance -> UAT -> Performance -> Production] could be defined as follows:

Pipeline with Metadata

In the above pipeline, each stage ends with a discrete piece of metadata (“created XYZ 2.1”, “XYZ 2.1 passed acceptance tests”, etc.) being written back to the binary repository, indicating that one or more new customer features have progressed in the value stream.

Unfortunately, pipelines are often constructed without metadata support:

Pipeline without Metadata

In this situation the lack of activity data reduces each stage to a fire-and-forget operation, constraining feedback and unnecessarily exposing the value stream to obtuse, time-consuming errors. For example, QA could mistakenly test new features that have not passed automated regression tests, or Operations could mistakenly release features that have not been signed off.

With metadata the following safeguards can be easily implemented:

  • Check if binary actually exists e.g. “can XYZ 1.2 be retrieved for deploy to Production”
  • Prevent binary re-entering a previous stage e.g. “once XYZ 1.2 has passed or failed Acceptance, the result is final”
  • Ensure binary has successfully passed sufficient dependencies to enter a stage e.g. “XYZ 1.2 can only enter Production once it has successfully passed UAT and Performance”
  • Introduce a manual sign-off process for critical environments e.g. “XYZ 1.2 can only pass UAT when exploratory testing is complete”
  • Visualise pipeline activity e.g. “I can see XYZ 1.2 was successfully released to Production a week ago, and that 1.4 is the next viable candidate as 1.3 failed Acceptance”

These features ensure fast feedback is always available and that the pipeline is an accurate representation of the underlying value stream. An absence of metadata unnecessarily hinders these goals and suggests a failure to understand the core values of Continuous Delivery.

Pipeline Antipattern: Deficient Deployer

14 March, 2012 / / 0 Comments

A badly-defined Deployer abstraction impairs Continuous Delivery

As Continuous Delivery patterns are gradually establishing themselves, antipatterns are also surfacing – and a common antipattern is the Deficient Deployer.

When we talk about a Deployer, we are referring to a pipeline task that can be invoked by any post-Commit stage to deliver an application binary to an environment. A Deployer interface should look like:

Deployer#Deploy(Application a, Version v, Environment e)

There are a couple of ways Deficient Deployer can creep into a Deployer implementation:

  • Anemic implementation – this is where the Deployer behaviour is solely specified as “download binary and copy to environment”, ignoring any one-time operations deemed necessary for a binary to be in a valid state. For example, environment configuration should be filtered into the application binary during deployment, as it is a one-time operation decoupled from the application lifecycle. If this configuration step is omitted from the Deployer, then additional manual effort(s) will be required to make the binary ready for use.
  • Over-specified interface – this is where environment-specific parameters are added to the Deployer interface e.g. Deployer#Deploy(Application a, Version v, Environment e, Server s). The server(s) associated with an environment and their credentials should be treated as an implementation detail of the Deployer via a per-environment server mapping. Application version, and environment are the only consistent mandatory parameters across all environments.

The root cause of the Deficient Deployer seems to be a reluctance to treat deployment scripts as first class citizens.

The Value Proposition for Continuous Delivery

13 March, 2012 / / 0 Comments

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

In November 2011, Dave West argued that “Water-Scrum-Fall is the reality of Agile for most organisations today“. Dave suggested that in many Agile organisations the Agile process in Development (“Scrum”) is constrained by culture and governance in both Business (“Water”) and Operations (“Fall”), and that such an organisation “fails to realise Agile’s business benefits, such as faster time-to-market, increased business value, and improved flexibility and responsiveness“. This can be summarised as:

Agile has transformed software development, but not product development

By definition, software can only generate revenue when it is in Production. However, Dave Farley and Jez Humble assert in Continuous Delivery that such common sense is not common practice in the software industry, saying that “in most organisations the release of software into Production is a manually intensive, error-prone, and risky process“. The high-cost, high-risk nature of this scenario is the root cause of the low frequency release policy so common in the industry, where stability is favoured over flexibility.

Dave F and Jez go on to argue that such a release policy is inherently expensive, stating that “every week of delay between having an idea and releasing the code that implements it can represent millions of dollars in opportunity costs“. The elapsed time between feature inception and feature delivery is the cycle time of an organisation, and by establishing a regular cadence of Production releases we can reduce cycle time and as a consequence dramatically improve throughput.

Enter Continuous Delivery, which is defined as “releasing high quality software fast through build, test and deployment automation“, and has been adopted by organisations such as Facebook, LMAX, and TheTrainLine to create reliable, repeatable, low-cost delivery mechanisms that release software to Production on a weekly or even daily basis. Such significant reductions in cycle time mean that more time can be invested back into product development and revenue growth, while the reduction in batch size provides faster feedback and reduces risk.

This is the value proposition of Continuous Delivery – firstly, “that we now have the tools, patterns and practices to drive down the transaction cost of releasing a change enormously“, and secondly that by fostering closer Development/Operations partnerships (such as DevOps) the artificial boundaries within “Water-Scrum-Fall” organisations can be dismantled.

Newer posts »

© 2024 Steve Smith

Theme by Anders Norén — Up ↑