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 full-size slide

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

    View full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size slide

  17. Questions
    Questions

    View full-size slide