Key concepts
Before you begin using Harness modules, you should be familiar with the key concepts.
Account
A Harness account is the top-level entity under which everything is organized.
Within an account you have organizations, and within organizations you have projects. You can add resources at the account level, and also at the organization and project levels.
All organizations and projects in the account can use the account's resources.
All projects in the organization can use the org's resources.
Why is this great? Each team can manage its resources within its project and not have to bother account admins every time they want to add a Connector or a secret. Projects make teams independent. This is part of Harness' democratization goals for developers.
Organizations and projects
Harness Organizations (Orgs) allow you to group projects that share the same goal. For example, all projects for a business unit or division.
Within each org you can add several Harness Projects.
A Harness Project contains Harness pipelines, users, and resources that share the same goal. For example, a project could represent a business unit, division, or simply a development project for an app.
Think of projects as a common space for managing teams working on similar technologies. A space where the team can work independently and not need to bother account admins or even org admins when new entities like connectors, delegates, or secrets are needed.
Much like account-level roles, project members can be assigned Project Admin, Member, and Viewer roles.
Project users have at least view access to all configuration and runtime data of a project and share the same assets (environments, services, infrastructure, etc).
See Projects and Organizations.
Product modules
Your project can add Harness products as modules, such as Continuous Integration or Continuous Delivery.
Pipelines
Typically, a pipeline is an end-to-end process that delivers a new version of your software. But a pipeline can be much more: a pipeline can be a cyclical process that includes integration, delivery, operations, testing, deployment, real-time changes, and monitoring.
For example, a pipeline can use the CI module to build, test, and push code, and then a CD module to deploy the artifact to your production infrastructure.
Pipeline Studio
You build pipelines in Pipeline Studio.
You can create pipelines visually or using code, and switch back and forth as needed.
| Visual | YAML |
 |  |
For more information about YAML in Harness, go to the Harness YAML overview.
Pipeline Studio guides you in setting up and running your pipelines with ready-to-use steps.
Stages
A stage is a subset of a pipeline that contains the logic to perform one major segment of the pipeline process. Stages are based on the different milestones of your pipeline, such as building, approving, and delivering.
Some stages, like a deploy stage, use strategies that automatically add the necessary steps.
See Add a Stage.
Steps and step groups
A step is an individual operation in a stage.
Steps can be run in sequential and parallel order.
A step group is a collection of steps that share the same logic such as the same rollback strategy.
See Run Steps in a Step Group.
Services
A service represents your microservices and other workloads logically.
A service is a logical entity to be deployed, monitored, or changed independently.
Service instance
Service instances represent the dynamic instantiation of a service you deploy via Harness.
For example, for a service representing a Docker image, service instances are the number of pods running with the Docker image.
Service definitions
When a service is added to the stage in a pipeline, you define its service definition. Service definitions represent the real artifacts, manifests, and variables of a service. They are the actual files and variable values.
You can also propagate and override a service in subsequent stages by selecting its name in that stage's service settings.
See Monitor Deployments and Services in CD Dashboards.
Environments
Environments represent your deployment targets logically (QA, Prod, etc). You can add the same environment to as many stages as you need.
Infrastructure definition
Infrastructure definitions represent an environment's infrastructure physically. They are the actual clusters, hosts, etc.
Connectors
Connectors contain the information necessary to integrate and work with 3rd party tools.
Harness uses connectors at pipeline runtime to authenticate and perform operations with a third-party tool.
For example, a GitHub connector authenticates with a GitHub account and repo and fetches files as part of a build or deploy stage in a pipeline.
See Connectors How-tos.
Secrets management
Harness includes built-in secrets management to store your encrypted secrets, such as access keys, and use them in your Harness account. Harness integrates with all popular secrets managers.
See Harness Secrets Management Overview.
YAML and Git
You can sync your Harness account, orgs, and projects with your Git repo to manage Harness entirely from Git.
Harness can respond to Git events to trigger pipelines and pass in event data.
See Harness Git Experience Overview.
Deployments
Deployments are the process of taking artifacts (microservices, functions, workloads, etc.) that have been developed and making them available for use in a test or production environment.
Deployments release the application or software so that it can be accessed by users or other systems. Deployment can be done manually or automated using triggers.
Deployments are modeled in the Harness pipeline using Harness services (what you will deploy), environments (where you will deploy), and execution steps (how you will deploy).
See Deployment concepts and strategies and Deploy services on different platforms.
GitOps
Harness provides full GitOps functionality.
GitOps is a specific approach to managing and automating the deployment and management of infrastructure and applications using version control systems, primarily Git.
In GitOps, the desired state of the infrastructure and applications is defined and stored in a Git repository as code (usually YAML files). Harness automation tools (Agents) then continuously monitor the Git repository for changes and automatically synchronize the actual state of the infrastructure and applications with the desired state.
Why are Deployments and GitOps different
In Harness, Deployments refers to executed pipelines. GitOps can leverage pipelines, but you don't need a pipeline to perform GitOps. In GitOps, changes to the target infrastructure and applications are managed via Git files and Agents.
This difference is why you see Deployments and GitOps separated in the Harness UI.
Deployment is a broader concept that encompasses the process of releasing software into production, while GitOps is a specific methodology that leverages Git repositories to manage and automate the deployment and configuration of infrastructure and applications.
Recap
What you've seen is how Harness integrates with your resources and tools, and how you can build pipelines.
Harness helps you to model any kind of software development and delivery process in minutes.
It allows for flexibility while making best practices easy to follow and poor practices difficult to implement.
Most importantly, it takes away the pain points of software development, delivery, verification, etc, and gives you confidence in their management and success.
What's next? Sign up for Harness and then try a quickstart.