Deployment talk dpc 13
Upcoming SlideShare
Loading in...5
×
 

Deployment talk dpc 13

on

  • 823 views

About determining your deployment strategy and creating a deployment script (with capistrano and capifony).

About determining your deployment strategy and creating a deployment script (with capistrano and capifony).

Statistics

Views

Total Views
823
Views on SlideShare
769
Embed Views
54

Actions

Likes
2
Downloads
12
Comments
1

5 Embeds 54

http://eventifier.co 43
http://www.eventifier.co 4
http://librosweb.es 3
http://eventifier.com 3
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Hey Robbert!
    Do you have vide/audio for that?
    Thanks
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • This talk is heavily opinionated. All tools mentioned could be replaced by alternatives, but I'll show you some tools and techniques which I consider best for the job. This is not a talk about continuous deployment, although most of the ideas and best practices shown are part of the concept.
  • FTP is a great protocol for transferring (large) files between computers, but what it's not so great for is deploying your 25000 files counting web project from your 2mb/s home network while your web visitors are waiting for it to finish.
  • Obviously, we would all prefer to never take our website down, not even when updating. But in practice most developers find it acceptable and even customers don't find it odd that their website is down for maintenance (when announced on beforehand of course). But, ideally, our customers and, more importantly, their customers should have no idea of what's going on on the server while buying new shoes in your awesome webshop. As discussed in the previous slides, most traditional deployment strategies require the developer to perform some additional manual operations after or before uploading the updated code. This often makes the developer want to work fast, because the website is down or even broken. This results in stress and often leads to mistakes made by the deployer. Some applications are very heavy and are heavily dependant on caching. After updating the code, the cache also needs to be renewed, which willl cause the first couple of page views to be slow. This might sound as a trivial problem, but in practice, when deploying multiple times a day, it will also result in multiple slow downs each day. Some deployment processes take forever to complete, which might not be a big thing when you're releasing every 3 months, but when your team wants to get new features out of the door quickly, your productivity rate will decrease dramatically when your team mates are waiting 40 minutes a day for 3 deployments to finish. There is soo much that could potentially go wrong when deploying. Database migrations gone wrong, permission errors, connection problems and so on. But, no matter what goes wrong, you should ALWAYS be able to go back and revert, so that you can investigate the problem, at your own pace, in your own time. Not when your website is throwing fatals at your visitors.
  • Wherever you can optimize, optimize! Higher release frequency means smaller deploys means less risk of exceptions Main point of presentation: optimize & automate!
  • Obviously, we would all prefer to never take our website down, not even when updating. But in practice most developers find it acceptable and even customers don't find it odd that their website is down for maintenance (when announced on beforehand of course). But, ideally, our customers and, more importantly, their customers should have no idea of what's going on on the server while buying new shoes in your awesome webshop. As discussed in the previous slides, most traditional deployment strategies require the developer to perform some additional manual operations after or before uploading the updated code. This often makes the developer want to work fast, because the website is down or even broken. This results in stress and often leads to mistakes made by the deployer. Some applications are very heavy and are heavily dependant on caching. After updating the code, the cache also needs to be renewed, which willl cause the first couple of page views to be slow. This might sound as a trivial problem, but in practice, when deploying multiple times a day, it will also result in multiple slow downs each day. Some deployment processes take forever to complete, which might not be a big thing when you're releasing every 3 months, but when your team wants to get new features out of the door quickly, your productivity rate will decrease dramatically when your team mates are waiting 40 minutes a day for 3 deployments to finish. There is soo much that could potentially go wrong when deploying. Database migrations gone wrong, permission errors, connection problems and so on. But, no matter what goes wrong, you should ALWAYS be able to go back and revert, so that you can investigate the problem, at your own pace, in your own time. Not when your website is throwing fatals at your visitors.
  • Deployment is an often forgotten topic when sitting around the drawing table. As before mentioned requirements will take time and therefore cost more money, you should mention and discuss this topic in the early stages of your project. It is essential for a successful deployment strategy.
  • Deployment is an often forgotten topic when sitting around the drawing table. As before mentioned requirements will take time and therefore cost more money, you should mention and discuss this topic in the early stages of your project. It is essential for a successful deployment strategy.
  • Also, you need to manage the expectations for everybody involved in the project. Since deployment is such a critical part of your development cycle, everyone should know how to act and what to expect when working on the project. Also, users should of course be informed about updates, maintenance windows and receive proper error messages when something goes wrong while deploying.
  • No matter how cool your versioning system is, and how good your migrations script can rollback, always make sure there is a backup of your stuff before you actually start breaking things.
  • No matter how cool your versioning system is, and how good your migrations script can rollback, always make sure there is a backup of your stuff before you actually start breaking things.
  • So now we're getting more and more close to having us a deployment script

Deployment talk dpc 13 Deployment talk dpc 13 Presentation Transcript

  • Deploying your apps.. the right way!Robbert van den BogerdJune 8th, 2013
  • Introduction
  • whoamiDeveloper at IbuildingsWeb enthusiastTravellerThe Average Joe
  • Disclaimer
  • DEPLOYMENTSo what are we here for?
  • TOCHorror storiesCommon pitfallsWhat we wantDeployment from beginning to endIntegration tools
  • Horror stories
  • Horror storiesFTP: Forever Taking Process
  • Horror storiesRsync: for oldschool sysadmins
  • Horror storiesVersioning checkout
  • Horror storiesTeamviewer: REALLY?
  • Problems & solutions
  • Common pitfallsManual operationsSloow deployment processDowntimeCacheMigrationsNo turning back
  • Manual operationsNo!The Bus FactorAnyplace, anywhere, anytimeConfidence
  • No turning back
  • Zero downtimeNo more UC pages!Quick deploysSmaller releasesAutomate
  • Cache
  • Migrations
  • Common pitfallsManual operationsSloow deployment processDowntimeCacheMigrationsNo turning back
  • What we wantManual operations AutomationSloow deployments Quick rolloutsZero DowntimeCache warmed upMigrationsNo turning back Rollbacks
  • From the beginning..
  • “Victorious warriors first winand then go to war”- Sun Tzu
  • Think before you (sign a contr)act!
  • Managing expectationsCustomerUsersProject managerDevs/testers
  • Deployment strategyRelease cycleServer setupBranching strategyTools to use
  • DTAP
  • So, lets cut to the point..
  • Use git
  • Seriously, use git!ReliableSuper fastEasy branching/mergingDistributedGithub:Awesome uiExtrasPRsIntegration with existing deployment tools
  • Dependency managementFrameworkLibrariesBuild/QA toolsCompany private repos
  • Drumroll please..
  • Composer
  • MigrationsWrite your own scriptUse one of the great existing ones:- Doctrine migrations- DbPatch- Shipped with your framework/orm?
  • BackupsAlways create one!..unless its not possible =]
  • Directory structure/var/www/rule34//var/www/rule34/releases/var/www/rule34/releases/20130606143000/var/www/rule34/releases/20130606143400Live www dir:/var/www/rule34/current > releases/20130606143400
  • Deployment script> Do a backup> Create new directory> Update your code> Update dependencies> Run migrations> Warmup cache> ...
  • Lets start scripting!
  • Wait a second..
  • Existing toolsFabricPhing/AntChefCapistrano
  • CapistranoPowerfulEasy setupEvent/task based, easy to hook intoWritten in rubyMultiple serversMultistage extension
  • CapifonyThe power of CapistranoPre-configured for SymfonyDeploy with 1 single config file
  • Setup
  • Local setupgem install capifonycd /var/www/rule34/capifony install .
  • Capifony config# app/config/deploy.rbset :application, "My App"set :deploy_to, "/var/www/my-app.com"set :domain, "my-app.com"set :scm, :gitset :repository, "ssh-gitrepo-domain.com:/path/to/repo.git"
  • Remote setupcd /var/www/rule34/cap deploy:setup
  • Deploy
  • Capifony deploycd /var/www/rule34/cap deploy# made a boo-boo?cap deploy:rollback
  • Configurationset :model_manager, "doctrine"
  • Configurationset :update_vendors, falseset :use_composer, trueset :vendors_mode, "install"
  • Configurationset :dump_assetic_assets, true
  • Configurationset :shared_children, [app_path+"/logs", "data"]set :writable_dirs, [app_path+"/logs", app_path+"/cache", "data"]
  • Directory structure/var/www/rule34/releases/shared/shared/data/shared/app/logsSymlink:/var/www/rule34/releases/20130606143400/data > ../../shared/data
  • DTAP
  • Multistaging# app/config/deploy.rbrequire capistrano/ext/multistageset :stages, %w(prod acc test dev)set :default_stage, "test"set :stage_dir, "app/config/deploy/stages"# app/config/deploy/stages/test.rbserver rule34.mytestserver.comset :symfony_env_prod, "test"
  • User permissionsset :use_sudo, falseset :user, "deployment"set :group, "www-data"set :webserver_user, "www-data":use_set_permissions, true:permission_method, “chmod” # or “acl” or “chown”
  • Maintenance pagecap deploy:web:disable REASON="hardware upgrade" UNTIL="12pm Central Time"# override templateset :maintenance_template_path, “app/Resources/uc.html”
  • Tips n Tricks# determine tag/branch/commit/sha1 on the flyset :branch dodefault_tag = `git describe --abbrev=0 --tags`.split("n").lasttag = Capistrano::CLI.ui.ask "Tag/branch to deploy (make sure topush the tag first): [#{default_tag}] "tag = default_tag if tag.empty?tagend
  • Tips n Tricks# enable ssh client interactiondefault_run_options[:pty] = true
  • Tips n Tricks# enable agent forwardingssh_options[:forward_agent] = true
  • Tips n Tricks# cleanup old release dirs automaticallyset :keep_releases, 3after "deploy", "deploy:cleanup"
  • Tips n Tricks# run doctrine migrations after code updateafter “update_code”, “doctrine:migrations:migrate”
  • Tips n Tricks# run any symfony console commandbefore “any_task”, “symfony:cache:clear”
  • Whats next?
  • System provisioningUpgrade PHP 5.3 > 5.4Upgrade MySqlInstall RedisInstall Node.jsEtc..
  • ChefVersion control your infrastructureIdentical environmentsIntegration with Vagrant
  • Chef# run chef after code updateafter “update_code”, “provision”task :provision doend
  • Chef# run chef after code updateafter “update_code”, “provision”task :provision dorun "#{sudo} chef-solo -c#{release_path}/chef/config.rb#{release_path}/chef/chef_#{stage}.json"end
  • Vagrant
  • Build automation
  • Jenkins
  • The end result
  • The usual stuffTwitter: @nickednameJoind.in: https://joind.in/8461
  • Further reading“A basic git capistrano workflow”http://labs.headshift.com/2012/02/29/a-basic-gitcapistrano-workflow/“A successful git branching model”http://nvie.com/posts/a-successful-git-branching-model/The dbPatch projecthttp://www.dbpatch-project.com/“Continuous deployment with symfony2, jenkins and capifony”http://jeremycook.ca/2012/11/04/continuous-deployment-with-symfony2-jenkin“Software branching and parallel universes”http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-un