Using CI for continuous delivery Part 1

Using CI tools for
continuous delivery?
Can we use CI tools for Continuous Delivery?

www.vishalbiyani.com/cicontinuous-delivery

www.vishalbiyani.com

What will we do?
• Test drive each of
– Go (ThoughtWorks)
– TeamCity (Jetbrains)
– Bamboo (Atlassian)
– Jenkins (Open Source)


On what basis?
Parameter

Description

Support for CI+CD Semantics

Ability to club information from multiple
builds into a release manifest sorts

First-class Workflow support

Visual workflow - to build workflow
which is easy to see and modify over
time

Standard actions available

Standard actions available for various
CD tasks - like deploy to tomcat,
connect to server X etc.

Custom actions- extensibility

Ability to write custom actions/plugins
for doing ad-hoc jobs, because not all
actions provided in tool might fit your
needs.

Miscellaneous factors

Supports rolling deployments?
Agentless or with Agents?
Horizontally Scalable?
Auto roll back?
Database deployment integration?

Rough workflow we will test

A code commit
invokes a build

Start Tomcat if
not up

Invoke test script

Build, unit test,
create package

Deploy
application

Wait on response
from script

Restart Tomcat

Indicate
success/failure


Go - ThoughtWorks
http://www.thoughtworks.co
m/products/go-continuousdelivery


Notice: What we are
doing now is in
“Admin”- creation part.
Pipelines tab is for
running what we build
here

We create a
pipeline with three
“stages” and
configure it


You can integrate
with project
tracking tools like
Mingle or others!

Material for a build
pipeline will be
source code from
any of repositories


The “stages” in
plan and number
of “jobs” in each
stage


Environment
variables can be
configured at multiple
levels. “Secure” ones
only at pipeline level


Diving one level deeper
– A job can have
settings, tasks, artifacts
and env. Variables
defined


The tasks available look
like few, but with “Custom
Command” you can literally
integrate anything from a
shell script to external
program

Moreover the “command
repository” provides
additional commands so
you don’t have to start
from scratch! You can build
your private command
repo from existing scripts
too!
Check https://github.com/goteam/go-command-repo

Let’s add a
“maven” custom
command to build
our checked out
source code

Similarly we added
custom commands
for tasks in other
stages – to build a
pipeline


Other options
while creating
pipelines including
templates,
authentication and
repos etc.


The only plugin
which was
available in OOTB
installation

Configure “Agents”
which will execute
tasks


All our pipelines and
their stages visible in
pipelines tab.


For a given pipeline –
all past builds with
stage level results in a
single page.

You can see where
the material is
going and what is
being built ;)

Overall progress,
with rest of details
like materials, jobs
and comparison of
changes

A history of given
stage in previous
runs!


We loved the
visual workflow and
overall information
we got while
running pipeline


Successful builds
and trends over
time


Comparison of Build
12 and 13 for a
pipeline – stage wise
and changes
committed as part of
change


Go - Concluding thoughts
• Clean, minimal interface
• Pretty good at both CI-CD Semantics
• Looks basic OOTB but Highly
extensible and can be customized to
needs with command repo (Kind of
actions etc.)
• Very well done visual workflows and
information required for deploys

Using CI for continuous delivery Part 1

More Related Content

What's hot (20)

Similar to Using CI for continuous delivery Part 1 (20)

More from Vishal Biyani (14)

Recently uploaded (20)

Using CI for continuous delivery Part 1