Continuous delivery Continuous delivery

Continuous delivery Continuous delivery ITV plc Presented by: Stefan Cocora Linux system engineer @dr_kovac

Background about itv Background about itv - rpm powered shop - RHEL 5 for historic and political reasons - moving swiftly to CentOS 6

Agenda Agenda Continuous delivery best practices: - background on continuous delivery - infrastructure as code - use a local development environment - all your source code goes in a SCM - build your binaries just once - use the same deployment methods everywhere

Continuous delivery Continuous delivery Definition and best practices: - it helps you to reduce feedback loop time - it helps keep the developed application in a working state - it helps reduce risk by delivering small, incremental changes rather than “all features at once” Best practices: - keep all software ( infra + dev ) in SCM - only build your binaries once - deploy the same way to any every $ENV - smoke test your deployments - deploy into a copy of production - if any part of pipeline fails, stop the line

Infrastructure as code Infrastructure as code Puppet: - it is as important to have configuration management for your infrastructure ( servers ) as it is to have a continuous delivery pipeline for your application What: - way of describing infrastructure as code Advantages of configuration management: - consistent and reproducible environments - consistent flow of change - traceability and accountability http://docs.puppetlabs.com/#puppetpuppet

Local environment Local environment Vagrant: Helps you get rid of “works on my laptop” syndrome What: - wrapper around virtualisation technologies - integration with configuration management tools: puppet, chef … Advantages: - consistent local environments – basically managed development workspace - shared language between ops and dev - completely destroyable environments http://www.vagrantup.com/

Use an SCM Use an SCM Git and Github: What: - ask a developer next to you :) Why use an SCM: - historic view of any file in the repository - gives a team the ability to easily work on the same codebase without sending zip files via email - provides accountability - helps you keep both dev & infra ( puppet is a codebase ) code in an SCM http://git-scm.com/

Push your binaries to artifactory Push your binaries to artifactory What is artifactory: - open source binary repository - proxy between your build tool ( maven … ) and the outside world Why use artifactory: - could be useful if you're have java/ application - not very useful if your application is ruby/php/python - development team responsible to push binaries to artifactory after they've passed unit tests http://www.jfrog.com/home/v_artifactory_opensource_overview

Build your binaries once Build your binaries once “Only Build Your Binaries Once” Advantages: - the binaries that will be deployed in production have to be the same ones that passed the acceptance test process - make sure you can use the same binary in every environment – brings the possibility of separating code from configuration management

Build your binaries once Build your binaries once “Only Build Your Binaries Once” - build your binaries once and package them - once the rpm has been built treat is as an artefact, test the app that it contains and either promote or stop it when it fails - no additional tools needed after the rpm has been built, just promote it to the “next” yum repository - since you're installing your “app” on an OS why not use the benefits of the OS' package database - What version of “app” is running at this time ? - Has file “x” been deployed in $ENV ? - How easy can I roll back to “app-1.0” from “app-1.1” ?

Build your binaries just once Build your binaries just once “Only Build Your Binaries Once” Tools and approaches: - jenkins - mock

Run acceptance tests to validate rpm Run acceptance tests to validate rpm Why: - automated way to validate your application - tests are developer responsibility - you need collaboration between the dev and ops team ( most times devs don't understand systems )

Use the same deployment methods everywhere Use the same deployment methods everywhere - historically I've used “push configuration” tools to deploy: rake, capistrano - these tools have some disadvantages

Use the same deployment methods everywhere Use the same deployment methods everywhere Tools: - capistrano ( push config ) for sending commands - mcollective to actually run those commands across $ENV http://docs.puppetlabs.com/#mcollectivemcollective https://github.com/capistrano/capistrano/wiki

Other CD practices Other CD practices - valid for $PROD for the moment ...

Questions Questions