DevOps Glossary

A cross-functional team has all the necessary skills to design, build, test, deliver and operate a product.

A software product must be cherished and maintained over time. Code is restructured while maintaining functionality to increase maintainability (readability, testability, clarity, ...). This activity should always be performed when needed and not just as a one-time event.

Changes are always made by 2 people (4 eyes) in order to be able to detect errors early on and build up knowledge. This can be implemented either through joint creation or downstream verification.

The implementation of the four-eyes principle by two developers working together at one workstation (one keyboard, one monitor).

Procedure for making technical design decisions in technical contexts (so-called domains). A formalised language can be used for this purpose.

New requirements are first implemented in the simplest possible version in order to quickly receive feedback from users.

A software/product design is created in the course of development by the team, only framework conditions/guidelines are given.

The technical structure of a product consists of many networked small elements (services) that interact with and among each other.

With TDD, an executable test is implemented first, followed by the actual function, and thus the test is tested immediately.

Technique to describe requirements in scenarios in the form Given (context), When (action), Then (sequence) (Gherkin syntax).
Example:
Given is a manager in a staff meeting.
When he is asked about a DevOps term,
He then looks at the KEGON DevOps poster on the wall and can immediately classify the term.

Standardised procedure/structure (template) for the development of new functionalities to produce good code.

Use proven programming guidelines (KISS, YAGNI, WET, DRY, good readability) for development.

The development artefacts are managed in only one common workspace by all, there are no more local versions (branches).

Non-functional requirements (NFRs) define system attributes such as performance, scalability and usability for products. These are (unfortunately) often omitted from the requirements.

The Continuous Integration pipeline is a collection of tools that are used to automatically generate and test a new software release after code creation.

To ensure a fast delivery of a new software product in good quality, functional and non-functional requirements are tested automatically and the result is provided automatically.

To ensure good sustainability of the newly developed code, so-called "coding standards" (development guidelines) are implemented, which are checked automatically during creation.

Static code analyses for different topics (check for architecture guideline, check for security, check for compliance) are automatically applied.

The final product acceptance (by the business) is based on previously defined and automated test scenarios.

Concept for accelerating test execution, in which unfinished, elaborate or poorly available system parts are simulated.

Approach to create a test for each new error that occurs and to always perform this test in the future to prevent recurrence.

The CD pipeline ensures that any software version of a product is automatically installed and configured on any environment and is thus provided ready to run.

To enable rapid developments and integrations as well as tests, additional environments must be able to be quickly deployed and also removed again.

Use of ready-to-use complex software products with ongoing support. Useful for rapid use in test and integration environments.

Creation of new environments including all necessary components/systems using automated scripts (code).

Developers can independently create or delete new environments, deploy a software version or load a dataset via a simple interface.

Similar to managing the software version/functionalities, the test data for environments must also be managed. Versions, compatibility with the software version used, anonymized production data, load test data generation, etc.

Release on click by Business is the activation of a functionality that was initially deactivated in production. In the best case, this should be done by a representative of the business without the involvement of IT.

The management dashboard monitors technical as well as business parameters of all active applications in different environments.

Faulty software installations are corrected with the same mechanisms as when installing a regular software version. Either a new corrected version or a previous version is used for this purpose.

Concept for providing production-ready features without making them accessible/usable for all users.

Variant of dark releases in which the new features are only made available in advance to a small and special part of the users.
Origin: Canary in a coal mine to test air quality.

A technique to enable/disable features for all users by confi guration during runtime.

Users of a certain region/country/continent are redirected to a new functionality, all others still see and use an older version.

Users of a certain group or those with special properties/rights are redirected to a new functionality, all others still see an older status.

Method for comparing the success of two versions of the same basic functionality but different design based on measured usage data.

Maintaining two identical productive infrastructures, an active one (blue) and a second one (green), on which an update or a new version is being prepared and which are then changed by a switch at an appointment, whereby green becomes blue and blue becomes the new green...

According to this motto, operation and maintenance are ensured by the developers who also developed an application or system.

To enable a shared mindset between developers and operations staff, a cross-functional DevOps team is established to handle both development and operations tasks for a product.

Often systems only monitor technical parameters, such as availability or speed. To monitor full function, business parameters (e.g. sales closures) must also be included.

Classification by which unit a support request can be solved. Typically, 3 levels are distinguished here.
Level 1: Classifying and, if necessary, re-recording tickets. Communicating known solutions and ad-hoc answers.

Level 2: Technical specialists with extended rights and powers.

Level 3: Technical specialists (often developers) elaborately analyse the tickets and respond, sometimes leading to new software versions.

ITIL process for tracking incidents and issues for users and resolving them and communicating the resolution.

All administrative changes in production are logged automatically. For this purpose, either log files are created or changes can be recognised in the configuration files via the version management.

Monitoring of the system with regard to critical system behavior and automated application of steps to rectify this. E.g. isolating nodes with unusual CPU usage, terminating long-running database queries.

A collaboration model for development and operations created by Google that has a lot in common with DevOps principles.

Agreement / contract regarding the performance quality of a technical solution (quality, availability, responsibilities), possibly combined with penalties.

Unapproved or external systems that are used productively but do not comply with internal regulations or processes and should be dismantled in the long term.