Title

name: center
layout: true
class: center, middle, title
---
name: title
layout: center
background-image: url(images/ground.jpg)
# Building Your Continous Delivery Pipeline from the Ground Up

.footnote3[Nick Humrich]
.footnote2[Canopy - Dev Tooling and Infrastructure]
.footnote[OpenWest - 06/07/2018]

???
welcome
---
template: inverse-center

# What is Continous Delivery?

???
First and foremost, it means delivering every single commit to production
---
layout: false
class: normal

# Why?

--
* Getting code to customers early and often

--
* smaller commits

--
* smaller impact of changes

--
* testing is easier

--
* Response time of fixing things is improved  (security?)

--
* bugs are less scary

---
template: center
# "If it's painful, do it more often."

???
- we DONT deploy often, because its painful/scary

---
background-image: url(images/pipeline.png)

# What is a Pipeline?

???

A pipeline is a process put in place to commits to ensure quality is high whilst maintaining velocity

A pipeline is a lock step process, which improves over time.

Like a data pipeline, but for code

As we get further away in the pipeline, the time of feedback decreases.

We want to put the simplist "catches" as close to the dev as possible, quick feedback cycles

---
.left-column[

## Validate
]

.right-column[

## - Lint

## - Static Analysis

## - Unit tests?

## - etc.

]

---

.left-column[
  ## Validate
  ## Build
]

.right-column[
  ## - Download Dependencies
  ## - Compile/Build
  ## - Save Binary/Artifact
]

---
# Artifacts

## - Binary

## - Zip/Tar

## - Docker

---

.left-column[
  ## Validate
  ## Build
  ## Test
]
.right-column[
  ## - Unit Tests?

## - Integration tests against artifact

## - Smoke Tests
]
---
.left-column[
  ## Validate
  ## Build
  ## Test
  ## Deploy
]

.right-column[
  ## - Deploy Artifact

## - Near Zero Downtime

## - Automated/Scripted

## - Same on every environment
]

---
# Environments

## - Environmnents allow code to get "Closer to production" over time
## - Typically about 3 environments
## - There should be a purpose for each environment
## - Clear criteria for each environment

---
background-image: url(images/pipeline.png)
---
.left-column[
  ## Tools that support Pipelines
]
.right-column[
  ## - Gitlab
  ## - Jenkins
  ## - Wercker
  ## - GoCD
  ## - Buddy
  ## - Shippable
  ## - BitBucket
]
---
background-image: url(images/tm-pipe.png)
---
template: center
# Examples
---
.gitlab-ci.yaml
```yaml
image: docker:dind

stages:
  - build
  - test
  - deploy-dev
  - deploy-preprod
  - deploy-prod

build:
  stage: build
  before_script:
    - docker login -u $DOCKER_USERNAME -p $DOCKER_PASSWORD
  script:
    - docker build --pull -t $CONTAINER_IMAGE .
    - docker push $REPO_NAME:$CI_COMMIT_SHA
```
---

```yaml
test:
  services:
    - postgres:9.6
  image: $REPO_NAME:$CI_COMMIT_SHA
  stage: test
  script: 
    - python3 -m coverage run pytest

```

---
```yaml
.deploy: &deploy
  image: nhumrich/deployment
  script:
    - sed -i -e "s/{{image}}/$CI_COMMIT_SHA/g" kube-deployment.yaml
    - kubectl apply -f kube-deployment.yaml

deploy-dev:
  <<: *deploy
  environment:
    name: dev
    url: https://dev.example.com

deploy-preprod
  <<: *deploy
  environment:
    name: dev
    url: https://preprod.example.com
```

???
You might want to make this its own script

---
# Other peices to add

## - Testing on environments automatically

## - Canaries

## - Performance testing
---
layout: true
template: center
---
# Tips/Extras

---

# Rollbacks
???
Part of failing fast, is being able to roll back
---
# No manual steps
???
- manual steps lead to delayed/larger deploys. 
- Pipelines can take longer, if they are fully automated
- Leads to higher quality over time
- getting rid of manual can feel scary, but leads to better code reviews and quality over time
---
# Master (Trunk) Based Development
???
- why MBD (or trunk-based) is required for CD
- How this effects environments 
- why not feature branches
---
# Feature Toggles 
???
- separating releases from deploys 
- allows deployment schedule to be decoupled from business release schedule 
- smaller commits 
- usually required wen doing MBD 
- See devons talk (The Foundation of Rapid Release Cycles) 300A, 3:00
---
template: section
# Thanks

.pull-right[
\#openwest

@nhumrich

joind.in/talk/3a48e
]