Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Continuous Delivery: releasing Better and Faster at Dashlane


Published on

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.

Published in: Software
  • Login to see the comments

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