Shortly after the release of Rudder 4.0 in November, the development team sat down together for a retrospective of the whole release cycle. We studied what went well, less well, and downright bad, and we looked at the lessons learned. Last but not least, we picked two topics to focus on improving in the next release cycle. Now we’re reaching the end of that cycle, since Rudder 4.1 is in release candidate status – so let’s take a step back to see how we did.

Rudder development cycles

As you may know if you follow Rudder versions closely, development happens in cycles with the team working on features for each major version in turn, with a release every 3-6 months. On some occasions a cycle can be longer, in particular if a big feature or lots of features come together for a major release – that was the case this time, where the release of 4.0 came about 9 months after 3.2.

At the same time as preparing for a new release, the same team focuses on customer support and fixes bugs in existing versions that are released in regular minor updates, usually about once a month. That obviously takes some focus away from new features, and can introduce a certain amount of task juggling!

What we learnt in the 4.0 cycle

Of all the topics that came up during our retrospective, a lot of them were of course very positive, sort of “patting ourselves on the back”.

We are proud of the plethora of new features in Rudder 4.0, the web interface redesign, and a lot of the tooling improvements we’ve made (rudder-dev in particular, that now saves us a lot of time by automating all our manual actions – so much so, we gave a talk about it at Config Management Camp 2017 in Ghent).

Improvement focus for the next cycle

But of course, while those positive topics are very encouraging, our focus for improvement must be on what didn’t go so well. Of the ideas that came up to work on, several key groups emerged, and we selected the top two to be our focus for improvement during the next development cycle. Here goes!

Automated testing

Pretty much all parts of Rudder have a testing framework (ncf methods, Techniques, the REST API, the core Scala code, and of course ‘rtf’ which is designed to test whole scenarios across a Rudder setup…), but a lot of them don’t have as much test coverage as we would like.

This is partly a result of the difficulty level to add new tests, and partly due to the fact that including tests in bug fixes and new features just isn’t in our habits quite yet.

Lowering the cost to create new tests, and adding some fundamental examples is therefore high on our priority list to get this improvement kickstarted.

Transparency and visibility outside the development team

With 7 people working pretty much full time on Rudder, contributors and many advanced users providing bug reports and detailed feedback, a *lot* of discussions about ideas and features happen about Rudder. But we’re well aware that a lot of that happens in private emails, chats, or just in person. Which means that from the outside, the development team may not look that active, or at the very least isn’t sharing all these ideas and discussions very well.

We want to improve visibility into the development team’s activities, and hopefully therefore promote interest and transparency around upcoming Rudder features.

We started several new initiatives to improve on this topic:

1. We launched a Rudder development blog over on rudder-project.org. This blog will have content about new Rudder features, releases and…
2. We publish a regular “Recent weeks in Rudder” blog post, every few weeks, with a summary of main changes we’ve made, new documentation sources, any community events, and a short list of what we’re working on.
3. We’ve starting making Rudder’s Twitter account more interesting! With regular tweets about the development team’s activity, and about new and old Rudder features, we’re hoping this will provide some insight in quick bites about our focus.
4. We’ve set up and launched a knowledge base / Frequently Asked Questions site: http://faq.rudder-project.org. This will be regularly updated with answers to questions we get on the mailing list, on IRC, in private, in support requests, etc to make them available to everyone.
5. Systematically document new features as they are committed into Rudder. This provides some detailed content to explain changes before they are released, giving attentive users a chance to provide feedback and get improvements or fixes included. For example:
   1. Server event hooks
   2. Node properties expansion in Directives
   3. Using Rudder as an audit tool
   4. Node properties data sources (plugin)

What’s next?

If you’re wondering what we actually worked on in Rudder 4.1 – the features, that is! – during this past cycle, do check out this video about what’s coming next in Rudder from Configuration Management Camp 2017!

Now that Rudder 4.1’s release is just around the corner, please tell us how we’ve done. Have you noticed better visibility into Rudder’s development work, upcoming features and docs? Let us know in the comments below – it matters to us, so please be honest!

This will be the last blog post about Rudder development on this blog. Subscribe to the new Rudder development blog to make sure you don’t miss future updates!