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?
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.
When "Create Openshift Project" is checked, this will also create OpenShift projects, namely
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.
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
Major releases of OpenDevStack happen roughly every half year. Each major release is identified by a version such as
4 and so on. As a consumer of OpenDevStack, you can either:
masterto follow the cutting edge
3.x, etc. to stay on a major version, but get bug fixes (minor versions)
v3.0, etc. to pin an exact version
use a custom branch / tag such as
3.custometc. to run ODS with customizations
A major update (e.g.
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 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
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)
1.0 (November 2018, using old versioning scheme)