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.
Continuous Delivery: releasing Better and Faster at Dashlane
Continuous Delivery at Dashlane
A path to releasing faster and better
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.
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
• The ability to deliver to production, fast, reliably and on-demand, through an
industrialized automated Release Pipeline.
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.
• Migration to Git (Bitbucket) and review of the branching strategy for each team
• Setting up a real Continuous Integration (Bamboo)
• 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.
• 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
Focusing now on Continuous Delivery
• Painting the Target Release Pipeline
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.
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.
• 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,…
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.
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
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
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?