Continuous Delivery: releasing Better and Faster at Dashlane
2 likes1,399 views
Dashlane's continuous delivery journey aimed to enhance production speed and reliability through an automated release pipeline, transitioning from a fragile versioning system to a more robust approach using git and continuous integration tools. The team adopted rigorous code quality practices, automated testing, and tailored continuous delivery strategies for various platforms, resulting in improved collaboration and process satisfaction. Despite initial challenges, the team achieved a deployment frequency of up to twice a week for major platforms while continuously seeking improvements in their delivery metrics and processes.
Continuous Delivery: releasing Better and Faster at Dashlane
- 1. Continuous Delivery at Dashlane A path to releasing faster and better
- 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. 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. Our Goal • The ability to deliver to production, fast, reliably and on-demand, through an industrialized automated Release Pipeline.
- 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. Code • Migration to Git (Bitbucket) and review of the branching strategy for each team • Setting up a real Continuous Integration (Bamboo)
- 8. Code Quality • Mandatory Pull Requests with multiple reviewers • Code Quality Tools • Sonar, Lint,…
- 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. 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. Focusing now on Continuous Delivery • Painting the Target Release Pipeline
- 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. 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. 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. 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. CD pipeline JIRA
- 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. Aggregated metric: time to ship a commit
- 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. Questions ?
- 21. Thank you © 2017 Dashlane, Inc