Glossary
To help you navigate the platform more effectively, familiarize yourself with the definitions and context of the most useful platform terms presented in the table below.
| Terms | Details |
|---|---|
| Platform Component - an item used in the CI/CD process | Portal UI - component that facilitates the management, setup, and control of business entities. |
| Artifactory - component that serves as a repository for all binary artifacts. NOTE: Nexus is a possible implementation of a repository. | |
| CI/CD Server - component that executes pipelines responsible for building, testing, and deploying code. NOTE: Tekton is a possible implementation of a CI/CD server. | |
| Code Review tool - component that facilitates collaboration and review of code changes. NOTE: GitHub/GitLab is a possible implementation of a code review tool. | |
| Identity Server - an authentication server that provides a centralized way to verify requests for all applications. NOTE: Keycloak is a possible implementation of an identity server. | |
| Security Realm Tenant - a realm in the identity server (e.g., Keycloak) where user accounts and access permissions are managed. The realm is unique to the identity server instance. | |
| Static Code Analyzer - component that continuously inspects code quality before changes are merged into the master branch. NOTE: SonarQube is a possible implementation of a static code analyzer. | |
| VCS (Version Control System) - a repository that tracks all changes made by developers. NOTE: GitHub and GitLab are possible implementations of a version control system. | |
| KubeRocketCI Business Entity - a part of the CI/CD process (the integration, delivery, and deployment of any codebase changes) | Application - a codebase type that is built as the binary artifact and deployable unit with the code that is stored in VCS. As a result, the application becomes a container and can be deployed in an environment. |
| Autotests - a codebase type that inspects a product (e.g. an application set) on a Deployment Stage. Autotests are not deployed to any container and launched from the respective code repository. | |
| CD Pipeline (Continuous Delivery Pipeline) - business entity that describes the whole delivery process of the selected application set via the respective stages. The main idea of the CD pipeline is to promote the application version between the stages by applying the sequential verification (i.e. the second stage will be available if the verification on the first stage is successfully completed). NOTE: The CD pipeline can include the essential set of applications with its specific stages as well. | |
| CD Pipeline Stage - business entity that is presented as the logical gate required for the application set inspection. Every stage has one OpenShift project where the selected application set is deployed. All stages are sequential and promote applications one-by-one. | |
| Codebase - business entity that possesses a code. | |
| Codebase Branch - business entity that represents a specific version in a Git branch. Every codebase branch has a Codebase Docker Stream entity. | |
| Codebase Docker Stream - a deployable component that leads to the application build and displays that the last build was verified on the specific stage. Every CD pipeline stage accepts a set of Codebase Image Streams (cbis) that are input and output. SAMPLE: if an application1 has a master branch, the input cbis will be named as [app name]-[pipeline name]-[stage name]-[master] and the output after the passing of the DEV stage will be as follows: [app name]-[pipeline name]-[stage name]-[dev]-[verified]. | |
| Git Server - a custom resource that is responsible for integration with Version Control System (VCS), whether it is GitHub, GitLab or Gerrit. | |
| Infrastructure - a codebase type that is used to define and manage the underlying infrastructure of projects using the Infrastructure as Code (IaC) approach, ensuring consistency and reproducibility. | |
| Library - a codebase type that is built as the binary artifact, i.e. it`s stored in the Artifactory and can be uploaded by other applications, autotests or libraries. | |
| Quality Gate - business entity that represents the minimum acceptable results after the testing. Every stage has a quality gate that should be passed to promote the application. The stage quality gate can be a manual approve from a QA specialist OR a successful autotest launch. | |
| Quality Gate Type - this value defines trigger type that promotes artifacts (images) to the next environment in CD Pipeline. There are manual and automatic types of quality gates. The manual type means that the promoting process should be confirmed in Tekton. The automatic type promotes the images automatically in case there are no errors in the Allure Report. NOTE: If any of the test types is not passed, the CD pipeline will fail. | |
| Trigger Type - a value that defines a trigger type used for the CD pipeline triggering. There are manual and automatic types of triggering. The manual type means that the CD pipeline should be triggered manually. The automatic type triggers the CD pipeline automatically as soon as the Codebase Docker Stream was changed. | |
| Automated Tests - different types of automated tests that can be run on the environment for a specific stage. | |
| Build Pipeline - a Tekton pipeline that builds a corresponding codebase branch in the Codebase. | |
| Build Stage - a stage that takes place after the code has been submitted/merged to the repository of the main branch (the pull request from the feature branch is merged to the main one, the Patch set is submitted in GitHub/GitLab). | |
| Code Review Pipeline - a Tekton pipeline that inspects the code candidate in the Code Review tool, triggered on Pull Request created/updated event. | |
| Code Review Stage - a stage where code is reviewed before it goes to the main branch repository of the version control system (the commit to the feature branch is pushed, the Patch set is created in GitHub/GitLab). | |
| Deploy Pipeline - a Tekton pipeline that is responsible for the CD Pipeline Stage deployment with the full set of applications and autotests. | |
| Deployment Stage - a part of the Continuous Delivery where artifacts are being deployed to environments. | |
| CI Pipelines - an orchestrator for stages that is responsible for the common technical events, e.g. initialization, in Tekton pipeline. | |
| Environment - a part of the stage where the built and packed into an image application are deployed for further testing. It`s possible to deploy several applications to several environments (Team and Integration environments) within one stage. | |
| Integration Environment - an environment type that is always deployed as soon as the new application version is built in order to launch the integration test and promote images to the next stages. The Integration Environment can be triggered manually or in case a new image appears in the Container registry. | |
| OpenShift / Kubernetes (K8S) | ConfigMap - a resource that stores configuration data and processes the strings that do not contain sensitive information. |
| Container - is a lightweight, standalone, and executable package. | |
| Container Registry - a store for the Container that is created for the application after the Build pipeline performance. | |
| OpenShift Web Console - a web console that enables to view, manage, and change OpenShift / K8S resources using browser. | |
| Operator Framework - a deployable unit in OpenShift that is responsible for one or a set of resources and performs its life circle (adding, displaying, and provisioning). | |
| Path - a route component that helps to find a specified path (e.g. /api) at once and skip the other. | |
| Pod - the smallest deployable unit of the large microservice application that is responsible for the application launch. The pod is presented as the one launched container. When the container is collected, it will be kept in Container Registry and then saved as Pod in the OpenShift project. NOTE: The Deployment Config is responsible for the Pod push, restart, and stop processes. | |
| PV (Persistent Volume) - a cluster resource that captures the details of the storage implementation and has an independent lifecycle of any individual pod. | |
| PVC (Persistent Volume Claim) - a user request for storage that can request specific size and access mode. PV resources are consumed by PVCs. | |
| Route - a resource in OpenShift that allows getting the external access to the pushed application. | |
| Secret - an object that stores and manages all the sensitive information (e.g. passwords, tokens, and SSH keys). | |
| Service - an external connection point with Pod that is responsible for the network. A specific Service is connected to a specific Pod using labels and redirects all the requests to Pod as well. | |
| Site - a route component (link name) that is created from the indicated application name and applies automatically the project name and a wildcard DNS record. |