Continuous {Integration,
Delivery, Deployment}
Release Engineering for Machine Learning Applications (REMLA, CS4295)
Sebastian Proksch
[email protected]
Luís Cruz
[email protected]
1
Copyright MariCarmennd9, “Infinity Light Camera”, Pixabay, Free License
Goal of today...
•Differentiate the various continuous X buzzwords
•Understand the setup and the goals of a basic delivery
pipeline
•Use semantic versioning in your projects
•Get to know basic release/versioning strategies
•Get a first glimpse in the capabilities of GitHub that go
beyond a simple build server
2
Continuous <Enter Buzzword here>
3
A Basic Delivery Pipeline
Source Code Developer Version Control Config
Environment gets
User Acceptance Tests
Tester
Setup Environment more “production-
Deploy
Manual Testing like” from left to right.
Commit Level Automated
Performance/Capacity Tests
Compile Acceptance Testing
Configure Environment
Unit tests Setup Environment
Deploy
Assembly Deploy
Performance Tests
Static Analysis Integration Testing
Binaries
Production Modern Processes
Configure Environment
Operator Deploy merge roles (“DevOps”)
Binaries Binaries
Artifact Repository
4
Inspired by “Continuous Delivery”, Humble & Farley, Addison Wesley
Configuration Management
•Configuration as Code
(Component Interaction)
•Infrastructure as Code
(Environment Setup)
We will cover this topic, when we talk about Kubernetes.
5
Deployment Workflow
Version Build & Unit Acceptance
Developer Release
Control Tests Tests
Automation is key
P
for timely feedback!
F
6
Continuous ...
Continuous Continuous Continuous Continuous
Integration Delivery Deployment Experimentation
7
What do the different buzzwords mean?
Continuous Continuous Continuous Continuous
Integration Delivery Deployment Experimentation
• Task: Discuss tasks and the goal of these different phases
• Group Size: Pair with your neighbor
• Time: 5min
• Outcome: define goal of each phase in one sentence
• We will collect answers afterwards
8
Continuous Integration
•Integrate changes
• Trunk-based development
(Fowler’s definition)
• Pipeline-centric development Automated Build
(everybody else’s def.) Dfsg f dgdf
asd aa sdd
sdsd sd dsd
•Quality assurance
Dfsg f dgdf sdsdsd sdd Dfsg f dgdf
asd aa sdd s dsl fjhfj ss asd aa sdd
sdsd sd dsd Dfsg f dgdf
fhdj fjd dsfg sdsd sd dsd
sdsdsd sdd asd aa sdd sdsdsd sdd
Dfsg f dgdf
s dsl fjhfj ss sdsd sd dsd s dsl fjhfj ss
asd aa sdd
fhdj fjd dsfg sdsdsd sdd fhdj fjd dsfg
sdsd sd dsd Dfsg
s dsl fjhfj ssf dgdf
sdsdsd sdd
fhdj fjd asd
dsfgaa sdd
s dsl fjhfj ss sdsd sd dsd
fhdj fjd dsfg sdsdsd sdd
•Maintainability
s dsl fjhfj ss
fhdj fjd dsfg
Build Logs
“use central code base and validate contributions”
9
Continuous Delivery
•Automate packaging
•Versioning
•Might require configuration
•Automated acceptance testing
•“One-click Deployments”
“make every change releasable”
10
Continuous Deployment
•All required tests are automated
• User Acceptance Tests
• Performance Tests
•Prepare/configure environment
•Infrastructure as code
“release every change”
11
Continuous Experimentation
??
•“Testing on live”
?
•Release to subsets of your users
•Monitor effect of changes
•Release decision based on monitoring results
“release every potential change”
12
Application Types
13
What does Continuous Delivery mean for...
•Webapps?
•Machine Learning Models?
•Downloaded Application?
•Mobile App/App Stores?
•Software library?
14
Think about your last project... What
are the challenges/ benefits/
requirements/... when you would want
to apply continuous delivery there?
15
Release Personas / Stereotypes
• Effects of application type
• Fat Client
• App (Device Fragmentation) Common goal: Automate
• Website (No installation) the necessary steps to
• Effects of execution mode get from code to release
• Standalone
• Isolated (Text Editor)
• Collaborative (Discord)
• Integrated (Plugins/Libraries) There is no “one size fits all”
• Gated Communities solution for CD. Learn from
(App Stores, Hosting) similar projects.
• ...
This list is by no means meant to be exhaustive and only serves as a starting point for a discussion. 16
Focus of this course
•Libraries
• Versioning
• Convenient Distribution via Package Registry
•(Web-) Services
• Containerization
• Orchestration
• Easy to update and experiment
•...? (maybe you have another idea for your project)
17
Versioning
18
Unique Versions
19
Ordered Versions
Credits: Wikipedia 20
https://semver.org/
Semantic Versioning
Given a version number MAJOR.MINOR.PATCH, increment...
• the MAJOR version when you make incompatible API changes,
• the MINOR version when you add functionality in a backwards
compatible manner, and
• the PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.
Unique & Ordered & “Meaningful”
21
Example Versions
•1 (non-semantic, unless interpreted as 1.0.0)
•1.2 (non-semantic, see above) Interpretation
•1.2.3 and order of
•2.43.0-beta these version
•0.1.3-SNAPSHOT (Maven specific?!) identifiers
depends on
•0.1.3-20220425-134715 the concrete
ecosystem.
22
Quick Quiz
Up to which level can you upgrade a dependency that
strictly follows semantic versioning without worrying
about breaking changes?
•Major (e.g., 1.2.3 à 2.0.0)
•Minor (e.g., 1.2.3 à 1.3.0)
•Patch (e.g. 1.2.3 à 1.2.4)
23
Managing Versions
24
Trunk-Based Development + Release Tags
(GitHub Model)
Branches Tags
develop
main v2.0
What about
bugfix releases?
v1.2
25
Release Branches
develop
main release-2.0 v2.0 v1.1.4 release-1.1
v1.1 v1.1.1
v1.0.7 release-1.0
v1.0 v1.0.1
Branch Tag 26
Time-based Versions
•Pre-releases (“Snaphots”)
•Scheduled Builds (e.g., “Nightlies”)
• CI/CD evangelists would say they are not necessary
• Used when releasing is expensive
• .. or environment changes frequently
(or at least more frequent than product)
•Usually used in addition to proper versioning scheme
27
Where to store the version information?
•In a file? pom.xml?
Again, no single solution
•As a repository tag?
•As a static field in a class?
is always superior...
•Does your software need to know its version?
•What happens should you forget to update?
•Who is bumping version numbers?
•Who gets to decide on major/minor/patch?
•Does the build server get write access to the repo?
28
Quick Quiz
True or false? New versions of a package should always
be released on the main branch of the repository!
•True
•False
29
Where to put the versioned program?
30
File Share
•Programs
•Websites
•Use simple transfer utilities, like ftp or scp
31
Artifact Repository
•A released artifact has a unique “coordinate”
(Maven: group ID, artifact ID, version)
•Central Repository to store and manage artifacts
• “Mavenized” Git Repository
• Package/Container Registry of Repository Providers
• Specialized Repository Software, like Artifactory
ß
• Maven Central
•Gives clients a unified access to well-defined deps
32
Application Server / Cluster
•Deployment/Configurations
•Often either a final, manual trigger...
•... or webhooks to trigger updates
•Automated update is key for continuous
experimentation
33
GitHub Actions
34
Workflows & Jobs
•Workflows are triggered by events (e.g., commit)
•Workflows contain Jobs that contain Steps
•Jobs and Steps are run sequentially
•A job runs all steps on a runner
35
https://docs.github.com/en/actions/using-workflows/about-workflows
Trigger
•Workflows can get triggered by GitHub events
• Commit
• New Issue
• API trigger
• ...
•Execution can be controlled though
•For example, use {branch, tag}-ignore
36
Actions
# /.github/workflows/my-name.yml
name: my-workflow-name
on: push
jobs:
Job my-job-name:
runs-on: ubuntu-20.04
steps: Github Action
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
Steps
with: Github Action
java-version: 11
distribution: 'temurin’ with Parameters
- run: mvn clean package
Script
37
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions
Artifacts
•Every job runs in a fresh container
•All changes in the working dir are isolated
• Changes only get preserved within a single job
• Changes are not shared between jobs
•Look into actions/cache@v3 to cache results
(e.g., downloaded dependencies)
•Look into actions/upload-artifact@v3 to save/restore
(e.g., coverage report)
38
Pipeline Execution
•Pipeline steps are executed on runners in containers
•Base image can be changed
(e.g., Java image for compilation, Docker image for
packaging, ...)
Hosted Your Organization
Shared
Shared Shared
Shared
Shared
Runner
Shared Shared
Runner
Shared
Runner
Shared GitLab Runner
Private
Runner
Runner Runner
Runner
Runner Runner
39
... and much more
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions
40
Conclusion
41
After today's lecture, you are able to...
•tell the difference between continuous integration,
delivery, deployment, and experimentation
•describe a basic delivery pipeline
•explain the concepts behind semantic versioning
•describe basic release/version strategies
•describe the basic elements of a GitHub workflow and
you know how to find more information
42
What was the
muddiest point
of todays lecture?
43
Next Lectures
Next:
• Recorded Lecture on Testing
Friday:
• Interactive lecture on Docker/Docker compose
• Please bring a computer and have Docker/Docker
compose installed https://docs.docker.com/compose/install/
• Please prepare the following article (3min)
https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/containers-vs-vm
44
