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