webinar: continuous deployment with mongodb at kitchensurfing

30
CONTINUOUS DEPLOYMENT Lars Kluge, Hacker.

Upload: mongodb

Post on 21-May-2015

2.266 views

Category:

Technology


0 download

DESCRIPTION

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.

TRANSCRIPT

CONTINUOUSDEPLOYMENT

Lars Kluge, Hacker.

Previously CTO and Cofounder of Kitchensurfing.

DEFINITION

Continuous Deployment is the automatedprocess of shipping your product to

production, with every push to master.

MOTIVATIONEarlier feedback for your business: get features in front ofusers as early as possibleFaster development: develop, push, next featureFewer merge conflictsLower the risk of deploymentsMotivation for everyone involved: changes can be doneimmediately--no wait for the next scheduled release

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 STACKRuby on Rails, MongoDB, Heroku, …

OUR WORKFLOW

1. Pick up a ticket in Pivotal Tracker2. Code3. Commit with reference to ticket id4. Pull Request on Github5. Code Review6. Multiple Staging Environments if manual check necessary7. CI: Codeship runs test suite for pull request8. Merge into master9. Github notifies Pivotal Tracker that ticket is merged

10. CI runs again11. On successful build, Codeship deploys to Heroku12. Release Notes Email sent by Heroku

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 FLAGSShow new features only to your beta user group

Avoid the 'big bang' release

OBSERVE PRODUCTION AFTER DEPLOYNot only exception tracking

How are business #s changing?

Cloud behavior

MMS Monitoring for MongoDB

New Relic

BEHAVIOR CHANGEIs your team ready to make the behavior change?The whole team needs to support it.Introduce Continuous Deployment as early as possible; it'sgetting harder down the road.

PRODUCT TEAMHow to break down features into small, easy to release

pieces? What is the order of operation?

COMMUNICATIONKeep your team in the loopRelease Notes EmailWhat is online, what's not?Ticket finished, does it mean it's online?

RUNTIME OF TEST SUITE> 15 Min. trickyContext Switch is expensive for Engineers

HEROKU PREBOOT$ heroku labs:enable -a myapp preboot

FUTURE PLANSBetter Release Notes Email based on finished stories inTrackerStatistics in Pull Request to understand the change basedon compiled JS, CSS size, test suite build time, # of databasequeries, etc.Engineering Dashboard: See how a deploy changes business#s

THANK YOU.larskluge.com

@aekym