Uniplaces deploy

internal presentation about our delivery process

Transcript

1. Uniplaces Deploy What is really happening here ?
2. Agenda • Principles and definitions • The root • The present (pipeline, environments etc...) Intro
3. Principles and definitions
4. • Is a way of working where developers and system operators work in harmony with little or no organizational barriers between them, towards a common goal. • Is not a way to get developers doing operational tasks so that you can get rid of the operations team and vice versa. • Is not a person who does system operational tasks Principles and definitions DevOps
5. A software engineering approach in which teams keep producing valuable software in short cycles and ensure that the software can be reliably released at any time. Principles and definitions Continuous Delivery
6. Is a method of ensuring the software asset, which is being developed builds correctly and plays nicely with the rest of the platform. Principles and definitions Continuous Integration
7. Principles of software delivery How everything connects
8. Deploying software ultimately involves three things: • Provisioning and managing the environment in which your application will run (hardware configuration, software, infrastructure, and external services.) • Installing the correct version of your application into it. • Configuring your application, including any data or state it requires. Principles of software delivery Definition of Deploy
9. Create a repeatable and reliable process for releasing software. Principles of software delivery
10. Goals 1/2 • Can we deploy the same binary to multiple environments ? • Can we access the binary and source repositories ? • Can we remotely invoke and control the installation process on the server it’s been deployed to ? • Are we capable of deploying database changes ? • Can we manage or at least reference environment/server specific configuration and deploy that along with the binary ? • Do we have functionality to allow for queuing up releases ? • Do we audit what has been deployed, when, and by whom ? Intro
11. Goals 2/2 • Are we secure ? • Can we interact with the infrastructure to allow for no-downtime deployments ? • Can we orchestrate automated infrastructure provisioning ? • Can we extend to interact with other systems and solutions such as email, change management, issue management, and project management solutions ? • Do we have a simple and easy to understand dashboard that can be displayed on big screens around the office ? • Can we interact with/or orchestrate the CI solution ? • Will it grow with our needs ? • Is it simple enough for anyone and everyone to use ? Intro
12. The root
13. Development environment The root
15. • 3 platforms (core, ops and admin) • VCS working (Git) • CircleCI running tests • Development environment close to staging and prod • One VM per project • Each VM was provisioned with Ansible • Data stores in VM’s (Redis and Disk) • Deploy with VCS (git checkout version) The root What we had on development
16. Staging and production environments The root
18. • 3 platforms (core, ops and admin) • VCS working (Git) • CircleCI running tests • One EC2 instance for all projects • Manual provision • Different datastores (one for staging and other for production) • Deploy with VCS (git checkout version) The root What we had on staging and production
19. • Manual deploys (need to ssh the machine git pull, build assets, update php dependencies etc…) • All projects in the same machine, if one project creates a problem in some service on the EC2 Instance or something happens to the EC2 instance, every project will be down. • If after a year we had to redeploy not only the code but the whole infrastructure we didn’t had an automated way to do that. The root Some pitfalls
20. Goals 1/2 • Can we deploy the same binary to multiple environments ? • Can we access the binary and source repositories ? ✔ • Can we remotely invoke and control the installation process on the server it’s been deployed to ? ✔ • Are we capable of deploying database changes ? ✔ • Can we manage or at least reference environment/server specific configuration and deploy that along with the binary ? ✔ • Do we have functionality to allow for queuing up releases ? • Do we audit what has been deployed, when, and by whom ? The root
21. Goals 2/2 • Are we secure ? • Can we interact with the infrastructure to allow for no-downtime deployments ? • Can we orchestrate automated infrastructure provisioning ? • Can we extend to interact with other systems and solutions such as email, change management, issue management, and project management solutions ? • Do we have a simple and easy to understand dashboard that can be displayed on big screens around the office ? • Can we interact with/or orchestrate the CI solution ? ✔ • Will it grow with our needs ? • Is it simple enough for anyone and everyone to use ? The root
22. The present
23. More platforms for the web ! Student, Accommodation provider, Photography The present
24. More platforms for the background jobs ! core-jobs, spa-jobs, core-reports The present
25. More environments ! Development, Staging, Prod (Prod1 and Prod2), Qaprod1 The present
26. More clusters ! Staging, Prod1, Prod2, Qaprod1 The present
27. More services ! Sphinx, Redis, MySql ... The present
28. And the picture is ... The present
30. Staging has exactly the same setup as prod but with only one cluster. It has it’s own data stores (same services, different hosts) and it’s own jobs. Qaprod1 has the same setup and shares production data stores. The present And this isn’t everything, don’t forget staging and qaprod1 !
31. What do we need to handle ? • 21 A Records on Route53 (prod1, prod2, qaprod1 and staging clusters) • 21 Amazon Elastic Load Balancers. • At least 24 Amazon EC2 instances. • 9 projects The present
32. Manual process ? The present
33. The present Automation with uniplaces deploy Promote Deploy Build Test
34. The present Promote Deploy Build Test
35. The present Promote Deploy Build Test How can we assure that we always return to a stable state?
36. The present Promote Deploy Build Test Immutable infrastructure We never leave the stable state. Once created, it’s never changed.
37. The present Promote Deploy Build Test Unit of deployment From source code/binaries to an AMI image.
38. The present Promote Deploy Build Test python build.py -p {project_name}
39. Principles and definitions Promote Deploy Build Test
40. The present Promote Deploy Build Test The AMI is registered with an identifier (commit hash or tag) on AWS allowing to be chosen later to deploy.
41. Goals 1/2 • Can we deploy the same binary to multiple environments ? • Can we access the binary and source repositories ? ✔ • Can we remotely invoke and control the installation process on the server it’s been deployed to ? ✔ • Are we capable of deploying database changes ? ✔ • Can we manage or at least reference environment/server specific configuration and deploy that along with the binary ? ✔ • Do we have functionality to allow for queuing up releases ? • Do we audit what has been deployed, when, and by whom ? The present
42. Goals 2/2 • Are we secure ? • Can we interact with the infrastructure to allow for no-downtime deployments ? • Can we orchestrate automated infrastructure provisioning ? ✔ • Can we extend to interact with other systems and solutions such as email, change management, issue management, and project management solutions ? • Do we have a simple and easy to understand dashboard that can be displayed on big screens around the office ? • Can we interact with/or orchestrate the CI solution ? ✔ • Will it grow with our needs ? • Is it simple enough for anyone and everyone to use ? ✔ The present
43. The present Promote Deploy Build Test python deploy.py -p {project_name}
44. The present Promote Deploy Build Test • Grab the AMI by identifier and create EC2 instance from it. • Configure environment variables and start required services. • Remove old EC2 instance from the same project. • Attach new instance on project ELB.
45. Goals 1/2 • Can we deploy the same binary to multiple environments ? ✔ • Can we access the binary and source repositories ? ✔ • Can we remotely invoke and control the installation process on the server it’s been deployed to ? ✔ • Are we capable of deploying database changes ? ✔ • Can we manage or at least reference environment/server specific configuration and deploy that along with the binary ? ✔ • Do we have functionality to allow for queuing up releases ? • Do we audit what has been deployed, when, and by whom ? ✔ The present
46. Goals 2/2 • Are we secure ? (No time to cover this here for now, just ask anything you need :) ) ✔ • Can we interact with the infrastructure to allow for no-downtime deployments ? • Can we orchestrate automated infrastructure provisioning ? ✔ • Can we extend to interact with other systems and solutions such as email, change management, issue management, and project management solutions ? ✔ • Do we have a simple and easy to understand dashboard that can be displayed on big screens around the office ? • Can we interact with/or orchestrate the CI solution ? ✔ • Will it grow with our needs ? ✔ • Is it simple enough for anyone and everyone to use ? ✔ The present
47. The present Promote Deploy Build Test Blue/green deployments
48. uniplaces.com
49. The present Promote Deploy Build Test python promote.py
50. uniplaces.com
51. The present Promote Deploy Build Test • We keep changing the route from uniplaces.com from prod1 clusters to prod2 clusters and vice versa.
52. The present Promote Deploy Build Test
53. Goals 1/2 • Can we deploy the same binary to multiple environments ? ✔ • Can we access the binary and source repositories ? ✔ • Can we remotely invoke and control the installation process on the server it’s been deployed to ? ✔ • Are we capable of deploying database changes ? ✔ • Can we manage or at least reference environment/server specific configuration and deploy that along with the binary ? ✔ • Do we have functionality to allow for queuing up releases ? • Do we audit what has been deployed, when, and by whom ? ✔ The present
54. Goals 2/2 • Are we secure ? (No time to cover this here for now, just ask anything you need :) ) ✔ • Can we interact with the infrastructure to allow for no-downtime deployments ? ✔ • Can we orchestrate automated infrastructure provisioning ? ✔ • Can we extend to interact with other systems and solutions such as email, change management, issue management, and project management solutions ? ✔ • Do we have a simple and easy to understand dashboard that can be displayed on big screens around the office ? ✔ • Can we interact with/or orchestrate the CI solution ? ✔ • Will it grow with our needs ? ✔ • Is it simple enough for anyone and everyone to use ? ✔ The present
55. Create a repeatable and reliable process for releasing software. ✔ The present
56. Questions