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.

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.

5. PAGE
Industry Partner

6. PAGE
Industry Partner

7. PAGE
Industry Partner

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)

11. PAGE
Industry Partner
Decouple

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 “=”

24. PAGE
Industry Partner

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

33. PAGE
Industry Partner
Questions?

34. PAGE
Industry Partner
Thank you