Deployment talk dpc 13

1,101 views

Published on

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

Published in: Technology
1 Comment
2 Likes
Statistics
Notes
  • Hey Robbert!
    Do you have vide/audio for that?
    Thanks
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
1,101
On SlideShare
0
From Embeds
0
Number of Embeds
68
Actions
Shares
0
Downloads
16
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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

    1. 1. Deploying your apps.. the right way!Robbert van den BogerdJune 8th, 2013
    2. 2. Introduction
    3. 3. whoamiDeveloper at IbuildingsWeb enthusiastTravellerThe Average Joe
    4. 4. Disclaimer
    5. 5. DEPLOYMENTSo what are we here for?
    6. 6. TOCHorror storiesCommon pitfallsWhat we wantDeployment from beginning to endIntegration tools
    7. 7. Horror stories
    8. 8. Horror storiesFTP: Forever Taking Process
    9. 9. Horror storiesRsync: for oldschool sysadmins
    10. 10. Horror storiesVersioning checkout
    11. 11. Horror storiesTeamviewer: REALLY?
    12. 12. Problems & solutions
    13. 13. Common pitfallsManual operationsSloow deployment processDowntimeCacheMigrationsNo turning back
    14. 14. Manual operationsNo!The Bus FactorAnyplace, anywhere, anytimeConfidence
    15. 15. No turning back
    16. 16. Zero downtimeNo more UC pages!Quick deploysSmaller releasesAutomate
    17. 17. Cache
    18. 18. Migrations
    19. 19. Common pitfallsManual operationsSloow deployment processDowntimeCacheMigrationsNo turning back
    20. 20. What we wantManual operations AutomationSloow deployments Quick rolloutsZero DowntimeCache warmed upMigrationsNo turning back Rollbacks
    21. 21. From the beginning..
    22. 22. “Victorious warriors first winand then go to war”- Sun Tzu
    23. 23. Think before you (sign a contr)act!
    24. 24. Managing expectationsCustomerUsersProject managerDevs/testers
    25. 25. Deployment strategyRelease cycleServer setupBranching strategyTools to use
    26. 26. DTAP
    27. 27. So, lets cut to the point..
    28. 28. Use git
    29. 29. Seriously, use git!ReliableSuper fastEasy branching/mergingDistributedGithub:Awesome uiExtrasPRsIntegration with existing deployment tools
    30. 30. Dependency managementFrameworkLibrariesBuild/QA toolsCompany private repos
    31. 31. Drumroll please..
    32. 32. Composer
    33. 33. MigrationsWrite your own scriptUse one of the great existing ones:- Doctrine migrations- DbPatch- Shipped with your framework/orm?
    34. 34. BackupsAlways create one!..unless its not possible =]
    35. 35. 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
    36. 36. Deployment script> Do a backup> Create new directory> Update your code> Update dependencies> Run migrations> Warmup cache> ...
    37. 37. Lets start scripting!
    38. 38. Wait a second..
    39. 39. Existing toolsFabricPhing/AntChefCapistrano
    40. 40. CapistranoPowerfulEasy setupEvent/task based, easy to hook intoWritten in rubyMultiple serversMultistage extension
    41. 41. CapifonyThe power of CapistranoPre-configured for SymfonyDeploy with 1 single config file
    42. 42. Setup
    43. 43. Local setupgem install capifonycd /var/www/rule34/capifony install .
    44. 44. 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"
    45. 45. Remote setupcd /var/www/rule34/cap deploy:setup
    46. 46. Deploy
    47. 47. Capifony deploycd /var/www/rule34/cap deploy# made a boo-boo?cap deploy:rollback
    48. 48. Configurationset :model_manager, "doctrine"
    49. 49. Configurationset :update_vendors, falseset :use_composer, trueset :vendors_mode, "install"
    50. 50. Configurationset :dump_assetic_assets, true
    51. 51. Configurationset :shared_children, [app_path+"/logs", "data"]set :writable_dirs, [app_path+"/logs", app_path+"/cache", "data"]
    52. 52. Directory structure/var/www/rule34/releases/shared/shared/data/shared/app/logsSymlink:/var/www/rule34/releases/20130606143400/data > ../../shared/data
    53. 53. DTAP
    54. 54. 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"
    55. 55. 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”
    56. 56. Maintenance pagecap deploy:web:disable REASON="hardware upgrade" UNTIL="12pm Central Time"# override templateset :maintenance_template_path, “app/Resources/uc.html”
    57. 57. 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
    58. 58. Tips n Tricks# enable ssh client interactiondefault_run_options[:pty] = true
    59. 59. Tips n Tricks# enable agent forwardingssh_options[:forward_agent] = true
    60. 60. Tips n Tricks# cleanup old release dirs automaticallyset :keep_releases, 3after "deploy", "deploy:cleanup"
    61. 61. Tips n Tricks# run doctrine migrations after code updateafter “update_code”, “doctrine:migrations:migrate”
    62. 62. Tips n Tricks# run any symfony console commandbefore “any_task”, “symfony:cache:clear”
    63. 63. Whats next?
    64. 64. System provisioningUpgrade PHP 5.3 > 5.4Upgrade MySqlInstall RedisInstall Node.jsEtc..
    65. 65. ChefVersion control your infrastructureIdentical environmentsIntegration with Vagrant
    66. 66. Chef# run chef after code updateafter “update_code”, “provision”task :provision doend
    67. 67. 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
    68. 68. Vagrant
    69. 69. Build automation
    70. 70. Jenkins
    71. 71. The end result
    72. 72. The usual stuffTwitter: @nickednameJoind.in: https://joind.in/8461
    73. 73. 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

    ×