Introduction to OpenDevStack

What is 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?

  • Everyting you need for CI infrastructure (Jenkins images, SonarQube, Nexus).

  • Ansible playbooks to install the Atlassian suite (Jira, Bitbucket, Confluence, Crowd).

  • A shared jenkins library that harmonizes the way you build, test, govern and deploy.

  • A set of technology quickstarters that provide complete CI/CD integration, w/o anything to worry about for the engineer.

  • A small provisioning application that gives you one place to start, no matter if you want to start a new project, or enhance an existing one with a quickstarter.

Using OpenDevStack

Create a new project

Trigger project creation through the provisioning application to get a new project. The web GUI of the provisioning app is located at https://prov-app-ods.example.com.

When "Create Openshift Project" is checked, this will also create OpenShift projects, namely <project-key>-dev and <project-key>-test. A Jenkins deployment will be created in the <project-key>-cd project to allow each project full freedom of build management. This deployment is based on a common Jenkins image from the central ODS namespace.

Create a new component within a project (using a quickstarter)

Open the web GUI of the provisioning app https://prov-app-ods.example.com. Select your project, then choose a quickstarter. If no framework fits to your needs, choose the docker-plain quickstarter.

After provisioning the quickstarter, you’ll have a new repository in your BitBucket project with the boilerplate of the component. From that, a Jenkins job is triggered automatically (via a webhook setup in Bitbucket) which builds and deploys the boilerplate application into the <project-key>-dev project.

Parts of OpenDevStack

OpenDevStackParts

Journey: From Commit To Deployment

OpenDevStack Journey From Commit to Deployment

Versioning

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:

  • point to master to follow the cutting edge

  • point to 2.x, 3.x, etc. to stay on a major version, but get bug fixes (minor versions)

  • point to v2.0, v3.0, etc. to pin an exact version

  • use a custom branch / tag such as 2.acme or 3.custom etc. to run ODS with customizations

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.

Roadmap

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

3 (to be released July 2020)

  • Rename central namespace to ODS, and extend with running provisioning app

  • Install provisioning app and document generation service from pre-built images

  • Quickstarter pipeline

  • Merge of MRO (now: orchestration pipeline) into general shared pipeline

  • Automation of SonarQube and Nexus setup

  • Decorate Bitbucket pull requests with SonarQube analysis

  • Promote images between environments if possible (instead of rebuilding)

  • New (single page) app user interface as optional feature

2 (December 2019)

  • Removal of Rundeck (replace with Jenkins jobs)

  • New quickstarter concept (multiple repo support)

  • Project specific technical users

  • CPU and memory quota support

1.2 (October 2019, using old versioning scheme)

Initial version of document generation service and MRO pipeline

1.1 (June 2019, using old versioning scheme)

Incremental improvements.

1.0 (November 2018, using old versioning scheme)

Initial release.