Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CentOS in a deployment pipeline - Continuous Delivery at itv

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. Continuous delivery
    Continuous delivery

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/
    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

    View Slide

  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

    View Slide

  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” ?

    View Slide

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

    View Slide

  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 )

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  17. Questions
    Questions

    View Slide