The Evolution of Kolab Development

In the past, even before I joined the Kolab community, our product was released on a feature-based schedule. We’ve changed that to time-based releases, with an aim to be able to provide something new every 6 months or so. We’re now changing it again, but not in the way you might think.

Not too long ago, software was developed, tagged, branched, released, tested, fixed, patched, packaged and deployed, not necessarily all of them in that order, at whichever pace the project set for itself, then distributors would pick it up, then environments would install it — often under the guidance of road-maps and milestones with the final result in mind (the “waterfall” methodology), upgrade paths and support life-cycles.

Today, we’re seeing more and more software that does not actually get released, ever, is perpetually in motion, and shows weekly or even daily incremental progress. A common methodology used here is the agile methodology which, in contrast to the waterfall approach, is an iterative process and rarely ever leads to a final result.

The way this works is by regularly gathering the stakeholders to look at actual, functioning software at the end of an iteration (a “sprint” in Scrum), and take in feedback. This meeting at the end of a sprint is called a retrospective in Scrum.

Sprints are time-boxed efforts to achieve a number of goals set out at the beginning of each sprint. The larger the window of time in which the effort is boxed, the more incremental changes will have been made, and the more difficult it becomes to genuinely facilitate agility.

And this is where the evolution of Kolab development kicks off.

You can imagine that the delivery of software on a daily or even just a weekly basis can amount to quite an effort, but the delivery of the software is a prerequisite for the retrospective. To facilitate the delivery, a few major aspects need to be taken in to account. In no particular order;

1. Packaging

Packaging the software solely for the sake of delivery in time for a retrospective doesn’t make sense, let alone packaging the software in such way that would be acceptable for inclusion in to distributor’s stock software repositories.

If you want to know more about why or how it doesn’t, please leave a comment so I know to write another blog post on just that subject.

2. Delivery

The retrospective intends to use whatever means necessary to be able to show off functioning software — as such it has little to do with delivery to market, nor the ability to install a package is therefore a void requirement.

A priori, you need to prioritize delivery of git master efficiently and effectively, not to say continuously, and not to say automatically.

3. Constraints

The development team participating in a sprint cannot be held back by arbitrary constraints, for they will be labelled “inhibitors” — negatively impacting the team’s “velocity” (ability to deliver, if you will).

This includes constraints such as the version of PHP or NodeJS that is available on a target platform. In fact, the entire concept of maintaining a target platform is out the window. However, you can set constraints on lower-level system abilities — the version of glibc or C come to mind. It usually does pay off to set a reference platform for implementation.

With Kolab, we have set such reference platform for implementation. Not only did we do that, we also set a reference implementation for the features and environment topology — a single server deployment aka. localhost.localdomain.

4. Software Development Process

To be absolutely clear on the implementation of specifications outlined in requirements, so that the implementation of software and expectation about delivered functionality is on par, to ensure a development team is provided with sufficiently descriptive architecture and design documentation, use-cases, test-cases, mock-ups and work-flow definitions (user stories), to increase the certainty and confidence at the point of delivery and to avoid the need to fix things just in time for a retrospective to take place, you will want to make sure that what is put in to git master during the sprint is tested.

This spells out a need for a test-driven development process, and mandatory (peer) code review. Before a retrospective takes place, the developments are reviewed (having been verified through continuous integration), and merged and become a line-item on the list of “things to show off” during the retrospective.

5. Containers

Docker containers offer a great opportunity to not only install software that is not packaged, but apply a series of operations and fix gotchas and configure ahead of distribution, while allowing for a certain degree of variety in where the image actually gets run — because the ability to distribute to a wider audience is inherited.

In the case of Kolab, orchestration allows for many moving parts to move in parallel, and hence we’re interested in using containers to address the “works on my system” syndrome, allow vendorizing massive chunks of code as part of a continuous delivery scheme, and increase participation because everyone can run the results of the latest iteration almost immediately.

Advertisement