The next big things, 2017 edition.

Along with several people on the Fedora Engineering team, I recently attended the DevConf.cz 2017 event. The conference has grown into an amazingly successful gathering of open source developers. Most attendees live in Europe but there were some from every continent. The coverage spanned all the big open source buzz-generating technologies. Session topics included containers, PaaS, orchestration and automation, and DevOps.

One of the most frequent topics I heard at and around the conference was CI — continuous integration. The idea of CI isn’t new in and of itself. Many open source projects put it to use already. If you do any work on Github, you’ve already seen it at work. (Also notably, OpenStack features one of the biggest and arguably most successful at-scale efforts.) However, it hasn’t taken strong root in Fedora, yet.

Based on the discussions I had and heard at DevConf.cz, that’s likely to change soon. Why? Well, for one thing, Fedora still breaks too often. This is especially (but not exclusively) true about Rawhide. But in many cases, we can easily understand these breakages. That means we can detect and prevent them before they occur. While update testing in Bodhi helps in the case of stable releases, that’s not a cure-all. That process still depends heavily on manual efforts that aren’t guaranteed. Moreover, those efforts form a gate of several days at a minimum, between building, karma, and tagging. This process no longer scales with new, fast-moving deliverables like Fedora’s edition of the Atomic Host. One size no longer fits all. We need a more flexible, automated approach.

What does that mean? For Fedora, the CI concept means gating on automated tests that guarantee some level of validity to a change. These tests are run prior to introducing changes into a tree, ostree, module, container, etc. That way, we don’t pass breakage on to the consumer.  But we can message that breakage back to the maintainer directly. The maintainer then quickly acts to fix the issues. And they see more immediate results from their fix.

We must do some work in the Fedora infrastructure to make this process work for Fedora contributors (maintainers especially). Some app work is also required to support our packaging and deliverables. We must make sure it’s easy for people to contribute to tests. Maintainers need to easily understand the status of their build requests. And of course the community must be able to continue contributing to higher levels of testing that make for a better Fedora. So CI isn’t the end of the story. It’s just another strong link in a chain of improvements.

Fortunately, we’re well situated to do great work here. For instance, the Fedora Infrastructure team already plans to front our dist-git package control with Pagure. (You probably know Pagure is a full-featured collaborative git forge.) This ensures the Fedora dist-git acts as a source for CI, tested with each new proposed change. But we believe this is unlikely to cause more complexity. Packagers can expect to use tools they already know. Furthermore, they could use the popular, effective pull request model to maintain packages and develop testing. This lowers the bar to contribution while maintaining high quality.

Another point in our favor is the entire Fedora application infrastructure has been running on the fedmsg messaging bus for years. We already can orchestrate and coordinate a huge number of automated activities around events involving our apps. Therefore a higher level of continuous integration and testing is well within our grasp.

Of course, this blog post is light on details. (What else would you expect from a manager?) ? Those details are obviously important. As the least technical person in the Fedora Engineering team, though, I’m the last person you’d want to describe them in detail. But the folks in the Infrastructure community team will be launching a series of discussions on the mailing list to explore those details.

We’re all passionate about making Fedora better. So hearing feedback from our contributors and colleagues at DevConf.cz has us very excited and enthusiastic about this next level. I encourage you to get involved and contribute constructively to the discussions!