Developer day - AWS: Fast Environments = Fast Deployments
•Download as PPTX, PDF•
0 likes•409 views
The document discusses how AWS enables fast and flexible deployments through automation. It outlines problems with manual and unique server deployments like breakages and lack of change management. The solution presented is to automate the entire process through continuous integration and deployment tools like Jenkins, GitHub, Grunt, and AWS CloudFormation. This treats servers as identical and deployable resources, ensures all code is tested and production-ready, and allows for boring but successful automated deployments on demand.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to Developer day - AWS: Fast Environments = Fast Deployments
Similar to Developer day - AWS: Fast Environments = Fast Deployments (20)
Recently uploaded
Recently uploaded (20)
Developer day - AWS: Fast Environments = Fast Deployments
- 1. AWS: Fast Environments = Fast and Flexible Deployments Matthew Cwalinski
- 2. The Process Last in line gets the blame.
- 3. The Process The order of things Source DevelopPlan Deploy
- 4. The Process The order of things Source DevelopPlan Deploy
- 5. The Process Why the deployment step was a problem Source • Manual Process • Does New Code Break Server? (yes) • Snowflake (unique) Servers - Every server was different • No Change Management - Find the code and push the code
- 6. The Change Be an agent of change
- 7. The Change Automate Everything Source • Automate Testing,Security and the entire process • All code/changes should be production ready • Treat your servers like cattle. Phoenix upgrading. • Continuously Integrate and Deploy
- 10. The How How do we automate infrastructure?
- 11. The How How do we automate infrastructure? Source • Set of tools • Repeatable process • If it’s boring - it’s working
- 12. The How Our Tools of the Trade
- 13. Amazon Web Services The Big Guns
- 14. Grunt Doer of Dirty Work GitHub The Control Freak
- 15. Jenkins The Keeper of Order
- 17. Deployment Steps Repeated over and over again Source 1 2 43 Grunt + GitHub Jenkins AWS Application
- 18. Uneventful Boring deployments = successful deployments
- 19. The Review Have we fixed the problem? Source • Manual Process • Continuous Integration and Deployment • Does New Code Break Server? • No • Snowflake (unique) Servers - Every server was different • Each server is identical and new • No Change Management - Find the code and push the code • It is always production ready and tested
- 20. The Review Did we automate everything? Source • Automate Testing and Security • Grunt! • All code/changes should be production ready • GitHub • Treat your servers like cattle. Phoenix upgrading. • CloudFormation • Continuously Integrate and Deploy • Jenkins
- 21. Conclusion I must conclude here.
Editor's Notes
- Deployment is always the last step when it comes to pushing out a new feature, bug fix or any kind of change. Because of that, it usually has the most visibility when it comes to crossing the finishing line with the feature.
- Each part of the process is equally important and from the outset, is treated as such. However, when deadlines approach, things change.
- Planning and development begin to overlap more and more and the window to test and deploy becomes smaller and smaller. I used to view this as a problem and take no accountability for it. But, when I started to look at the deployment process in a vacuum, it had it’s issues and was an equal contributor to slowing down all of the processes.
- What were some of the issues? Deployments were always a manual process. When we introduced new code, it would break the server. This was because we had snowflake servers. Each server was different, running different minor versions of different frameworks, different users/permissions. Anything you could think of. No change management process to test code for different environments before pushing to the environment.
- To do all of this - we needed to be ready to change and we had to change from the very core.
- We moved towards automating our infrastructure. Specifically, adopting the philosophy of inf as code.
- We wanted the right set of tools. We wanted a repeatable process and if deployments were boring, then we knew this was working.
- The tools we chose obviously had a foundation of AWS. On top of that we leveraged GitHub, Jenkins and Grunt.
- AWS has lots of services and dozens of different ways to automate your deployments. Exploration and testing is the best way to find what is right for you. I’m still testing and getting ready to talk about a whole new way to deliver our app in a server less way. Change is always coming.
- Grunt is our local tool for testing and automating a lot of the dirty work for us. Grunt is a JS task runner, that we configure to test not just our code as we write it, but also look for malicious or outdated libraries we integrate within our application. It handles basic tasks like minification for us, but even goes further in integrating modular code for us, so we don’t have to do this manually. Github isn’t new to the engineering world, but it’s starting to be relied on not only for it’s version control, but how well it integrates with various services. We use it to help push tested code in a continuous way to various environments when new branches are updated. This allows us to remove the manual process of this step.
- Jenkins is our tireless friend who works side by side with github and listens whenever there is a new change and pushes it out to AWS for us. It lets us know how everything went and alerts us of failures.
- Each AWS service we use is important, but we currently rely on cloudformation the most. Cloudformation is a service that allows you to write son templates (inf as code) that determine what resources you want provisioned for your stack, how they should be set up, named, configured, any customization you can think of. This service allows us to update our stack and have new instances every time we push new production code.
- So now - our deployment process looks like this.
- It’s pretty boring and uneventful. Failures are few and far between and new features are pushed daily, without the need to plan for them. This allows us to spend more time on development.
- In conclusion, addressing deployments alone and creating a fast environment to operate in has created faster deployments.