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. | |
| Deployment Flow (Continuous Delivery Pipeline) - business entity that describes the whole delivery process of the selected application set via the respective environments. The main idea of the CD pipeline is to promote the application version between the environments by applying the sequential verification (i.e. the second environment will be available if the verification on the first environment is successfully completed). NOTE: The Deployment Flow can include the essential set of applications with its specific environments as well. | |
| Environment - a logical entity that facilitates the inspection of application sets. Each environment is linked to a distinct Kubernetes namespace dedicated to containerized workloads, ensuring a one-to-one mapping between the environment and the namespace. This structure allows for the sequential promotion of applications from one environment to the next. | |
| 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 Image Stream - serves as a key component in managing the deployment lifecycle of an application version. It facilitates the identification and progression of application versions that are ready for deployment. Within the Deployment Flow, each environment leverages Codebase Image Streams (CBIS) to manage application versions effectively. For instance, an application named 'application1' associated with a master branch would be initially tagged in the CBIS using the format: [codebase name]-[branch name], e.g., 'application1-main'. As the application version progresses through the Deployment Flow, reaching readiness for deployment in a specific environment, the CBIS naming convention evolves to indicate its deployment flow and target environment, following the structure: [deployment flow name]-[environment name]-[codebase name]-verified. This approach ensures a clear and systematic tracking of application versions from their initial identification through to their readiness for deployment in various environments within the deployment pipeline. | |
| 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 environment has a quality gate that should be passed to promote the application. The environment 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 a deployment flow. 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 deploy 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 deployment flow for a specific environment. | |
| 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. | |
| Environment - a part of the Continuous Delivery where artifacts are being deployed to. | |
| CI Pipelines - an orchestrator for stages that is responsible for the common technical events, e.g. initialization, in Tekton pipeline. | |
| Environment - a namespace where the built and packed into an image applications are deployed for further testing. It is possible to deploy several applications to several environments (Team and Integration environments) within one deployment flow. | |
| 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 environments. 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. |