CONTINUOUS
DEPLOYMENT
Lars Kluge, Hacker.
Previously CTO and Cofounder of Kitchensurfing.
DEFINITION
Continuous Deployment is the automated
process of shipping your product to
production, with every push to master.
MOTIVATION
Earlier feedback for your business: get features in front of
users as early as possible
Faster development: dev...
THE BIG PICTURE
WHO IS USING IT?
Facebook, Etsy, Quora, Linkedin, …
IS IT PRACTICAL FOR SMALLER STARTUPS?
YES.
We use it and love it at Kitchensurfing.
OUR STACK
Ruby on Rails, MongoDB, Heroku, …
OUR WORKFLOW
1. Pick up a ticket in Pivotal Tracker
2. Code
3. Commit with reference to ticket id
4. Pull Request on Github
5. Code Rev...
OUR LEARNINGS
MONGODB HELPS.
NO SCHEMA.
ETSY
source
WITH MONGODB:
While (re)inventing your product,
no* schema migration necessary.
YOUNG PRODUCT = A LOT SCHEMA CHANGES
TRUST YOUR TEST SUITE
RELEASE BIG PRODUCTS IN SMALL PIECES
USE FEATURE FLAGS
Show new features only to your beta user group
Avoid the 'big bang' release
OBSERVE PRODUCTION AFTER DEPLOY
Not only exception tracking
How are business #s changing?
Cloud behavior
MMS Monitoring fo...
BEHAVIOR CHANGE
Is your team ready to make the behavior change?
The whole team needs to support it.
Introduce Continuous D...
PRODUCT TEAM
How to break down features into small, easy to release
pieces? What is the order of operation?
COMMUNICATION
Keep your team in the loop
Release Notes Email
What is online, what's not?
Ticket finished, does it mean it'...
RUNTIME OF TEST SUITE
> 15 Min. tricky
Context Switch is expensive for Engineers
HEROKU PREBOOT
$ heroku labs:enable -a myapp preboot
FUTURE PLANS
Better Release Notes Email based on finished stories in
Tracker
Statistics in Pull Request to understand the ...
THANK YOU.
larskluge.com
@aekym
Webinar: Continuous Deployment with MongoDB at Kitchensurfing
Upcoming SlideShare
Loading in...5
×

Webinar: Continuous Deployment with MongoDB at Kitchensurfing

2,444

Published on

Continuous Deployment is gaining popularity with companies like Facebook and Etsy, but its successful implementation creates technical challenges and will require any team to make workflow changes. Learn how Kitchensurfing switched to continuous deployments and how they’ve grown from one deploy a week to 10+ deploys a day with zero downtime and zero worries, thanks to MongoDB. Hear about their workflow, the tools they use, and how they manage communication with product owners to make sure everyone is always in the loop.

Published in: Technology

Webinar: Continuous Deployment with MongoDB at Kitchensurfing

  1. 1. CONTINUOUS DEPLOYMENT Lars Kluge, Hacker.
  2. 2. Previously CTO and Cofounder of Kitchensurfing.
  3. 3. DEFINITION
  4. 4. Continuous Deployment is the automated process of shipping your product to production, with every push to master.
  5. 5. MOTIVATION Earlier feedback for your business: get features in front of users as early as possible Faster development: develop, push, next feature Fewer merge conflicts Lower the risk of deployments Motivation for everyone involved: changes can be done immediately--no wait for the next scheduled release
  6. 6. THE BIG PICTURE
  7. 7. WHO IS USING IT? Facebook, Etsy, Quora, Linkedin, …
  8. 8. IS IT PRACTICAL FOR SMALLER STARTUPS?
  9. 9. YES. We use it and love it at Kitchensurfing.
  10. 10. OUR STACK Ruby on Rails, MongoDB, Heroku, …
  11. 11. OUR WORKFLOW
  12. 12. 1. Pick up a ticket in Pivotal Tracker 2. Code 3. Commit with reference to ticket id 4. Pull Request on Github 5. Code Review 6. Multiple Staging Environments if manual check necessary 7. CI: Codeship runs test suite for pull request 8. Merge into master 9. Github notifies Pivotal Tracker that ticket is merged 10. CI runs again 11. On successful build, Codeship deploys to Heroku 12. Release Notes Email sent by Heroku
  13. 13. OUR LEARNINGS
  14. 14. MONGODB HELPS.
  15. 15. NO SCHEMA.
  16. 16. ETSY source
  17. 17. WITH MONGODB: While (re)inventing your product, no* schema migration necessary.
  18. 18. YOUNG PRODUCT = A LOT SCHEMA CHANGES
  19. 19. TRUST YOUR TEST SUITE
  20. 20. RELEASE BIG PRODUCTS IN SMALL PIECES
  21. 21. USE FEATURE FLAGS Show new features only to your beta user group Avoid the 'big bang' release
  22. 22. OBSERVE PRODUCTION AFTER DEPLOY Not only exception tracking How are business #s changing? Cloud behavior MMS Monitoring for MongoDB New Relic
  23. 23. BEHAVIOR CHANGE Is your team ready to make the behavior change? The whole team needs to support it. Introduce Continuous Deployment as early as possible; it's getting harder down the road.
  24. 24. PRODUCT TEAM How to break down features into small, easy to release pieces? What is the order of operation?
  25. 25. COMMUNICATION Keep your team in the loop Release Notes Email What is online, what's not? Ticket finished, does it mean it's online?
  26. 26. RUNTIME OF TEST SUITE > 15 Min. tricky Context Switch is expensive for Engineers
  27. 27. HEROKU PREBOOT $ heroku labs:enable -a myapp preboot
  28. 28. FUTURE PLANS Better Release Notes Email based on finished stories in Tracker Statistics in Pull Request to understand the change based on compiled JS, CSS size, test suite build time, # of database queries, etc. Engineering Dashboard: See how a deploy changes business #s
  29. 29. THANK YOU. larskluge.com @aekym
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×