Five (easy?) Steps Towards Continuous Delivery

Slide 1

Slide 1 text

Five (easy?) Steps Towards Continuous Delivery Eberhard Wolff @ewolff innoQ

Slide 2

Slide 2 text

http://continuous-delivery-buch.de/

Slide 3

Slide 3 text

http://microservices-buch.de/ http://microservices-book.com/

Slide 4

Slide 4 text

http://microservices-book.com/primer.html FREE!!!!

Slide 5

Slide 5 text

What is CD?

Slide 6

Slide 6 text

Continuous Delivery = Deployment automation

Slide 7

Slide 7 text

Continuous Delivery = Deployment automation to increase speed

Slide 8

Slide 8 text

Production problem. Boss screams at you. How long to production? <15 min <30 min <60 min >60 min >1 day

Slide 9

Slide 9 text

OH “The application server takes 15 min to start.”

Slide 10

Slide 10 text

Why don’t we deliver software every day into production?

Slide 11

Slide 11 text

Old release Hot fix Old release New release

Slide 12

Slide 12 text

Risk of bug fix small compared to keeping faulty release in production.

Slide 13

Slide 13 text

Would we deliver into production more often if it took e.g. 5 minutes?

Slide 14

Slide 14 text

Would we deliver software into production more often with Puppet, Chef, Docker?

Slide 15

Slide 15 text

Step One Realize deployment automation is just a prerequisite for Continuous Delivery!

Slide 16

Slide 16 text

Continuous Delivery = Deployment automation to increase speed

Slide 17

Slide 17 text

Continuous Delivery = Deployment automation to increase speed

Slide 18

Slide 18 text

What is CD?

Slide 19

Slide 19 text

Agile Manifesto Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Slide 20

Slide 20 text

Build Pipeline Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Many tests to minimize risk Infrastructure automation Fast Feedback

Slide 21

Slide 21 text

Why Continuous Delivery? > Faster Deployment > Higher Reliability > Reproducibility

Slide 22

Slide 22 text

Why Continuous Delivery? > Cost-savings hard to estimate > CD is an important step towards better and faster results €

Slide 23

Slide 23 text

Understand the Goal! > Seemingly simple > …but often forgotten > Not just about time-to-market > Might also be reliability!

Slide 24

Slide 24 text

Reliability > Errors hard to reproduce > Software hard to install > Invest in deployment automation > Ensure environment is identical in development and production

Slide 25

Slide 25 text

Time-to-Market > Optimize processing time! > There is already a pipeline > Goal: Constant flow of features through the pipeline > Optimize throughput

Slide 26

Slide 26 text

Value Stream Mapping > Analyze existing pipeline > Optimize throughput

Slide 27

Slide 27 text

Commit Acceptance Testing Capacity Testing Release Delay Lead Time 5 Days 2 Days 1 Day 1 day 1 day 1 day Automated Acceptance Testing Automated Capacity Testing Testing, Sign Off & Release Cycle Time = Delay + Lead Time 1 hour 20 minutes 20 minutes 30 minutes 2 Day 2 day

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Result > Cycle time reduced: Automated tests faster > …and less effort > Still manual sign-off & Release > Feedback faster: Early 80% acceptance test

Slide 30

Slide 30 text

Goal: Reliability Deployment Automation Goal: Time-to-Market Value Stream Mapping Fast Feedback

Slide 31

Slide 31 text

Step Two Understand goals! Take pragmatic steps!

Slide 32

Slide 32 text

Commit Automated Acceptance Testing Automated Capacity Testing Testing, Sign Off & Release 1 hour 2 day Why Sign Off? Acceptance test = software is accepted

Slide 33

Slide 33 text

Why Sign-Off? > Customer wants to check the final result. > Understandable > But: Slow > But: Hard to reproduce

Slide 34

Slide 34 text

Eliminate manual Sign-off!

Slide 35

Slide 35 text

Sign-off->Automated Tests > Automated tests are fast > …and easily reproducible > …and cheaper > Obviously the better choice!

Slide 36

Slide 36 text

Why Sign-off? > Risk of deploying the wrong software > Lack of trust in tests > Risk handling strategy

Slide 37

Slide 37 text

Handling risk > Make it easier to resolve issues > Make deployment easier and faster > Problem in production easier to fix > Deployment automation

Slide 38

Slide 38 text

Old release New release

Slide 39

Slide 39 text

Old release New release New release New release New release

Slide 40

Slide 40 text

Handling risk > Smaller deployments > More frequent deployments > Less risk that an error sneaks in > Easier to reverse

Slide 41

Slide 41 text

Creating Trust > Customer must understand the tests > Reviews > Use proper kind of tests

Slide 42

Slide 42 text

Automated Acceptance Tests Automated Integration Tests Unit Tests Manual Tests Test Pyramid Visible to customer

Slide 43

Slide 43 text

The ultimate requirement is an automated acceptance test. XP 1999

Slide 44

Slide 44 text

UI Tests: Selenium > Easy to start > Natural for testers > Fragile > Loose semantics

Slide 45

Slide 45 text

Behavior-driven development: Example Scenario: User registers successfully Context Event Expected outcome Given a new user with email [email protected] firstname Eberhard name Wolff When the user registers Then a customer with email [email protected] should exist And no error should be reported

Slide 46

Slide 46 text

Creating Trust > UI Tests are overused and have drawbacks > BDD is designed for customers > But most important: > Choose whatever the customer understands! > UI tests might be OK

Slide 47

Slide 47 text

Step Three Eliminate manual sign-offs! Create trust in tests!

Slide 48

Slide 48 text

CD & DevOps > Usually Dev wants Continuous Delivery (CD) > Dev wants easier and faster releases > Ops not supportive > However, they should aim for less risky deployments…

Slide 49

Slide 49 text

Ops > Optimized for costs > Caught in a local optimum > i.e. standardized environments > …but manual deployment > Large investment for full automation > Continuous Delivery problem to be expected

Slide 50

Slide 50 text

Commit Automated Acceptance Testing Automated Capacity Testing Testing, Sign Off & Release Dev Ops

Slide 51

Slide 51 text

CD & DevOps > No need to create DevOps teams > Collaboration needed, though > Deployment is a joined Ops / Dev effort > Good news: No reorganzation

Slide 52

Slide 52 text

CD & DevOps > Seek feedback from Ops early on > Try to leverage Ops experience

Slide 53

Slide 53 text

DevOps is no organization.

Slide 54

Slide 54 text

DevOps is collaboration.

Slide 55

Slide 55 text

Step Four Deal with the gap between Dev and Ops!

Slide 56

Slide 56 text

Continuous Delivery: Build Pipeline ECommerce System Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release

Slide 57

Slide 57 text

ECommerce System 3rd party systems Database

Slide 58

Slide 58 text

Challenges > Dependencies on 3rd party systems > Must provide test systems > …or mocks > Large database > Must provide test data

Slide 59

Slide 59 text

Challenges > Tests take too long > Deployment takes too long > Continuous Delivery pipeline takes far too long

Slide 60

Slide 60 text

Continuous Delivery with large deployment units is hard.

Slide 61

Slide 61 text

Like real hard.

Slide 62

Slide 62 text

Server Server Microservices > Independent deployment units > E.g. process, VMs, Docker containers > Any technology > Any infrastructure Micro Service Micro Service

Slide 63

Slide 63 text

Microservices ECommerce System 3rd party systems Database

Slide 64

Slide 64 text

Microservices 3rd party systems Database Order Catalog Billing Search

Slide 65

Slide 65 text

Order Billing Customer Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release

Slide 66

Slide 66 text

Microservice Pipeline > Build pipeline per Microservice > Small > Easy to set up > Simpler (3rd party systems) > Faster Feedback: Less tests > Separate critical and less critical parts

Slide 67

Slide 67 text

Migrate to Microservices > Add Microservices to existing system > Implement new features in Microservices > No need to redo the full application

Slide 68

Slide 68 text

Continuous Delivery doesn’t mean Microservices.

Slide 69

Slide 69 text

But can you do Continuous Delivey without supporting it in the architecture?

Slide 70

Slide 70 text

Step Five Adjust the architecture!

Slide 71

Slide 71 text

Conclusion

Slide 72

Slide 72 text

Final words > Do no underestimate the effort! > This is not about automation to save cost. > It is about increasing quality!

Slide 73

Slide 73 text

Conclusion > Deployment automation is just a prerequisite > Understand the goals! Take pragmatic steps! > Eliminate sign-offs! Create trust in tests! > Deal with the gap between Dev and Ops! > Adjust the architecture!

Slide 74

Slide 74 text

Thank You! @ewolff