Deployment automation, cloud platforms, containerization, short iterations to develop and release software—we’ve progressed a lot. And finally it’s official: Kubernetes and OpenShift are the established platforms to help us do scaling and zero downtime deployments with just a few hundred lines of YAML. It’s a great time. Can we finally put all our eggs into one basket? Identify the cloud platform that fits our needs, and jump on it? That could well backfire: Vendor lock-in is the new waterfall, it slows you down. In future you’ll want to jump over to the next better platform, in a matter of minutes. Not months. This talk is about The Art of Writing deployment pipelines that will survive Kubernetes, OpenShift and the like. It’s for Python developers and Kubernetes enthusiasts of all levels – no domain specific knowledge required, all you need to understand will be explained. You’ll learn how to separate application-specific and deployment-specific configuration details, to maximize your freedom and avoid vendor lock-in. Come see a demo of a Django project setup that covers everything from local development to automatic scaling, flexible enough to be deployed on any of your favorite container platforms. Take home a working, future-proof setup for your Python applications. See the original presentation at https://slides.com/bittner/modern-continuous-delivery/

1. Modern Continuous DeliveryModern Continuous Delivery
“ deploy to productiondeploy to production
from commit #1from commit #1

2. Peter BittnerPeter Bittner
DeveloperDeveloper
of people, companies and codeof people, companies and code
@peterbittner, django@bittner.it
behave-django
pyclean
djangocms-maps
ansible-role-software
django-probes
django-apptemplates
codeship-yaml
django-organice
PythonTurtlepainless/tox
django-bootstrap-static

3. Continuous DeliveryContinuous Delivery
“ a set of practices and principles in software engineering
aimed at building, testing, and releasing software
safely, faster, more frequently, and in a sustainable way.
Source: painless.software/continuous-delivery

4. Continuous DeliveryContinuous Delivery
“ a set of practices and principles in software engineering
aimed at building, testing, and releasing software
safely, faster, more frequently, and in a sustainable way.
“ the goal is to put the release schedule
in the hands of the business, not in the hands of IT.
Source: painless.software/continuous-delivery

5. Continuous DeliveryContinuous Delivery
“ a set of practices and principles in software engineering
aimed at building, testing, and releasing software
safely, faster, more frequently, and in a sustainable way.
“ the goal is to put the release schedule
in the hands of the business, not in the hands of IT.
Source: painless.software/continuous-delivery
????
Continuous
Continuous
integration
integration

6. Continuous DeliveryContinuous Delivery
“ a set of practices and principles in software engineering
aimed at building, testing, and releasing software
safely, faster, more frequently, and in a sustainable way.
“ the goal is to put the release schedule
in the hands of the business, not in the hands of IT.
Source: painless.software/continuous-delivery
????
Continuous
Continuous
integration
integration
????
Continuous
Continuous
deploym
ent
deploym
ent

7. Modern?Modern?

8. Modern?Modern?
Immutable infrastructureImmutable infrastructure

9. Modern?Modern?
Immutable infrastructureImmutable infrastructure
Container orchestrationContainer orchestration

10. Modern?Modern?
Immutable infrastructureImmutable infrastructure
Container orchestrationContainer orchestration
Version control + automationVersion control + automation

11. Modern?Modern?
Immutable infrastructureImmutable infrastructure
Container orchestrationContainer orchestration
Version control + automationVersion control + automation
Cloud-native applicationsCloud-native applications

12. Choice or Lock-in?Choice or Lock-in?

13. 1. Clean code1. Clean code
2. Deploy to production2. Deploy to production
from commit #1from commit #1
There must be a better way!There must be a better way!

14. DemoDemo

15. Responsibility LayersResponsibility Layers

16. Responsibility LayersResponsibility Layers
ApplicationApplication

17. Responsibility LayersResponsibility Layers
ApplicationApplication
DevelopmentDevelopment

18. Responsibility LayersResponsibility Layers
ApplicationApplication
DevelopmentDevelopment
DeploymentDeployment

19. Responsibility LayersResponsibility Layers
ApplicationApplication
DevelopmentDevelopment
DeploymentDeployment
AutomationAutomation

20. ApplicationApplication
One environment!
12-factor app.
Build with features.
Compose in environments.
11

21. DevelopmentDevelopment
Make it easy!
Standard practices.
No comprehensive instructions.
Simple & user-friendly!
33

22. DeploymentDeployment
Make it beautiful!
Easy to explain.
Generate + seal your secrets,
or seal + commit your secrets.
22

23. AutomationAutomation
Keep it simple!
What you would do manually.
Tell a story!
ASAP
44

24. ASAP!ASAP!
as simple as possibleas simple as possible

25. Deploy to production!Deploy to production!
often + from commit #1often + from commit #1

26. Iterate!Iterate!
... and improve... and improve

27. Agile, please.Agile, please.
test-driven, pair-programmingtest-driven, pair-programming

28. Free your softwareFree your software
no secrets, no security holesno secrets, no security holes

29. “ The only way to go fastThe only way to go fast
is to go well.is to go well.
--- Robert C. Martin
Source: , 2015Technology and Friends, Episode 354

30. Thank you!Thank you!
for your precious timefor your precious time
Painless SoftwarePainless Software
Less pain, more fun.

31. Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough
to break the rules.
Although practicality beats purity.
Pythonistas OathPythonistas Oath
11

32. Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse
the temptation to guess.
There should be one­­ only one ­­obvious way
to do it.
Although that way may not be obvious
at first sight.
Pythonistas OathPythonistas Oath
22

33. Now is better than never.
Although never is often better
than *right* now.
If the implementation is hard to explain,
it's a bad idea.
If the implementation is easy to explain,
it may be a good idea.
Pythonistas OathPythonistas Oath
33

34. Continuous delivery is
a honking great idea.
If you deploy to production
from commit #1.
Let's do it! ­­ I start today.
Pythonistas OathPythonistas Oath
44
Python