Code Shipping - Continuous (Deployment|Development|Delivery)

Card Puncher Data Processing


Continuous deployment reflects the habit of deploying new code as a series of small changes as soon as they are ready.

Continuous deployment is also known as:

Continuous deployment is typically performed with snapshot versions.

Continuous Deployment follows your tests (continuous integration ) to push your changes to either a staging or production system.

See also: Code Shipping - Workflow (Agile, MVP, Scrum, Waterflow, Kanban)

(Development|Deployment) Cycle

There is still a distinction between code in development and code that is ready to be deployed. Developers use a version control system (git,…) for their daily work, until the code is ready to push.

The stable version for deployment is maintained in a branch. When ready to be pushed, new code must first be merged with the stable version in the centralized repository, after which engineers can commit their changes.

Some of the factors going into the determination of the optimal deployment cycle are:

  • the cost of each deployment,
  • the probability and cost of errors,
  • the probability and value of incremental benefits,
  • the skill of the engineers involved,
  • and the culture of the organization.

Adding to the complexity of the decision is that many of these factors can be optimized, so the optimal cycle can change.

Feature with large changes to the codebase

Ostensibly, rapid deployment is at odds with feature development that requires large changes to the codebase. The solution is to break down such changes into a sequence of smaller and safer ones, hidden behind an abstraction.

See Code Shipping - Feature Development / Planning


Immediatly availabe to a a small subset of users

Deploying new code does not necessarily imply that it is immediately available to users. Facebook uses a tool called “Gatekeeper” to control which users see which features of the code. Thus it is possible for engineers to incrementally deploy and test partial implementations of a new service without exposing them to end users.

A/B testing: Live experimentation

An important attribute of continuous deployment is that it facilitates live experimentation using A/B testing. The innovations that engineers implement are deployed immediately for real users to experience.

A/B testing is an experimental approach to finding what users want, rather than trying to elicit requirements in advance and writing specifications.

This enables a careful comparison of the new features with the base case (that is, the current site) in terms of their effect on user behavior [5].

While this typically involves only a small subset of users, at Facebook’s volume of activity even a very small subset quickly generates enough data to assess the impact of the tested features. Thus engineers can immediately identify what works in practice and what does not.

Reduces the risk

Frequent deployments imply that each deployment introduces only a limited amount of new code. This reduces (but doesn’t eliminate) the risk that something will go wrong.

All commits are individually tested for regressions.

Deploy Often Time Cost Risk

Easily identify the source and solutions of problems

Another benefit of small and rapid deployments is that we can easily identify the source of and solutions to emerging problems: they’re most likely the most recently deployed changes in the code, and still fresh in engineers’ minds.

No long-lived branches to merge

All front-end engineers at Facebook work on a single stable branch of the code, which also promotes rapid development, since no effort is spent on merging long-lived branches into the trunk.






Documentation / Reference

Discover More
Card Puncher Data Processing
Code Shipping - Change and Deployment Pipeline - Development Lifecycle / Workflow

Deployment pipelines describe how a change in your application moves through your infrastructure into production. It lays out all necessary automated and manual steps. Every step that can be automated...
Card Puncher Data Processing
Code Shipping - Continuous Integration

Continuous integration is just a fancy term for a build kicked off by a VCS commit. Continuous Integration is the practice of testing each change done to your codebase automatically and as early as possible....
Card Puncher Data Processing
Code Shipping - Devops

Devops: Teams of Devs and Ops. DevOps is a software development method that highlights collaboration and open communication between teams. DevOps teams are composed of: developers and operations...
Card Puncher Data Processing
Code Shipping - Feature Development / Planning

An application is composed logically from one or more features. jobYTQTgeUE?t=842Philip Fernbach - Why do we believe things that aren't true? Features can be in one of 4 states: Internal Incubating...
Card Puncher Data Processing
Code Shipping - Snapshot Version

Continuous development is typically performed with snapshot versions. The actual version is generally composed of a date/timestamp and an enumerator.
Card Puncher Data Processing
Continuous Delivery

is the concept of frequently delivering updates to your software application. same as ?
Card Puncher Data Processing

is continuous deployment platform. runs jobs. When running the current directory is the workspace. A build is the execution of a job. A TriggerTriggers can run a job periodically. home directory:...
Card Puncher Data Processing
Version Control - Tag

A tag is a snapshot of the whole source code at a current time. A tag is generally made after a successful build on the master branch to release the code. It's then called a named or numbered releases....
Card Puncher Data Processing
What is Infrastructure as code? (Configuration, Provisioning, and Software Deployment)

Infrastructure as code means that all ops operations are scripted and are found in code. They are used in DevOps pipeling for continuous deployment You will find three kind of software in this area:...

Share this page:
Follow us:
Task Runner