Using CI for continuous delivery Part 1

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

www.vishalbiyani.com/ci-continuous-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

Deploy application

Build, unit test, create package

Restart Tomcat

Invoke test script

Wait on response from script

Indicate success/failure


Go - ThoughtWorks

http://www.thoughtworks.com/products/go-continuous-

delivery



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

Notice: What we are doing now is in

“Admin”- creation part. Pipelines tab is for running what we build

here


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


Technology

Using CI for continuous delivery Part 1