Continuous Integration and Delivery: from Zero
to Hero with TeamCity, Docker and Kubernetes

Dev Marche

Outline
Agenda
1. Who we are
2. Introduction
3. Level Zero: Everything Manual
4. Level Intermediate: introducing a CI Tool
5. Level Hero: Docker + Kubernetes

L’azienda
Dati Generali Azienda
• Sede centrale a Basilea, Svizzera
• Development center ad Ancona
• Circa 20 professionisti motivati (Int&Est)
• Oracle Partner per Agile PLM

Il Team
Lean IT: Team
✓ Team 20 Persone (Int & Est)
✓ > 75 % Assunti a tempo Indeterminato
✓ > 90 % Laureati in Informatica o Ingegneria Informatica
✓ > 80% Laureati Specialistici
✓ Turnover delle risorse < 7% ultimi 3 anni
✓ >70% del Team ha tra 5 - 10 Anni o oltre i 10 Anni di
esperienza di Sviluppo Software
✓ Di questi il 60% ha più di 10 anni di esperienza di
Sviluppo Software
<2 Anni
2<>5 Anni
5<>10 Anni
>10
Team: Anni Esperienza
Sviluppo Software
<2 Anni 2<>5 Anni 5<>10 Anni >10

I Nostri Servizi
Lean IT: I Nostri Servizi
• IT Consulting
• System integration
• Sviluppo Software
• PLM Consulting
• Implementazione e Configurazione
• System integration
• Helpdesk e supporto
• Sviluppo moduli Custom
• Consulenza per i processi di Business

PLM
Application For Product Lifecycle Management

Tecnologie

Metodologie
Metodologie Waterfall vs Agile

Metodologie
Scrum Framework
✓ Lean IT:
✓ Sprint Weeks: 2
✓ Every 2 Weeks:
Grooming (normally) on
Friday
✓ Every 2 Weeks: Planning
(normally) on Monday
✓ Retrospective: Once
Months

La Nostra Sede

Opportunità
✓ Talenti
Mandateci un CV a:
recruiting@leanitconsulting.it
Esempio al desk all’ingresso
✓ Partner Commerciali / Strategici
Contattatemi a:
grizzo@leanitconsulting.it

Grazie
ITALY
Lean IT Consulting IT
Giulio Rizzo
grizzo@leanitconsulting.it
Via I Maggio 25/b – 60131 Ancona
+39 071 9256426
+39 328 8141675
BUON TECH BAR ☺

Disclaimer
We are NOT
• DevOps/CI/CD GURUs
• Affiliated with any of the brands we cite
Feel free to interrupt us in case you feel
we are saying something really wrong
Today we present our journey in the CI/CD
world

Introduction
Setting the Stage
• We have a quite long journey to share
• We outlined a path to guide us through
• Questions are welcome but please do not focus
too much in low-level details...
• … we don't want to leave at dawn!
• Help us to adjust our presentation: how much
of a DevOps expert are you?

Continuous Integration
Continuous Integration is a software
development practice where members of a
team integrate their work frequently ...
leading to multiple integrations per day.
Each integration is verified by an automated
build (including test) to detect integration
errors as quickly as possible.
Introduction
Martin Fowler
https://martinfowler.com/articles/continuousIntegration.html

Continuous Delivery
Continuous Delivery is the ability to get
changes of all types ... into production ...
safely and quickly in a sustainable way.
We achieve all this by ensuring our code
is always in a deployable state … completely
eliminate the integration, testing phases that
traditionally followed “dev complete”, as well as
code freezes.
Introduction
Jez Humble
https://continuousdelivery.com/

Introduction
Demo Scenario
receiversender
orders_queue

Talk is cheap
Show me the code

Level Zero
How we Deliver Our Application in PROD?
How would you do it?

Level Zero
Everything manual!
• Testing
• Building and packaging
• Deployment
We all started from here
With a bit of attention it works…
• … until the number of
projects is really small

Level Zero
Manual Build
$ mvn clean package -U
sender.war receiver.war
JAR
WAR WAR
demo-utility-lib.jar

Level Zero
Manual Deploy
RDP
SERVER
sender.war receiver.warDeveloper
WAR WAR

Level Zero
Deployment Pipeline
sender.war (v4)
receiver.war (v4)
sender.war (v3)
receiver.war (v3)
sender.war (v2)
receiver.war (v2)
sender.war (v1)
receiver.war (v1)
LOCAL
DEV
TEST
PROD
sender.war (v2)
receiver.war (v2)
sender.war (v3)
receiver.war (v3)
sender.war (v4)
receiver.war (v4)
• Manual deploy of artifacts thought the
pipeline
• Internal rules to ensure that each
environment receives the artifact of the
previous one
• Conventions on where to store artifacts

Level Zero
Application Demo

Zero Level: Considerations
Boring … repetitive … dummy ... work
• No added value after the first time you do it!
• What if you have DEV/TEST/STAGING/PROD
envs?
Highly subject to human error
No versioning of deploy history
• What I deployed in DEV? What in TEST?
• How to ensure that what has been tested in TEST
goes in PROD?
Level Zero

Level Intermediate

Introducing a Continuous
Integration Tool
There are as many CI tools as the stars: Jenkins, TeamCity, Travis CI,
Go CD, Bamboo, GitLab CI, CircleCI, Codeship...
We are currently – and happily – using Teamcity
Objective: automatize the development pipeline
Intermediate

TeamCity
• Developed by JetBrains
• Full support for Java and .NET
• Professional license free with some limitation
• 100 builds max
• 3 build agents
Intermediate

Intermediate
Continuous Integration with TeamCity

Intermediate
TeamCity Concepts
Project
Sub-project
Build
Build

Intermediate
TeamCity Build Dependencies

Intermediate
Deployment Pipeline with TeamCity
sender.war (v4)
receiver.war (v4)
sender.war (v3)
receiver.war (v3)
sender.war (v2)
receiver.war (v2)
sender.war (v1)
receiver.war (v1)
LOCAL
DEV
TEST
PROD
sender.war (v2)
receiver.war (v2)
sender.war (v3)
receiver.war (v3)
sender.war (v4)
receiver.war (v4)
• TC deploys artifacts thought the pipeline
• TC build dependencies to implement the
pipeline you need
• TC will store artifacts for you

Intermediate
Intermediate Level:
Pro and Cons
• Good level of automation
• Faster coding and quick feedbacks
on breaking changes
• Config of app environments is manual
• Installation on a new server is manual
• No isolation of micro-services

Next Level: Hero
• Docker – Container Platform
• Kubernetes – Orchestrator
• Google Cloud Platform – Cloud Provider

Level Hero
What is Docker?
Container
• Share the same kernel, isolation is done
in user space
• Lower resource usage
• Fast start time
Virtual Machine
• Each VM runs a full copy of the
operating system
• High resource usage
• Slow start time

Hero
What is Docker?
• Containers are built from layers
• Images can be pushed and
pulled to/from a shared repository
(public or private)
• A standardized unit of software

Hero
Why Docker?
• High isolation level (better security)
• Reduce friction between developers and operations
• Runs everywhere and reduce the risk of "works on my PC"
• Fast to stop and start
• Containers are easy to scale, deploy and upgrade
• Leader in container industry

Hero
Dockerfile
$ docker build –t leanitrepo/ci-demo-receiver:latest .
FROM openjdk:8-jdk-alpine
COPY ./target/ci-demo-receiver.jar
/usr/src/ci-demo-receiver.jar
WORKDIR /usr/src/
EXPOSE 8091
CMD ["java", "-jar", "ci-demo-receiver.jar"]

Can be easily integrated in Teamcity
Commands can be added
as build steps
Hero

Containers grows
rapidly
How can we manage an infrastructure
that scales?
Hero

Kubernetes
• An open source container orchestrator
• Based on Borg, a project run by Google
Hero

Kubernetes
• Automates deployment and scaling
• Manage failures
• Binpacking based on resource requirements
• Run on-premise or on the cloud
Hero

Kubernetes Concepts
Nodes
• A physical or virtual machine
• Manage workloads of containers
• Master: coordinates the activity of
the cluster
Hero

Kubernetes Concepts
Management
• Master node exposes an API
• kubectl: command line tool
• Many dashboards are available
• Can be easily integrated in Team City
Hero
kubectl

Hero
Scenario
receiversender
orders_queue

Hero
Scenario
orders_queuesender
receiver

Hero
Scenario

Hero
Google Cloud Platform
• Easy to setup and manage
• Resources can be allocated dinamically
• Can be managed with CLI for task automation
$ gcloud container clusters resize kube-demo --size=3

Hero
Google Cloud Console

Hero
Google Cloud Console

Hero
Deploy to Kubernetes with Team City

Hero
Scaling Pods
$ kubectl scale deployment receiver-deployment --replicas=5

Hero
Deploy Updated Version
$ kubectl set image deployment/receiver-deployment receiver=leanitrepo/ci-demo-receiver:100msec

Hero
Downscaling Pods
$ kubectl scale deployment receiver-deployment --replicas=3
docker@docker:~/dev-marche-demo$ kubectl describe deployment receiver-deployment
Name: receiver-deployment
Namespace: default
CreationTimestamp: Fri, 16 Nov 2018 09:59:32 +0100
Labels: app=dev-marche-demo
component=receiver
Annotations: deployment.kubernetes.io/revision=2
Selector: component=receiver
Replicas: 5 desired | 5 updated | 5 total | 5 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge

Hero
Monitoring logs with kubectl or Stackdriver
docker@docker:~/dev-marche-demo$ kubectl logs receiver-deployment-784c5df8cf-l675g --tail=10
2018-11-16 11:35:33,662 [http-nio-8091-exec-7] INFO com.leanit.ci.demo.cidemoreceiver.controllers.StatusController - /status/check endpoint
called
2018-11-16 11:35:34,561 [pool-2-thread-3] INFO com.leanit.ci.demo.cidemoreceiver.config.OrdersReceiver - Consumed Order d80fc7a2-2871-4166-
a59e-b82fbdc280e6 created at 2018-11-16T11:35:24.263Z[GMT]
2018-11-16 11:35:35,563 [pool-2-thread-4] INFO com.leanit.ci.demo.cidemoreceiver.config.OrdersReceiver - Consumed Order e4866ef8-85ff-4e72-
9866-d2ed6cedfb24 created at 2018-11-16T11:35:25.021Z[GMT]
2018-11-16 11:35:36,566 [pool-2-thread-3] INFO com.leanit.ci.demo.cidemoreceiver.config.OrdersReceiver - Consumed Order 9ed744f2-3034-45e6-
a5e5-01805d2ec3c5 created at 2018-11-16T11:35:25.869Z[GMT]
2018-11-16 11:35:37,568 [pool-2-thread-4] INFO com.leanit.ci.demo.cidemoreceiver.config.OrdersReceiver - Consumed Order 1a0d599f-e243-43c9-
9a4e-8e33db2d386c created at 2018-11-16T11:35:26.505Z[GMT]

References
• https://bitbucket.org/account/user/leanitdevs/projects/ZTH
• www.jetbrains.com/teamcity
• https://www.docker.com/
• https://kubernetes.io/
• Continuous Delivery - Jez Humble and David Farley
• Continuous Integration – Paul Duval, Stephen M. Matyas and Andrew Glover

Questions
1. Hero Level

Kubernetes Concepts
Pods
• A set of containers
• Has a unique cluster IP address
• Volumes can be attached
• Can be scaled
Hero

Kubernetes Concepts
Deployments
• Describe how pods can be scaled
• Different strategies can be
configured: Recreate, RollingUpd
ate, Canary
Hero

Kubernetes Concepts
Services
• Exposes a tcp port inside or
outside the cluster
• Balances the load of multiple
pods
• Matches multiple pods with label
selectors
Hero

Kubernetes Concepts
Scaling
Hero