Agile Glossary

Continuous Deployment

What is Continuous Deployment?

Continuous deployment can be thought of as an extension of continuous integration, aiming at minimizing lead time, the time elapsed between development writing one new line of code and this new code being used by live users, in production.

To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meets these release criteria, the live application is updated with new code.

Instrumentation is needed to ensure that any suggestion of lowered quality results in aborting the deployment process or rolling back the new features, and triggers human intervention.

Expected Benefits

The main benefits claimed for continuous deployment arises as a result of reducing lead time, with two main effects:

  • earlier return on investment for each feature after it is developed, which reduces the need for large capital investments
  • earlier feedback from users on each new feature as it is released to production, which affords techniques such as parallel (or A/B) testing to determine which of two possible implementations is preferred by users

Common Pitfalls

to the extent that continuous deployment is viewed as a strategy for quality, it’s easy (in particular for developers enamored with the novelty and technical aspects of it) to pick the wrong target and optimize for “maximum frequency of deployments” – that will not, by itself, result in increased quality

Potential Costs

  • continuous deployment relies on extensive instrumentation to ensure that functionality newly made available to users does not result in incidents, lowering externally perceived quality
  • for the same reason, continuous deployment relies on infrastructure that allows easily backing out new features when a defect has not been detected by automated tests

Origins

  • 2002: in early (unpublished) discussions of applying Lean ideas to software, seeing undeployed features as “inventory”, Kent Beck mentions continuous deployment at LifeWare and “several others”; it will take several years, however, for the idea to be refined and codified
  • 2006: the first conference article describing the core of continuous deployment, “The Deployment Production Line” by Jez Humble, Chris Read, and Dan North is published in the proceedings of Agile2006, a codification of the practices of several Thoughtworks UK teams
  • 2009: the practice of continuous deployment has become well established, though still somewhat controversial as a much commented upon article, “Continuous Deployment at IMVU” by Timothy Fitz attests; it has become important not only in Agile but also as a core element of more specialized, recent strategies such as Lean Startup or Devops

Further Reading

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs. LEARN MORE >

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

The scrum master is the team role responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use.
The acronym INVEST stands for a set of criteria used to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it.
Class Responsibility Collaborator (CRC) Cards are an object oriented design technique teams can use to discuss what a class should know and do and what other classes it interacts with.
An approach to estimation used by Agile teams. Each team member "plays" a card bearing a numerical value corresponding to a point estimation for a user story.
Refactoring consists of improving the internal structure of an existing program's source code, while preserving its external behavior.
Agile teams generally prefer to express estimates in units other than the time-honored "man-hours." Possibly the most widespread unit is "story points."

Help us keep the definitions updated

Ready to join Agile Alliance?

Unlock members-only access to online learning sessions, Agile resources, annual conference discounts, and more! And when you join, you’ll be supporting our member initiatives, regional events, and global community groups.

Privacy Preference Center

IMPORTANT: We have transitioned to a new membership platform. If you have not already done so, you will need to SET UP AN ACCOUNT on the new platform to establish your user profile. Your previous login credentials will not work until you do this set up.

When you see the login screen, choose “Set up Account” and follow the prompts to create your new account. You can choose to log in using your social credentials for either Google or Linkedin (recommended), or you can set up your account using an email address.