CI Enterprise Concepts
Harness CI Enterprise (CIE) simplifies the development and testing of code. In Harness Pipelines, you visually model your build and test processes as CIE Stages. Each Stage includes steps for building, testing, and pushing your code.
CIE executes steps as containers, packaging code, and dependencies in isolation from other steps. You simply specify a container to use, and Harness locates and launches the container in which the job will run. There is no longer a dependency chain to manage with Steps and Plugins running in their own containers.
This topic describes CIE concepts and provides a summary of the benefits of CIE.
In this topic:
- Before You Begin
- Visual Summary
- Harness CIE Features
- Harness CIE Components
- Try It Yourself
- See Also
Before You Begin
Before learning about Harness CIE, you should have an understanding of the following:
The following video walks you through the Harness CI Enterprise.
Harness is a leading provider of the Continuous Delivery-as-a-Service platform. Harness CIE extends this functionality with Continuous Integration-as-a-Service. Harness CIE simplifies CI Pipelines, enabling you to model stages visually, and automates all processes of building and testing software.
The architecture diagram of the Harness CIE setup is as follows:
The Harness Delegate is central to all CI processes. The Delegate is a service that runs in your environment, such as your local network, virtual private cloud, or cluster. The Delegate connects the Harness Manager to all of your code repositories, artifacts, infrastructure, and cloud providers. Above all, the Delegate is in charge of all Harness CIE operations.
The build farm has access to a VCS (Git) repository and an artifact repository to obtain dependencies for building artifacts.
The Delegate establishes outbound connections to the Harness Manager and receives CIE operations from your Pipeline to execute.
The Delegate manages the resources on your build farm that are used to run build jobs and tests. Harness receives status, logs, and metrics from the Delegate and the build farm on a regular basis. This data is used for DAG orchestration, debugging, health checks, analytics, notifications, and the generation of ML models.
Finally, the build farm saves the built docker images to the registry of your choice.
Harness CIE Features
Test Intelligence (TI) reduces test time significantly by running only the tests required to confirm the quality of the code changes that triggered the build. TI selects tests that are needed to confirm the quality of the code changes that triggered the build and ranks them in the best possible order to increase the rate of fault detection. See Test Intelligence Overview.
Harness is seamlessly integrated with other Harness modules such as Continuous Delivery, Cloud Cost Management, and Feature Flags. You no longer have to navigate from application to application to follow the steps of the Pipeline. Harness platform offers unified CI/CD Pipelines with visual controls and approval gates.
CI Enterprise uses Kubernetes to run pipeline steps as containers, making it language-agnostic. Containers are lightweight abstractions of the host operating system that can package code and dependencies independently of the steps. You can specify a container in the pipeline itself, and the agent will fetch and start the container where the job runs. Because all of the steps run in containers, and plugins have their own containers, you don't need to worry about dependencies.
Visual Pipeline Builder
Scripting Pipelines can be time-consuming and tedious. You may also be unaware of the sequence of events. It's possible that things will get worse as the Pipeline becomes more complicated. As a result, CIE provides a graphical representation of the Pipeline with nested steps. You can build directly from the UI, or you can use the YAML editor if you prefer. The YAML editor functions similarly to any other IDE. With YAML, you can easily configure it as code.
Harness Git Experience
Harness Git Experience provides seamless integration between your Harness Projects, Pipelines, and resources and your Git repos. You can work entirely from Git or use a hybrid method of Git and the Harness Manager. Harness CIE integrates with all the popular source control management tools including GitHub, GitLab, and Bitbucket. To get started, you need to activate the repository and include a
.harness folder for the configuration files. This will trigger a build within Harness CI once a commit is detected. See Git Experience.
Harness CIE Components
Harness CIE allows you to create complex pipelines by breaking them down into Stages. You can create multiple Stages by combining various CI Steps. Each Stage includes Steps for building, pushing, and testing your code. The Codebase configured in the first stage can be imported into subsequent stages. This reduces redundancy and simplifies pipeline creation. For details, see CI Stage Settings.
A Pipeline Step is defined as a series of commands used to carry out an action. For example, the Run and Run Tests step executes one or more commands on a container image. The commands are run within your git repository's root directory. All steps in your pipeline share the root of your Git repository, also known as the Workspace. In Harness CI, you can add a Step or a combination of Steps to create a Pipeline tailored to your specific requirements.
Harness CIE provides the following options as Step Library.
Shared Path in a Stage allows you to share data in the Stage. By default, all of a Stage’s Steps use the same workspace to share data. By default,
/harness is the working directory and is shared by all the steps of the stage. For example, the Maven m2 repo is stored in
/root/.m2 by default. So, you can specify the same in shared paths
/root/.m2 when using the Maven install in a later stage.
If you need to share additional volumes, you can add Shared Paths.
If you decide to split your pipeline into multiple stages, you need to make sure each stage has access to any dependencies. A typical use case for services is when your unit tests require a running Redis server. Service Dependencies are also run in an isolated container so that you need not handle the dependencies. See Configure Service Dependency.
Plugins are Docker containers that perform predefined tasks and are configured as Steps in your Stage. Plugins can be used to deploy code, publish artifacts, send notifications, and more. See Plugin Step Settings.
Caching ensures faster job execution by reusing data from previous jobs' expensive fetch operations. Using the Save Cache step in Harness CI, you can save the cache to an AWS S3 or GCS bucket and later restore it using the Restore Cache step.
Harness CIE offers popular artifactory options such as JFrog, Amazon S3, and Google GCS to which you can push your artifacts. Artifactories are set up as Pipeline Steps by using the Upload Artifacts step from the Step library.