Developer experience is essential to Lightdash because, as an open-core company, the lines between our developers/contributors/users/customers are all blurred. Contributors of today can be customers tomorrow and vice versa.
We’ve just launched two new improvements in our developer experience in the last few weeks:
Before we dive deep, we want to give shoutouts to community members André and Abert for kicking off the Helm charts repo and Jim for his mastery of GitHub actions! Thank you all!
Until last month, each release of Lightdash was a manual process that involved painstakingly changing version numbers, updating changelogs, and clicking many buttons in the GitHub UI.
But now we’re on the path to developer nirvana! Each merge to main in GitHub triggers an automatic release of Lightdash.
We’re all data nerds, so obviously we collected data before and after this change to see the impact of automating releases. Our engineering KPI is release rate (number of releases per week per engineer). Here’s how it looks before and after automation:
Boom! By releasing smaller chunks more frequently we’re able to:
It is absolutely essential that our users are able to self-host Lightdash to keep their data secure and under control. To better support our users running Lightdash in production, we’ve released our first community helm charts, which lower the barrier to installing Lightdash in Kubernetes.
As well as making it quick to setup, it’s also fast to update Lightdash and we encourage our users to subscribe to rolling updates of Lightdash. This allows us to accept bug reports from production users and roll out fixes in just 2 hours!
Once again, we’re dogfooding our own product and using our charts for managing Lightdash Cloud (our fully-managed Lightdash offering), which means it’s battle tested.
Here’s a 30 second demo showing how easy it is to get Lightdash up and running in production:
You can open an issue in GitHub, or come chat to us in #tools-lightdash in dbt’s slack.
P.S - We're hiring!