Taking your code to production
1 like195 views
The document discusses best practices for taking code to production, including deploying using a 12 factor app methodology. It emphasizes that code should work reproducibly across environments from development to production. Specific practices discussed include using version control, declaring explicit dependencies, separating configuration from code, treating backing services as external resources, and executing apps as stateless processes. The document also covers continuous integration/delivery, testing at various stages, code reviews, and blue-green deployments.
Taking your code to production
- 1. PAGE Industry Partner Taking your code to production Deployment and 12 factor
- 2. PAGE Industry Partner Speaker: Muayyad Alsadi Free software contributor and advocate. One of the Tech leads at OpenSooq.com. https://muayyad-alsadi.github.io/
- 3. PAGE Industry Partner It works on my laptop ● Developers write the code ● On their laptops they sacrifice anything to get it to work ● They try and experiment with all kinds of things ● They add all kinds of dependencies of arbitrary random versions ● Their environment is not reproducible ● They even can’t tell you what they have installed to get it to work
- 4. PAGE Industry Partner It works on my laptop • The develop is not aware that he is using bleeding edge non-production branch of library that only adds a shiny logo and millions of bugs • The develop is too lazy, instead of using standard things he uses all kinds of third party helpers • The developer tries to avoid writing two lines of code by using thousands of random code on the internet that he/she does not understand. • The developer is trying to avoid reading the docs by re-inventing the wheel • Re-inventing the square wheel indeed. • The developer hacks the framework core so it no longer do what it’s expected to do. And there is no documentation of the new behavior • Too much magic behind the scenes.
- 8. PAGE Industry Partner It works on my laptop • The data needed to reproduce the bug is not in the outdated or small dev database. • The bug is only seen at thousands of requests per seconds • The bug is only seen when your first request lands on a server on one region and then next requests on another requests • The scenario needed to reproduce the bug involves new sign up with a new real facebook account, sms verification with a real phone number in another country, doing a payment ..etc. • The bug is not even reproducible • Heisenbug/schrödinbug is a bug that changes its behavior when you study it (in the presence of tools to debug it)
- 9. PAGE Industry Partner Software Defined Everything • Software can add more value (ex. a smartphone software can use gyroscope sensor to do image stabilization) • Software define the value • Software defined does not mean fake or virtual but it means – Controlled – Scriptable and Automated – Reproduced • Software as a service – “Everything as a service” • Ironic is a bare-metal as a service
- 10. PAGE Industry Partner Microservice Architecture • Infrastructure as code • Microservice is Similar to Unix Philosophy – Do one thing and do it right – Everything is a file (here everything is a service) – Every file is a text file (every service is a load-balanced port)
- 12. PAGE Industry Partner Pets vs. Cattle
- 13. PAGE Industry Partner Cattle vs. Ants ● Thousands of containers ○ docker ● Fast startup time ● Continue to work even if you kill many of them ● Dev-Ops
- 14. PAGE Industry Partner Cattle vs. Burger ● Serverless ○ Lambda ○ Kubeless.io ● No-ops
- 15. PAGE Industry Partner On-premises vs. pay as you go
- 16. PAGE Industry Partner Introducing 12 Factor App • https://12factor.net/ • By Heroku co-founder Adam Wiggins • #1 code in a VCS (like git), one app, one code, many deployments. – Dev1, dev2, staging, production, all same code, same repo – No many apps sharing code (split common into libraries) • #2 Explicitly declare and isolate dependencies – No system-wide dependencies • One app uses django 1.11 while other needs 1.9 – Scoped dependencies • Python’s virtualenv • Ruby’s bundler • Php’s composer into vendor directory ..etc.
- 17. PAGE Industry Partner Introducing 12 Factor App • #3 Strict separation of config from code – Accept config from environment variable or service discovery – No config hardcoded in the code – “confd” can be used to template environment variable into config files • #4 Treat backing services as attached resources – Like MySQL or MongoDB or S3 – Resources can be attached and detached to deploys at will. For example, if the app’s database is misbehaving due to a hardware issue, the app’s administrator might spin up a new database server restored from a recent backup. The current production database could be detached, and the new database attached – all without any code changes.
- 18. PAGE Industry Partner Introducing 12 Factor App • #5 Strictly separate build and run stages • #6 Execute the app as one or more stateless processes – Stateful parts are via attached backing services – Sticky sessions are a violation of twelve-factor and should never be used or relied upon • #7 Export services via port • #8 Scale out via the process model • #9 Disposability: Maximize robustness with fast startup and graceful shutdown – app’s processes are disposable, meaning they can be started or stopped at a moment’s notice • #10 Keep development, staging, and production as similar as possible
- 19. PAGE Industry Partner Introducing 12 Factor App • #11 just output logs to standard output – A twelve-factor app never concerns itself with routing or storage of its output stream. • #12 Run admin/management tasks as one-off processes – One-off admin processes should be run in an identical environment as the regular long-running processes of the app. They run against a release, using the same codebase and config as any process run against that release. Admin code must ship with application code to avoid synchronization issues.
- 20. PAGE Industry Partner Similar Manifesto • http://www.reactivemanifesto.org/ • Resilient: expect the failure as part of the process • Elastic: – Scale-out (not scale up) to handle high loads – Scale-in to save cost • Message driven
- 21. PAGE Industry Partner Gitflow workflow • An always stable production/release branch – Known to be working • Each feature is a branch – Developers work in • A merge (staging) branch – To be production branch • Hotfix fast lane • Tag for each past release • Branch for past releases if you are going to support them with backports
- 22. PAGE Industry Partner Code Quality • Fail early • Auto checks before you commit – Pre-commit hook on developer machine – “php -l” that checks syntax – “python -m compileall MyApp” • Lint your code for a common style and best practices – Pylint for python, eslint for javascript/nodejs
- 23. PAGE Industry Partner Left: pylintrc showing how I disabled some warnings, and allowed some names Right: Pylint telling you that you should put spaces around assignment “=”
- 25. PAGE Industry Partner CI/CD • Continuous integration / continuous delivery • The What? – Each/some commits or tags or pushes triggers build servers, integration and automated tests • The Why? Reproducible builds, guaranteed quality • The How – Jenkins (I hate it, but it’s the most common) – Gitlab ci – Good old git hooks (server side), scripts, ansible ..etc.
- 26. PAGE Industry Partner Some types of testings • Unit tests: test every function – Positive assertions – Negative assertions – Coverage: did your test cases cover all code (cases for if part, other cases for else part) • Stress testing: – siege/ab – A way to skip cache (Always miss cache component) – Replay network capture from live on test
- 27. PAGE Industry Partner Code review and process
- 28. PAGE Industry Partner Code review and process
- 29. PAGE Industry Partner Deployments • Local – developer code on developer machine – In-office toy machine • Test (developer code on non-developer environment) • Staging – Merge / Integration – Many features and branches – Avoid conflicting or competing changes • Pre-Production – Candidate code on production database
- 30. PAGE Industry Partner Canary testing • Pass small fraction of production traffic to new candidate code • Deliver the new version of the app (ex. Via Google play) to small fraction of users • Enable the new feature to small fraction of user base (using configuration service)
- 31. PAGE Industry Partner Blue-green deployment • Roll the new release using a fan out, instead of all servers at once • Let’s denote current production version as green and new release as blue • Make 10% of servers blue, 90% green • Increase the percent blue, while watching logs • End with all blue servers.
- 32. PAGE Industry Partner Immutable servers • You don’t just “git pull” code on existing servers • You launch new servers running new code • When done, you terminate old ones. • Servers are not pets, they get launched and killed all the time • Deliver code as docker images • Orchestrate containers using kubernetes