OpenShift / PaaS

OpenShift DevOps Concepts

Glossary of Terms

Some concepts relevant to role of the OpenShift in the context of DevOps enablement are summarised here. These are not intended as formal Industry standard definitions. Instead, these are a point of view as interpreted through the lens of a container management centric approach to automation. This section is another in the OpenShift Minilabs series.



Aligning the constituents in the software delivery process to a common goal of value delivery. And its not just Developers and Operators, but InfoSec and Quality Assurance functions and more. Recognising that wealth is created when the work product is valued by actors external to the production system. Value delivery outcomes measured by metrics tied to production delivery velocity, quality and waste. DevOps emphasises behavioural or cultural related changes such as those which encourage teaming, inclusion, feedback and experimentation. Technological interventions such as automation are central as they can reinforce such target behaviours. DevOps does not necessarily imply functional roles in software delivery such as development, quality assurance or operations are merged. More important is that a professional respect and shared sensibility is formed across the delivery team.


The runtime representation of a packaging format based on a lightweight, immutable image. Runtime dependencies are resolved within the image which facilitates portability. This makes possible the agreement on a standardised software work product. Management and runtime tooling that is container aware can then be applied consistently no matter what the underlying technology stack. Container based workloads are suitable for multi-tenancy on a single compute instance and so when implemented securely can realise significant operation efficiencies. An important corollary is that launching a new workload does not incur the cost of provisioning new compute infrastructure. This enables a true on-demand, self-service experience for users.


Concerns the lifecycle management of container workloads including functions such as to schedule, stop, start, replicate across a cluster of machines. Compute resources for running workloads are abstracted allowing the host infrastructure to treated as a single logical deployment target. Kubernetes is an open source community project addressing container orchestration. It groups containers that make up an application into logical units for easy management and discovery and features self-healing, service discovery, load-balancing and storage services among its rich feature set. Orchestration plays a critical role in our design goal of application-centricity as quality-of-service attributes and deployments pattern are executed by invoking kubernetes API primitives.

CI – Continuous Integration

Concerns the integration of code from potentially multiple authors into a shared source code management (SCM) repository. Such check-ins could occur many times a day and automation steps in such a process could include gates or controls to expose any issues as early as possible. SCMs such as git include workflow support to commit to trunk, push and merge code pull requests from multiple developers. With containers, a git push event could be configured to then trigger an image build event via the webhooks mechanism.

CD – Continuous Delivery

Once a CI strategy is in place, consideration can then move to achieving CD. This involves automating the steps that required to promote the work product from one environment to the next within the defined software life cycle (SLC). Such steps could include automated testing, smoke, unit, functional, and static code analysis and static dependency checks for known security vulnerabilities. With containers, promotion in later stages of the SLC may merely involve the tagging of the (immutable) image to mark acceptance. Binary promotions are also possible such that only the image is pushed (to the target registry of the new environment), leaving source code in-situ.

CD’ – Continuous Deployment

By convention, we can denote the special case of continuous delivery to production as “continuous deployment”. We make such a distinction because such deployments may be subject to additional governance processes, e.g. deliberate human intervention to mange risk and complete sign off procedures.

CS – Continuous Security

[ Coming Soon ]


Pipelines are a representation of the flow/automation in a CI/CD process. Typically a pipeline might call out discrete steps in the software delivery process and present them visually or via a high level scripting language so the flow can be manipulated. The steps might include build, unit tests, acceptance tests, packaging, documentation, reporting and deployment and verification phases. Well designed pipelines help deliver better quality code faster by enabling participants in the software deliver process to more easily diagnose and respond to feedback.

CM – Software Configuration Management

For our purposes we will take a narrower view of CM and focus on the recommended software engineering practice of separating dynamic configuration from static runtime software. Doing so allow developers and operations engineers to change the configuration without having to rebuild the runtime such as might occur when deploying to different environments. Containers, based as they are on immutable images, amplifies this behaviour as the alternate would be configuration layered across multiple images for each deployment scenario.

Deployment Patterns

Aligned with the goal of automation across all steps in the software delivery life cycle, are patterns for deployment. We look here for strategies that can balance across criteria including safety, testability, reversibility and downtime minimisation in cloud-scale scenarios. Some deployment patterns also offer opportunities for capturing and responding to feedback. An A/B Deployment allows for testing of an hypothesis such as which of application versions A or B is more effective. Usages results can then drive weighted load balancing across the alternatives. Automation of deployment strategies in this DevOps world are implemented by driving the orchestration APIs.

CI’ – Continuous Improvement

Let’s close off this topic with continuous improvement which should be the thread that connects all of the process improvement related practices summarised. The environment changes and so must we. These practices make it easy and cheap to experiment, formulate and test hypotheses, experiment and capture and action feedback. This way we can continue to inject energy into the system and so maintain a state of dynamic stability – a balance of adaptive/agile versus fixed/stable.



2 thoughts on “OpenShift DevOps Concepts

  1. Pingback: OpenShift DevOps Tutorial | emergile

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s