Deployment talk dpc 13

Editor's Notes

• #5: 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.
• #9: 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.
• #14: 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.
• #17: Wherever you can optimize, optimize! Higher release frequency means smaller deploys means less risk of exceptions Main point of presentation: optimize & automate!
• #20: 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.
• #23: 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.
• #24: 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.
• #25: 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.
• #31: 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.
• #35: 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.
• #38: So now we're getting more and more close to having us a deployment script