CONTINUOUS INTEGRATION
&
CONTINUOUS DELIVERY

Quick Poll

Are you using version control?

Quick Poll

Can you release new version of your software in one day?

Quick Poll

Can you release new, well-tested version of your software in one day?

Version Control System

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

Software Used

Following are the software generally used for version control:

• Git
• CVS
• SVN

Development

• Every developer has feature branches (If using any VCS otherwise you're dead)
• Integration issues
• Merge conflicts
• Workflow for merge code into various branches

Problem?

• Bringing software to production is hard
• Takes lot of time
• Human Errors​

Continuous Integration

Continuous Integration

“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.”

- Martin Fowler

Benefits of CI

• Code is always in the consistent state
• Code always compiles
• Enable automatic testing
  • Code should always build and test
• Automatic feedback on production readiness
• If you're going to fail, then fail early

Workflow change!

• Checkout / update
• Code
• Build and test locally
• Merge
• Commit
• Continuous Integration server takes over..

Testing

• Automate everything
  • If it hurts, do it more often. Continuously.
  • Fail fast.
• Integration testing
• Unit testing
• Functional testing
• Application testing

• Whatever you don’t test against, will happen

Requirements

• Source code repository
• Test cases
• Continuous Integration Server 

CI Servers

• Jenkins
  • Upstream Hudson fork
  • Java
  • Plug-able modules
• GitLab
  • Written in Ruby
  • Yaml based
  • Version control on CI configuration
• CircleCI
• Travis CI

 CI Workflow

Image source:  rigor.com

Continuous Delivery

“The essence of my philosophy to software delivery is to build software so that it is always in a state where it could be put into production. We call this Continuous Delivery because we are continuously running a deployment pipeline that tests if this software is in a state to be delivered.”

– Jez Humble, Thoughtworks

• CD = CI + fully automated test suite
  • Not every change is a release
  • Manual trigger
  • Tag releases!
• CD – It is all about testing!

Cont. Delivery vs. Deployment

Unit Test

Integration

test

Validation

test

Deploy to Production

Manual

Unit Test

Integration

test

Validation

test

Deploy to Production

Auto

Cont. Delivery

Cont. Deployment

Demo?

Tools and software used

• GitLab
• GitLab Runners
• Docker
• NodeJS

Cont. Integration & Deployment

Workflow from build to production release

Test

Build

Deploy

Test

// Simple async test for HTTP 200 response code using supertest
'use strict';

var request = require("supertest"),
    app = require("../app").getApp;

describe('GET /', function(){
  it('expects HTTP response 200', function(done){
    request(app)
     .get('/')
         .expect(200, done);
  });
});

Dockerfile

FROM centos:centos6.9

MAINTAINER Savitoj Singh <savitojs@gmail.com>

RUN rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

RUN yum install -y npm

COPY . /src

RUN cd /src; npm install

EXPOSE 8080

CMD cd /src && node ./app.js

.gitlab-ci.yml

cache:
  paths:
  - node_modules/

stages:
- test
- build
- deploy

test_application:
  image: node:4.2.2
  stage: test
  tags:
   - docker
  script:
   - npm install
   - npm test

build_app:
  stage: build
  tags:
   - sh
  script:
    - echo "Building application..."
    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN gitlab-stage.cee.redhat.com:4567
    - docker build -t gitlab-stage.cee.redhat.com:4567/savsingh/nodejs .
    - docker push gitlab-stage.cee.redhat.com:4567/savsingh/nodejs

staging:
  stage: deploy
  tags:
   - sh
  script:
   - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN gitlab-stage.cee.redhat.com:4567
   - docker pull gitlab-stage.cee.redhat.com:4567/savsingh/nodejs
   - docker stop nodejs-stage || true && docker rm nodejs-stage || true
   - docker run --name=nodejs-stage -p 8081:8080 -itd gitlab-stage.cee.redhat.com:4567/savsingh/nodejs:latest
  except:
   - master
  environment:
    name: staging
    url: http://10.65.8.23:8081

production:
  stage: deploy
  tags:
   - sh
  script:
   - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN gitlab-stage.cee.redhat.com:4567
   - docker pull gitlab-stage.cee.redhat.com:4567/savsingh/nodejs
   - docker stop nodejs || true && docker rm nodejs || true
   - docker run --name=nodejs -p 8080:8080 -itd gitlab-stage.cee.redhat.com:4567/savsingh/nodejs:latest
  only:
   - master
  environment:
    name: production
    url: http://10.65.8.23:8080