CentOS in a deployment pipeline - Continuous Delivery at itv

Deck presented at the September centos dojo, on 13th Sept 2013.
video from the centos dojo at http://wiki.centos.org/Events/Dojo/London2013

Transcript

1. Continuous delivery Continuous delivery
2. Continuous delivery Continuous delivery ITV plc Presented by: Stefan Cocora Linux system engineer @dr_kovac
3. Background about itv Background about itv - rpm powered shop - RHEL 5 for historic and political reasons - moving swiftly to CentOS 6
4. 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
5. 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
6. 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
7. 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/
8. 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/
9. 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/<insert_java_based_language> 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
10. 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
11. 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” ?
12. Build your binaries just once Build your binaries just once “Only Build Your Binaries Once” Tools and approaches: - jenkins - mock
13. 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 )
14. 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
15. 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
16. Other CD practices Other CD practices - valid for $PROD for the moment ...
17. Questions Questions