Config flags ● Toggles features on and off ● Allows a team to continuously integrate ● Can be used for Canary testing ● Provides a rollback in case of flawed functionality
Think about the following ● Versioning your application ● Versioning your environment ● Version numbering ● Which tools to use ● How to react on a build failure
Versioning ● Master/trunk should always be deployable ● Any change in master / trunk should result in a release candidate ● Release branches, develop mainlines and other constructs do not play a role with Continuous Deployment – There are exceptions
Goal ● Determine how to start automating your build and deployment process ● Review your deployment strategy ● Automate your deployment process using phing
Deployment strategy ● Have a symlink representing your current release ● Upload your new release to a separate folder ● Integrate configuration in the new folder ● Create symlink of the new release ● Move the symlink of the new release over the current using `mv -Tf`
Goal ● Update jenkins and add phing plugin ● Setup a job in Jenkins ● Add deployment as a post-build action ● Execute our first automated build and deployment
Goal ● Add a new staging environment to puppet ● Change our deployment action to deploy to staging instead of production – using the changes of last exercise
Adding a new Deploy job ● Add a new job `blog-deploy` ● Configure `blog` job to archive the build ● Configure `blog-deploy` job to use the archived build
Goal ● Create a Behat test ● Alter our build file and add a UAT stage ● Add a new UAT job ● Persist workspace between jobs ● Automatically trigger UAT job after `blog` job ● Move deployment to staging from `blog` to UAT job ● Test our new process
mvriel
line_developers
no24oka
mixi_engineers
red_frasco
kohbis
okuzawats
twingob
lamrongol
yuya4
interu
whywaita
mclloyd
dougneiner
akosma
zakiwarfel
brettharned
carmenintech
reverentgeek
geeforr
jponch
lemiorhan
colly
sachag