Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Improve the deployment process step by step

254 views

Published on

A guide to improve the deployment process of a PHP app in a way that does not hurt.

Published in: Engineering
  • Be the first to comment

Improve the deployment process step by step

  1. 1. Improving the deployment Process Step by Step
  2. 2. About me Daniel Fahlke (aka Flyingmana) ● Working as a Software Engineer with Magento and PHP ● Doing lots of open Source ● Helps maintaining the OpenMage-LTS Fork ● http://flyingmana.name/ ● https://github.com/Flyingmana ● https://twitter.com/Flyingmana ● https://www.patreon.com/Flyingmana ● https://github.com/OpenMage/magento-lts
  3. 3. About my Workplace (simplified version) https://www.valmano.de/ We sell Watches and Jewelry
  4. 4. About my Workplace (simplified version) https://www.valmano.de/ We sell Watches and Jewelry TV series teached me, Watches are the best anniversary present for long term employees.
  5. 5. Deploying with Git Great, you are not deploying with FTP/SFTP anymore ● Faster switching between version ● Nearly atomar switch (latency between first and last changed file) ○ Error rate of ~0.3% ● No Fear of on server only “workarounds”
  6. 6. What Error Rate?!!!! ● Request Starts ● Request did load a lot of classes ● Files Change ● Loads another class ● New Class uses method which did not exist in already loaded classes ○ ERROR!!
  7. 7. But OpCache ● Request Starts ● Request did load classes from Opcache ● Files Change ● Loads another class from Opcache ● Loads changed template which did not exist before ● New Template uses method which did not exist in already loaded classes ○ ERROR!!
  8. 8. But OpCache ● Request Starts ● Request did load classes from Opcache ● Files Change ● Loads another class from Opcache ● Loads changed template which did not exist before ● New Template uses method which did not exist in already loaded classes ○ ERROR!! I forgot the exact case, why this is not covered from opcache, but it still happens sometimes
  9. 9. How to solve this kind of errors Prevent files being changed while requests are active in the project folder.
  10. 10. Blue / Green Deployment Basic Idea is, you have your project twice on the Filesystem ● An active one, and an inactive one ● This can be a symlink which is used as project root ○ If the first file is loaded in magento, most is loaded relative to this file, not to the docroot ● Or full instances of FPM servers ○ which are switched over by a webserver config ● Works also with NodeJS Apps
  11. 11. Take Servers temporary out of loadbalancer Works only if you have multiple servers ● Take server out of loadbalancer ● Deploy changes ● Put server back in ● Take Next server
  12. 12. But Database Migrations ● Somehow new Code tends to fail, when you dont run the DB migrations
  13. 13. But Database Migrations ● Somehow new Code tends to fail, when you dont run the DB migrations ● Or worse, old Code fails after the DB migration were run.
  14. 14. But Database Migrations ● Somehow new Code tends to fail, when you dont run the DB migrations ● Or worse, old Code fails after the DB migration were run. !!!!Maintainance Mode!!!!
  15. 15. But Database Migrations ● Somehow new Code tends to fail, when you dont run the DB migrations ● Or worse, old Code fails after the DB migration were run. !!!!Maintainance Mode!!!! Means you failed
  16. 16. Best Practice of DB Migrations ● Make your Code work - always ○ Add proper handling so it still works before the migration is done ○ Try to avoid DB changes, which break old code ■ You should be able to roll back a whole week ■ You should deploy more then once a week ■ If something is terrible broken for a week already, dont roll back, push forward ○ Run DB migrations as last step of deployment ■ Maybe even after a first check if everything still works
  17. 17. Best Practice of DB Migrations ● Make your Code work - always ○ Add proper handling so it still works before the migration is done ○ Try to avoid DB changes, which break old code ■ You should be able to roll back a whole week ■ You should deploy more then once a week ■ If something is terrible broken for a week already, dont roll back, push forward ○ Run DB migrations as last step of deployment ■ Maybe even after a first check if everything still works ● Complain to module vendors if they dont follow best practice ○ Tell them about the additional work it did cause for you ○ But be nice ○ And help them with suggestions
  18. 18. How to measure a deployment ● Time between Triggering and finishing deployment ● Time between a failed deployment and a finished rollback ● Error rate & Downtime ● Average Grade of Fear in the Team doing a deployment on Friday at 17:00 ○ And also The Max() ○ Having no Fear and a 2 hour downtime after deployment results in minus points ●
  19. 19. ● Time between Triggering and finishing deployment Not even seconds with git, so why switch? ● Sass ● Babel ● Code Generation ● Composer
  20. 20. ● Time between Triggering and finishing deployment Not even seconds with git, so why switch? ● Sass ● Babel ● Code Generation ● Composer Because you also have a Build step, which is not covered by Git
  21. 21. ● Time between Triggering and finishing deployment Depends a lot on the Build process Solution: ● Move the Build process out of the deployment ● Create build artifacts ○ Composer_vendor_$hash.tgz ○ node_modules_$hash.tgz ○ …. ● Add them via single downloads over the local network
  22. 22. ● Time between a failed deployment and a finished rollback In case you have a Blue / Green deployment, Independent of build process < ~15sec
  23. 23. This is more a risk value, which therefore should be as low as possible. ● Additional health checks during deployment ○ Simulate basic requests ○ Maybe have health check URLs ● Having a CI or Staging setup can help catch problems even before ● Investigate problems afterwards and find automated solutions ○ Never blame the person who hit deploy ● Error rate & Downtime
  24. 24. Fearing deployment Fear in this case is a good sign for something not working reliable. While the previous points should help, there is also a human component always. ● People can only manage a certain amount of changes at once ● Trusting a tool is not happening from one day to another ○ Split changes up into smaller parts ○ Spread them over several weeks ○ Involve them in implementing the changes
  25. 25. Build the Composer Vendor artifact
  26. 26. Use the artifact on deploy
  27. 27. There is no one-size-fits-all solution There are lot of existing solutions ● Capistrano ● Deployer ● Robo ● Ansible And probably a reason why you dont use one of them already.
  28. 28. The learnings ● Take small steps ● Reducing build time is easier than it seems ○ Build artifacts are just another kind of (permanent) cache ● Make DB migrations harmless ● Simple php scripts are NOT bad practice
  29. 29. Thank You for listening In case you want to also say Thank you, support me on Patreon. https://www.patreon.com/Flyingmana I also take Requests for next Topics I should present about.

×