Continuous Delivery and Automation: Our Journey at Dashlane

Presented at Quality Talks, Lisbon, 27 November 2019

In this talk, I shared Dashlane's experience of building and scaling Continuous Delivery and automation practices across a complex, multi-platform product. What began as a technical initiative gradually became a cultural transformation that connected teams, tools, and processes around a single goal: delivering value to users faster and with confidence.

Introduction

Dashlane helps millions of users manage passwords, identities, and payments securely across devices. As part of the automation effort, our mission was to improve the delivery pipeline and move from heavily manual releases toward reliable, repeatable automation on every platform, including macOS, Windows, Android, iOS, and web.

This journey was not just about adding more tests or new tools. It was about rethinking how development, quality, and release processes fit together.

What the Talk Covered

The session focused on five main themes:

• Continuous Integration and how automated builds and tests became the foundation
• Continuous Delivery and what it really means in a real product environment
• The technology stack that enabled automation
• The major challenges we faced along the way
• Practical recommendations for teams starting a similar journey

Continuous Integration and Continuous Delivery

One of the first steps was clarifying the difference between CI and CD.

Continuous Integration ensures that every change is integrated and validated automatically. It gives fast feedback and prevents long-lived branches from drifting apart.

Continuous Delivery goes further. It aims to make every change releasable at any time. This requires not only automation but also trust in tests, deployment processes, and collaboration between teams.

Understanding this distinction helped us set realistic goals and communicate clearly across engineering and product.

Working Across Multiple Platforms

Dashlane is present on many platforms, and each one comes with its own constraints. Native applications and web clients require different build systems, test frameworks, and deployment strategies.

We learned that a single universal pipeline was not realistic. Instead, we focused on standardizing principles while allowing platform-specific solutions where necessary. The key was consistency in expectations rather than identical tooling.

Challenges We Faced

The road to Continuous Delivery was far from smooth.

Test reliability was one of the biggest obstacles. Flaky tests slowed down feedback and reduced confidence in automation.

Branching strategies also created friction. When pipelines were slow or unstable, teams naturally reverted to manual checks.

Another constant tension was balancing speed and stability. Moving too fast with automation sometimes caused more problems than it solved.

These challenges pushed us to focus less on tools and more on foundations: solid tests, shared ownership of quality, and clear definitions of done.

Lessons and Recommendations

Several lessons emerged from this experience.

Plan test execution carefully. A pipeline should be designed intentionally, with a clear understanding of what runs where and why.

Avoid isolated automation teams. Automation must be part of the product development process, not a separate project.

Stay close to the main technology stack whenever possible. This reduces friction and makes contributions easier.

Measure what matters. Build times, failure rates, and deployment frequency help guide decisions.

Automate with purpose. Not everything needs to be automated immediately. Start with the biggest pain points.

Results

Over time, these changes improved confidence in releases and strengthened collaboration between developers and quality engineers. Deployments became more predictable, and teams were able to focus more on delivering features instead of fighting the process.

Automation became a shared responsibility rather than a specialized function.

Final Thoughts

Continuous Delivery is not just a technical upgrade. It is a shift in mindset and culture. Tools matter, but trust, ownership, and collaboration matter more.

Every team will have its own path, but the goal remains the same: make it easier to deliver quality software to users, consistently and safely.