presentations/cicd/cicd.md

CI/CD @ TrackCode

Using Jenkins, Helm & Kubernetes

---

Content

• About me
• Definition of CI/CD
• Existing Stack
• Implementation
• Pros & Cons
• Whats next?

---

About me

Julian Tölle
Developer @ narando & TrackCode
Backend Development & DevOps

--

About us

• ~ 5 Employees
• Last-mile scanning solution for logistics
• Nodejs + React

---

Definition of CI/CD

Continuous Integration

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day.

Each check-in is then verified by an automated build, allowing teams to detect problems early.

From ThoughWorks

--

Definition of CI/CD

Continuous Delivery

Continuous Delivery (CD) is a software development discipline where you build software in such a way that the software can be released to production at any time.

From Martin Fowler

--

Definition of CI/CD

Summary

• Merge often
• Test everything
• Deploy quickly

---

Existing Stack

• Bitbucket Server
• Jenkins
• Dedicated machines for each service

--

Existing Stack

Jenkins

• Seperate jobs per service instance and environment
• Polling for SCM changes
• Freestyle jobs executing shell:

rsync -avz . jenkins@SERVICE-MACHINE:/var/www/
ssh jenkins@SERVICE-MACHINE "./deploy.sh production"

--

Existing Stacks

Pain Points

• Configuration only in Jenkins
• No hermetic builds
• Deploying means capacity reduction
• Only application, no infrastructure

---

Implementation

Premise

Deployment Target	Kubernetes
Build Tool	Jenkins

--

Implementation

Workflow

1. Make changes and commit
2. Create PR from feature branch to master
3. Automatic tests and linting provide inline feedback
4. Code Review from peers
5. Act upon test and review feedback
6. Merge
7. Deployment is triggered

---

Implementation / Build

• Triggered by Webhook
• On every push/pr
• Steps defined in Jenkinsfile
• Build defined in Dockerfile

--

Implementation / Build

Jenkinsfile Build Steps

--

Implementation / Build

Jenkins Blue Ocean UI

---

Implementation / Deployment

• Defined in same Jenkinsfile
• Executed when branch IN (master, dev)

--

Implementation / Deployment

Helm

• Incubating CNCF Project
• "Package Manager for Clusters"
• CLI Tool (helm) and in-cluster Operator (tiller)
• Only used for templating
• Alternatives: ksonnet, kubetpl, ...

--

Implementation / Deployment

Helm Workflow

• Render Helm Chart to Kubernetes Manifest
• Apply Manifest against cluster

--

Implementation / Deployment

Folder Structure

app-web
└── ops
    ├── chart
    │   ├── Chart.yaml
    │   ├── templates
    │   │   ├── configmap.yaml
    │   │   ├── deployment.yaml
    │   │   ├── _helpers.tpl
    │   │   ├── ingress.yaml
    │   │   └── service.yaml
    │   └── values.yaml
    └── nginx
        └── default.conf

--

Implementation / Deployment

Jenkinsfile Deploy Steps

---

Pros & Cons

Pros

• Explicit, reviewed, tracked configuration
• Infrastructure also deployed
• Clean builds
• Every commit/pr is build

--

Pros & Cons

Cons

• Dependency on local tools
  • kubectl, helm, docker, npm, node
• Leftover build artifacts
• Groovy is unnecessarily verbose
• Missing clean up of orphaned k8s resources

---

Whats next?

• Container native build tools
  • e.g. Drone.io, Jenkins X, Concourse
  • explicit tool dependencies
  • built-in docker garbage collection
• Helm v3
  • deprecation of tiller in favor of CRDs
  • still allowing clean up of orphaned resources