Code Shipping - Change and Deployment Pipeline

1 - About

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 should be, to make the deployments as productive as possible.

If there's something potentially risky in the pipe we'll build out before pushing that so it can be deployed by itself.

This section talks also about software product development practices.

Less Work, More Production ! Jason Fried

3 - Deployment Automation

See Code Shipping - Continuous (development|Deployment) Generally, the more automated (scripted) the deployment is, the safer. This is actually not because of the automation, but because of an effect of automation. With automated deployment in place, deployment usually becomes a more frequent process, which tends to exercise, expose, and remove sources of risk to a larger extent.

code freezes don' t prevent outages

4 - Continuous

5 - Pushing the code

5.1 - Before

Before being pushed, code is subject to peer review, internal use, and extensive automated testing.

The feature development is done on one branch that must be ahead of master

5.2 - During

The developer is responsible for pushing the code and monitoring the system with the help of a global monitoring dashboard.

5.3 - After

After the code push, engineers must monitor the site’s behavior and identify any sign of trouble.

6 - Flow

Don't deploy a branch :

  • until continuous integration tests have run.
  • if CI completed but the branch failed some tests
  • if the branch is behind master (automatically merge with master if required).
  • if the chat rooms is not the good one

After deployment:

  • a lock is set on every other deployment in order to test the branch
  • the lock is suppressed when the branch is merged with master (ie the test was successful)

Is Tagging before releasing a good one ?

6.1 - Code

git clone –depth 1 grabs the current file state and no history — just what we need for a build. See Git - Clone

6.2 - Database

if new code is needed to handle the database migrations, it must be deployed first.

7 - Cache

If we have a cache, we let the old one fall out naturally with time.

8 - Report

Deployments can show up in the timeline of corresponding pull requests through the GitHub API.

Cycle Time is the total elapsed time to move a change from the beginning to the production.

9 - Tools

* Heaven is a rails app that receives Deployment events from GitHub and deploys your code.

10 - Documentation / Reference

code/shipping/shipping.txt · Last modified: 2017/10/15 13:54 by gerardnico