Volker Krause: Turning users into contributors - CD in application development

Duration: 8:39 1297 transcript words EN summary

Video summary

Volker Krause discusses the transformative journey of adopting continuous delivery (CD) builds in application development, highlighting how this shift turns passive users into active contributors. Traditionally, bug reports often lagged significantly behind the actual issues because users were stuck on older Long Term Support versions while developers worked on months-old code. Even with pre-releases, fixing bugs and distributing patches could take weeks, meaning feedback loops were slow and often ineffective. By transitioning to a model where daily drivers use leading-edge CD builds, the team drastically reduced this latency; serious issues now surface within a day or two, and fixes can be deployed and verified by users in as little as fifteen minutes. This rapid cycle allows developers to push debug outputs and receive immediate diagnostics, a level of responsiveness that is impossible with standard release schedules. The core enabler for this success is the establishment of high-quality, reliable CD builds that users can trust with their data and daily workloads. This requires maintaining development branches in a continuously releasable state, ensuring that dependencies are managed correctly and regressions are addressed as top priorities. When these builds are trusted, the responsibility shifts entirely to the distributor; there is no longer an excuse to blame upstream or downstream breaks. Furthermore, effective communication becomes vital in both directions, utilizing channels like Matrix to capture not only critical bugs but also subtle user feedback regarding new features and usability improvements. To mitigate the annoyance of constantly changing software, the team has implemented infrastructure for in-app release notes with translations, providing users with clear context on what is changing while opening a direct line for them to suggest UX enhancements. To facilitate this seamless interaction between developers and users, Volker demonstrates a practical workflow using Flatpak, which allows for automatic updates without requiring root permissions or interfering with the existing system session. By creating a modified version of an application that runs alongside the official one, developers can test changes instantly on various distributions, from rolling releases to immutable systems, within just two minutes. While this approach has limitations regarding specific desktop environments like Plasma or complex framework hacking, it covers approximately eighty percent of use cases across most applications with minimal setup costs. This method effectively lowers the barrier to entry for testing and validation, allowing users who might otherwise remain casual consumers to naturally evolve into contributors. As these users gain familiarity with the development process, they often identify small issues that can be turned into merge requests, creating a virtuous cycle where the community actively participates in quality assurance without even realizing they have joined the QA team. Ultimately, the goal is to replicate this accidental success of "itinerary" elsewhere by fostering an environment where users feel excited to be part of the development process rather than just consumers of finished products. The presentation concludes with a demonstration of how easy it is to spin up a modified build and test it locally, emphasizing that such tools should not require deep system integration or administrative privileges. Volker invites the audience to provide feedback on whether this approach should be further explored, suggesting that by making development accessible and safe for daily use, organizations can cultivate a robust community of contributors who help flush out distribution problems before they reach production. This strategy not only accelerates bug resolution but also enriches the software ecosystem by leveraging the collective intelligence and immediate engagement of its user base.

Read the full video transcript

Okay, now. Okay, so I want to talk a bit about the experiences we made on our journey way with using continuous delivery CD builds. Um Many of you might share those experiences right so if you get bug reports um they are often for something we worked on months ago and that is the best case right people actually using the latest release not some some LTS version. Um and we we do have pre-releases betas and release candidates. Um and they help to flush out some distribution problems but they aren't really widely tested so um when it comes to to testing anything before the production release right you are mostly on your own. Uh and if you make fixes uh it takes again in the best case weeks until they make it to the person who actually had that problem so the chances that you ever get a feedback that this actually fixed the problem uh relatively slim. Um this changed a lot for us in our journey way when we got a whole bunch of people to daily drive leading edge CD builds. Um because now if we have um serious issue it takes a day or two until um people start screaming. Um so basically you get the bug reports for the stuff you are currently still working on. Um and same in the other direction. Um so if I push a fix within 15 minutes the person who reported that problem has the fixed version on their device and can confirm that I actually fixed the problem. Um and if I didn't I cannot even do stuff like um push some debug output and within minutes I get diagnostics from the affected person or the affected device, right? Um that would simply be impossible with uh waiting for regular releases. Um and as a side effect of that, the people daily driving the CD builds have basically stopped being normal users, they have become contributors and are now part of the QA team. Um I mean for itinerary this kind of happened by accident, um but there is still uh a few things I think we can uh can learn from this and trying to to replicate it elsewhere. Uh so the first and probably most important thing is we really need high-quality and reliable CD builds for this. Um And so this needs to be in a state that people trust it with their data and can rely on it uh to actually get um get their work done. Um So this this basically means your um your your development branch needs to be in a uh continuously releasable state, but since most of us use time-based releases, that's a good idea anyway, right? Um and that's also where all the stuff fits in that Pushan and and Nico talked about earlier. Um It also means that um for the CD builds you are the distributor, right? So there is no longer upstream broken or downstream broken as an excuse. If any of that happens, and it will happen, it's your responsible uh responsibility to take care of it. So it's a good idea to understand the how the the whole CD pipeline works and how you can pin a dependency or patch a dependency and and do things like this. Uh and whenever there is a regression, right? That has to be the priority to to address this. Um the second important part is um communication. And that goes in in both directions. So for itinerary, we have a lot of the daily driving users on on Matrix. So that's the the channel you want to closely watch um not just for the serious issues. Um there's also a lot of more subtle between the line feedback then. Um like people asking how to use a a new feature for example, right? That gives you some tells on how you might be able to improve the the UX. Again, for something you're currently working on, right? Um and then for the other direction, um I mean, using software that constantly changes, right? Is can be kind of annoying. And you can mitigate that to some extent by actually telling people what you're changing. Uh since a few releases in frameworks, we have infrastructure for in-app release notes um that are based on upstream. So they have uh translations and all of that uh for free. Um Carl added standardized UI components for this 2 days ago or so. Um so that's that's a new channel we are getting for this. Of course, any other communication channel also helps. Um and then the third part, if you have a packaging system that does automatic updates like we have for Android, um that helps a lot. Uh for Flatpak, I think it's a bit of a mixed situation. Uh for the other platforms, we don't have that yet. Um Right. And then, as I said, we have a bunch of people that have become contributors without even realizing this. Um they have have gotten in touch with the community and they are starting to experience the excitement of being part of this. So they're good candidates to pull them in uh even deeper. And they might find something small that is a good first merge request candidate, right? So, in order to test this, we ask them to install a whole bunch of um packages that a distro might or might not have, and then build 200 modules, and maybe break their session on the way. Um that's not great, right? Um but I think we can do better. And that's what I'm going to show you now. So, this is a vanilla off-the-shelf alligator. The only thing I have modified here is a small patch in Kirigami add-ons, adding this uh new action in the about screen here. And then a small local UI handler. Um if I click on this, I'm asked whether I want Oh, where to I want to clone the repository if I haven't done this yet. Um and I hope the network works. And never mind that this is GNOME Builder, right? This is just to demonstrate the workflow, um because none of our tools can do this that nicely yet. Um so, and and let me do a small change here. And then let's quickly build and run this. And I mean, as you can probably guess, this is all based uh based on Flatpak. Right? So, it doesn't matter if I'm on the latest rolling release distro or some immutable Debian old stable, as long as it can do Flatpak, right? This this will work. Uh I don't need to install anything on the system. Um I don't need root permissions. There is no risk of interfering with my existing session. Um it it's going to give me a a second version modified running alongside the other one within 2 minutes or so. Um and yes, I mean it's flatpak, so it will have all kinds of limitations, right? So, it's not going to work for plasma. It's not going to work for frameworks hacking. Um and a whole bunch of other special cases. But I would say for 80% of the things we do on 80% of the applications, that is more than sufficient. Um and it has basically no sunken setup cost, right? So, if I need the the full thing, I can easily do that um whenever I want. Um yeah, so that's basically what I wanted to show you. Um I would be very interested to hear your feedback over the next days on whether that's an approach that we should uh look into further. Um yep. Thank you.