Continuous deployment is the automated process of shipping code to production with every push to the master branch. Some benefits include earlier feedback, faster development, and lower risk of deployments. Kitchensurfing uses continuous deployment with Ruby on Rails, MongoDB, and Heroku. Their process includes code reviews, testing, and automated deployment to Heroku after successful builds. MongoDB helps avoid schema migrations during product development. They emphasize trusting test suites, releasing in small pieces, using feature flags, and observing production after deployments.

1. CONTINUOUS
DEPLOYMENT
Lars Kluge, CTO and Co-founder of Kitchensurfing

2. KITCHENSURFING

6. WHO IS FAMILIAR WITH …?

7. DEFINITION

8. Continuous Deployment is the automated
process of shipping your product to
production, with every push to master.

10. MOTIVATION?
Earlier feedback for your business: get features in front of
users as early as possible
Faster development: develop, push, next feature
Lower the risk of deployments
Motivation for everyone involved: changes can be done
immediately--no wait for the next scheduled release

11. WHO IS USING IT?
Facebook, Etsy, Quora, Linkedin, …

12. IS IT PRACTICAL FOR SMALLER STARTUPS?

13. YES.
We use it and love it at Kitchensurfing.

14. OUR STACK
Ruby on Rails, MongoDB, Heroku, …

15. OUR WORKFLOW

16. 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

17. OUR LEARNINGS

18. MONGODB HELPS.

19. NO SCHEMA.

20. ETSY
source

21. WITH MONGODB:
While (re)inventing your product,
no* schema migration necessary.

22. YOUNG PRODUCT = A LOT SCHEMA CHANGES

23. TRUST YOUR TEST SUITE

24. RELEASE BIG PRODUCTS IN SMALL PIECES

25. USE FEATURE FLAGS
Show new features only to your beta user group
Avoid the 'big bang' release

26. OBSERVE PRODUCTION AFTER DEPLOY
Not only exception tracking
How are business #s changing?
Cloud behavior
MMS (MongoDB Monitoring Service)
New Relic

27. 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.

28. PRODUCT TEAM
How to break down features into small, easy to release pieces?
What is the order of operation?

29. COMMUNICATION
Keep your team in the loop
Release Notes Email
What is online, what's not?
Ticket finished, does it mean it's online?

30. RUNTIME OF TEST SUITE
> 15 Min. tricky
Context Switch is expensive for Engineers

31. HEROKU PREBOOT
$ heroku labs:enable -a myapp preboot

32. OUR 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

33. THANK YOU.
larskluge.com
@aekym