Successfully reported this slideshow.
Your SlideShare is downloading. ×

Continuous Delivery: releasing Better and Faster at Dashlane

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Dashlane Triple Track
Dashlane Triple Track
Loading in …3
×

Check these out next

1 of 21 Ad

Continuous Delivery: releasing Better and Faster at Dashlane

Download to read offline

An introduction to how the Dashlane Engineering Team worked on achieving Continuous Delivery: the ability to deliver to production, fast, reliably and on-demand, through an industrialized automated Release Pipeline.

An introduction to how the Dashlane Engineering Team worked on achieving Continuous Delivery: the ability to deliver to production, fast, reliably and on-demand, through an industrialized automated Release Pipeline.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to Continuous Delivery: releasing Better and Faster at Dashlane (20)

Advertisement
Advertisement

Continuous Delivery: releasing Better and Faster at Dashlane

  1. 1. Continuous Delivery at Dashlane A path to releasing faster and better
  2. 2. We are Tanguy Le Barzic, Backend Team Lead and Frédéric Rivain, CTO of Dashlane. We build a Password Manager, to help you manage your identity and your payments in a simple and secure way everywhere.
  3. 3. A bit of context Funded in 2009 by Bernard Liautaud and 3 Centrale students 110 employees in Paris and New York • Product & Engineering in Paris • Marketing & Sales in New York 4 business lines: • Consumer product (B2C) • Enterprise offer (B2B) • Financial Partners • API and Dev Ecosystem • 7 “production” teams
  4. 4. Our Goal • The ability to deliver to production, fast, reliably and on-demand, through an industrialized automated Release Pipeline.
  5. 5. The Dashlane Platform
  6. 6. Our starting point • Old fragile mercurial versioning system. • Limited CI • Limited unit tests • Manual QA • No systematic Code Review • But already a « DevOps » spirit in all teams  We first needed to address the prerequisites.
  7. 7. Code • Migration to Git (Bitbucket) and review of the branching strategy for each team • Setting up a real Continuous Integration (Bamboo)
  8. 8. Code Quality • Mandatory Pull Requests with multiple reviewers • Code Quality Tools • Sonar, Lint,…
  9. 9. Test Automation • Climbing the Pyramid of tests. • Hard and long. • Train manual QA to start coding automated tests • Focus Devs on unit tests • Define smoke tests scope • Find the right tools for functional tests for each platform • iOS: Xcode • Android: Espresso • Windows: Ranorex • Mac: Xcode • Web: Watir • Plug into CI • Keep pushing over and over. • Way better today, but still work to do. UNIT TESTS INTEGRATION TESTS FUNCTIONAL TESTS MANUAL TESTS AUTOMATED TESTS
  10. 10. Monitoring • Already a good logging framework. Sent by our applications to track user activity and performance • Business logs • Technical logs • Performance logs • Dashboards in Kibana and Tableau • Adding Alert System • Practice of Morning Gymnastics
  11. 11. Focusing now on Continuous Delivery • Painting the Target Release Pipeline
  12. 12. What is our Continuous Delivery Target? • Each platform is specific. • Adapt what we mean by Continuous Delivery for each platform. • Ability to ship native client every week. Platform Frequency iOS Release train every 2 weeks Android Release train every 2 weeks Windows Release train every 2 weeks. Silent install. Targeting every week. MacOS Release train every 2 weeks for Mac AppStore Release train every 2 weeks for DMG. Silent install. Targeting every week. Web Extensions: Release train every 2 weeks. Silent install. Targeting every week. Web Apps: On Demand, except Fridays. Server / Backend On Demand, except Fridays. Web Site On Demand, except Fridays.
  13. 13. Diving • First iterations were painful. • Some fear of the unknown. • Fix issues and smooth process as we progress. • Improve QA process as well. • Everybody eventually feeling happier: dev, product, business,…
  14. 14. Continuous Delivery Tools • Build our own Feature Flipping tool. • Improving Monitoring Dashboards for releases. • Working on building an improved version of our old A/B Test Engine.
  15. 15. Example of the server team • 10 developers (in Paris and Vilnius) • 50 or so projects • Main project (‘user’ webservices) • 370k lines • 3000 tests (closer to integration tests than unit tests) • CI on every branch (tests and linting) • 2 approvals for each PR, rebase enforced • Deployment triggered manually, in one command • Average of 2 deployments a day
  16. 16. CD pipeline JIRA
  17. 17. Performance is a feature – CD edition • One of the goals of CD: faster feedback, less context switching • The speed of every step of the pipeline matters • Time to run the CI • Time for code reviews • Time for QA • Time for deployment
  18. 18. Aggregated metric: time to ship a commit
  19. 19. What are the next things to improve? • How long is your pipeline taking? If you had to fix something now, what’s the smallest ETA of a fix? • Do you have a bad feeling about this particular deployment? • « Make sure to watch the error logs after this one » • How many things do you have to think about before deploying? • « Update the credentials » • « Make sure you pull the deployment project » • « Don’t forget to alter the database before deploying » • Do you know whether a given JIRA story has been shipped, to who?
  20. 20. Questions ?
  21. 21. Thank you © 2017 Dashlane, Inc

×