Introduction to OpenDevStack

When we started with RedHat’s OpenShift we were blown away by the 100s of possibilities to use it, but there was not anything along the lines of "This is how you make it work for your org". Its catalog provides items for almost everything - yet what we wanted is to enable people to quickly introduce Continous Delivery and standardized technology archetypes. We call this lean, empowered governance.

So what does OpenDevStack provide?

Major releases of OpenDevStack happen roughly every half year. Each major release is identified by a version such as 2, 3, 4 and so on. As a consumer of OpenDevStack, you can either:

A major update (e.g. 2.x to 3.x or 3.x to 4.x) is, from a user perspective, an explicit update. This means that even if admins update the ODS installation in the cluster, users still have to adopt that change (e.g. by updating their Jenkins image reference and so on). Therefore, a major version change is accompanied by an update guide like Update to 3.x. For admins, a major update might mean that configuration options have to be changed or migration steps to be taken, as well as rebuilding and rolling out all images etc.

A minor update (consuming changes/bugfixs on a release branch such as 3.x). From a user perspective, this is an implicit update. This means that only admins have to make a change to the ODS installation in the cluster. Users must get those changes automatically, without the need to explicitly adopt it. Therefore, there is no update guide for minor updates. For admins, a minor update should not require changing configuration options nor performing migration steps - only rebuilding and rolling out some (or all) images should be needed.

Each version is tracked as a GitHub project. The current major version is 3, the next one will be 4.