Continuous delivery and the ÔÇô Engine

Today I write about the development model Arqadium is taking with creating the ÔÇô Engine – it is one of continuous delivery and rolling release.

Background

If you look at ÔÇô’s GitHub repository, you will find something quite monolithically strung together. As we announced before on Twitter, we have relicenced ÔÇô and in the process dropped said GitHub repository, migrating to a corporate GitLab instance with a fresh codebase. In doing so, we were able to split ÔÇô into numerous modular subprojects, so that their workload can be divided and conquered more easily.

Development pipeline

We also brought in another win for teamwork by setting up a three-stage development pipeline using Git branching, which works like so:

  1. A new branch is checked out for work, prefixed with either feature/ or fix/. At most one team can work on this branch at a time.
  2. Subproject masters review the status of each feature or fix, and will squash merge them into the unstable base branch, develop.
  3. develop is committed to working towards a release milestone, and when that is met, develop is squash merged again into master. A release is made.

In ÔÇô’s development, the develop branch is the perfect candidate to use for producing snapshots in testing and QA. Each subproject is cloned, develop is checked out for each of them, and they are all built together.

Release tracks and the roadmap

We have taken a lot of cues from the technical steering committee of Node.js, fusing the fast-paced rolling release model that works so well in development with the stability-producing point-release model, using a schedule of tracks for the major point releases. Even releases will be LTS-tracked, and odd ones will be rolling.

Our plan for ramping up into those numbers is fairly simple, and it brings me to a good place to say a bit about ÔÇô’s development roadmap. As of this writing, development is in the pre-alpha stage – we are putting together the inner core components of the engine itself, and are building an intelligent system for managing ÔÇô’s development called Miles. Once Miles is up and running and we have a stub of ÔÇô to work with, we will move into Alpha 1, creating the OAM system for 2D, Lapis for state management, and the scripting system for designers to use as well. After this, Alpha 2’s development starts, where we build the Yellows 3D renderer, the Sapphire Physics engine, the editor suite, and other amenities for game developers. Once these are in working order the engine will be released in a public beta, and Arqadium will shift into gear to market and present ÔÇô worldwide.

Up until this point, the engine will be receiving releases under major version zero (0), according to the spec for semantic versioning. Once the public beta has worn its welcome and the software has been received as relatively stable, ÔÇô will move into major version 1 as a non-LTS, and the company will resume development in full force again. From here, version 2 will be ÔÇô’s first LTS release – the software at this juncture will have reached fruition.