Introduction to OpenDevStack

When we started with the OpenShift container platform we were blown away by the 100s of possibilities to use it, but there was nothing along the lines of “This is how you make it work for your org”. What we wanted is to enable developers to quickly introduce Continous Delivery and standardized technology archetypes. We call this lean, empowered governance.

OpenDevStack (ODS) is how we achieve this. It is, to a large extent, tooling sitting in between your local software development (your machine/editor), and the running software in the target environemnt (OpenShift etc.). As such, most of ODS functionality is within and related to the CI/CD process.

ODS is comprised of core functionality, and a configurable set of so-called quickstarters. Quickstarters can be seen as software templates, which can be instantiated in your project to create a component of your application quickly, with all the integration / configuration setup out-of-the box. The officially supplied quickstarters include, but are not limited to: Java (Spring Boot), Python (Flask), Scala (Play), Go, Angular, Ionic, Jupyter, RShiny.

The core ODS functionality offers the following:

Quickstarters provide the following:

When quickstarters are provisioned through the provisioning application, a repository is created on Bitbucket for the new component. The repository is populated with the boilerplate, and immediately built and deployed via Jenkins through the ODS integration. Developers can start to work on features straight away without setting up CI/CD and integrating various services.

The following pictures the different parts ODS is made out of:

Below is a diagram detailing the flow of an OpenDevStack CI/CD pipeline:

Each major ODS release is identified by a version such as 2, 3, 4 and so on. Administrators of ODS can either:

Users of ODS simply consume the version installed by their ODS administrators.

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 although admins update the ODS installation in the cluster, users still have to explicitly 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 have 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) is, from a user perspective, an implicit update. This means that only admins have to make a change to the ODS installation in the cluster. Users should 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 (typically) 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 4, the next one will be 5.