$30 off During Our Annual Pro Sale. View Details »

CentOS in a deployment pipeline - Continuous De...

stefanco
September 13, 2013

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

stefanco

September 13, 2013
Tweet

More Decks by stefanco

Other Decks in Technology

Transcript

  1. Background about itv Background about itv - rpm powered shop

    - RHEL 5 for historic and political reasons - moving swiftly to CentOS 6
  2. 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
  3. 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
  4. 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
  5. 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/
  6. 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/
  7. 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
  8. 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
  9. 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” ?
  10. Build your binaries just once Build your binaries just once

    “Only Build Your Binaries Once” Tools and approaches: - jenkins - mock
  11. 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 )
  12. 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
  13. 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