Aegir5 Roadmap

Aegir5 is pre-alpha softare

Under open development at https://gitlab.com/aegir/aegir.

This roadmap will be regularly updated as we iterate, to reflect current progress and status.

We are currently in pre-alpha development stage. Having prototyped the basic architectural pieces to prove its utility, we are currently focused on solidifying an initial foundation, so that we can better enable the existing Aegir community to participate in the project.

Upcoming milestones

As of May 2023, we’ve re-imagined our Milestones in terms of an MVP we can launch back into the Aegir dev community and beyond. We’ve broken MVP up into an Alpha and Beta stage.

In Alpha, the focus is on anything that’s useful to external developers who want to help with the project. We want a minimal prototype that integrates our Kubernetes backend with the familiar Drupal Frontend administration UI. We also need to document and clean things up enough that the project is accessible to interested participants.

Snapshot of Aegir 5 MVP Alpha sprint boards

In Beta, we hope to have more feedback on our Aegir5 Roadmapping blog series, which lays out the trajectory we foresee from here.

post-MVP

The focus after the MVP launch will be to get us back to feature parity with Aegir3 core as it stands today. This is specifically just the bare bones of CRUD operations on D8+ sites (probably not even D7 support initially), in order that we can begin to use it in real environments, and thus inform where to direct further development efforts.

  • Basic Drupal 8+ support comparable to Aegir3.
  • Better security by default.
  • Feature-complete ready for regular use

In more detail:

  • Focus on D8+ as the primary application to deploy, and aim for feature parity with the Ops-focused workflows that Aegir3 does very well for Drupal 7, 8, and 9 today.

    • Create Codebases (traditionally called “platforms” in Aegir), provisioning them on one or more Servers (later containers) which have the Services to run them.
    • Create Site instances on top of those Codebases, which represent a particular install at a specific URL.
    • Automated and manual backups of Sites and Codebases, to designated Server(s).
    • Reliable restoration of backup data, to spin up a copy of a Site at a point in time.
    • Migrate Site instances between Servers and Codebases (even Services, e.g. MySQL to MariaDB), with blue-green deploy, automatic backups and rollback.
    • HTTPS, different Webservers, etc.

  • Currently, if we verify a codebase, we scan for profiles, pick up .info files, post those back to the front-end. This creates profile “entity” on the frontend as an optional available to site-installs, etc.

    • This is application specific: D7 is different than D8+
    • In D8+ we will probably use the composer.lock in a similar way
    • In general there should be an abstract form of this “set of packages” a Codebase has installed, that arbitrary applications (Wordpress, Grav) can define in their own terms.

  • Stabilizing, improving performance, etc.

  • For the adventurous :)

  • Figure out what packaging looks like. However it gets deployed should be automated as much as possible with any .deb, .rpm, Snap/Flatpak etc. for distribution. Must be automated on release. Eliminate the current day-long release cycle.

    • Currently this is painful: multiple projects, specific order, build scripts, and tests that can break things.
    • Our pipeline: Tag it, forget it, and then the release is out. Then we can do minor point releases regularly, fearlessly.
    • Ideally we’d be doing this by the time we tag RCs.

Historical Trajectory