Harness | Feature Flag

1. A feature flag (also called a feature toggle) is a conditional switch in code.

Instead of deploying new code to enable a feature, you wrap the feature with a flag:

if (featureFlagService.isEnabled("new-checkout")) {
    showNewCheckout();
} else {
    showOldCheckout();
}

The flag value is controlled remotely from Harness.

---

2. Basic Flow

Typical lifecycle:

1. Create flag in Harness
2. Add SDK to your application
3. Evaluate the flag in code
4. Control rollout from the dashboard
5. Target users or environments

Harness Dashboard
        ↓
Feature Flag Service
        ↓
Application SDK
        ↓
Feature Enabled / Disabled

---

3. Step-by-Step Implementation

Step 1: Create a Feature Flag

In Harness:

1. Go to Feature Flags module
2. Click Create Feature Flag
3. Choose flag type:
• Boolean
• String
• Number
4. Name it:
   new-checkout-ui

Enable it for specific environments like:

• dev
• staging
• production

---

Step 2: Add Harness SDK

Install the SDK in your app.

Example: Java

<dependency>
  <groupId>io.harness</groupId>
  <artifactId>ff-java-server-sdk</artifactId>
</dependency>

Initialize SDK:

CfClient client = new CfClient("YOUR_API_KEY");

---

Step 3: Evaluate the Flag in Code

Create a user context:

Target target = Target.builder()
    .identifier("user123")
    .name("Test User")
    .build();

Check the flag:

boolean enabled = client.boolVariation(
    "new-checkout-ui",
    target,
    false
);

if(enabled){
   showNewCheckout();
}

---

4. Targeting Specific Users

Harness allows rule-based targeting.

Examples:

Enable feature only for:

• specific users
• user segments
• percentage rollout
• environments

Example targeting rule:

Email ends with @company.com → Feature ON
Others → OFF

---

5. Progressive Rollout (Most Common Use)

Instead of enabling for everyone:

Phase	Users
Phase 1	Internal team
Phase 2	5% users
Phase 3	25% users
Phase 4	100%

This reduces risk if something breaks.

---

6. Kill Switch (Critical Use Case)

If production breaks:

Just disable the flag in Harness UI.

No redeploy required.

Feature Flag → OFF
Application automatically disables feature

---

7. Environment Control

You can manage flags per environment:

Environment	Status
Dev	ON
QA	ON
Prod	OFF

This helps test features safely before release.

---

8. Best Practices

1. Use meaningful names

Good:

checkout_new_ui

Bad:

flag123

---

2. Remove flags after rollout

Once feature is stable:

• delete flag
• remove conditional code

Otherwise tech debt increases.

---

3. Use flags for risky features

Great for:

• new UI
• payment systems
• new algorithms
• large backend changes

---

9. Real Production Example

Example:

You deploy new recommendation algorithm.

Steps:

1. Deploy code with feature flag
2. Enable for 5% users
3. Monitor metrics
4. Increase to 50%
5. Finally 100%

If metrics drop → disable instantly.

---

In short:
Harness feature flags allow safe releases, gradual rollouts, instant rollback, and user targeting without redeploying applications.

Harness | You Should Know These Concepts

Harness is a modern CI/CD and DevOps platform that automates software delivery using AI/ML-driven deployment verification, continuous integration, continuous delivery, and cloud cost management.

Key features

1. Continuous Integration (CI)
2. Continuous Delivery (CD)
3. Feature Flags
4. Cloud Cost Management
5. Security Testing Orchestration
6. GitOps support
7. Automated Rollback using ML verification

Example:

Harness is a software delivery platform that automates CI/CD pipelines and uses machine learning for automated verification and rollback of deployments. It supports multiple deployment strategies such as canary, blue-green, and rolling deployments.

---

Core modules in Harness -

Important Harness modules include:

Module	Purpose
CI	Build and test automation
CD	Deployment automation
Feature Flags	Release features gradually
Cloud Cost Management	Optimize cloud spending
STO	Security testing orchestration
GitOps	Kubernetes Git-based deployment

---

Harness Pipeline -

A pipeline in Harness is a series of automated steps used to build, test, and deploy applications.

Components

• Stages
• Steps
• Triggers
• Approvals
• Rollback steps

Example flow:

Code Commit → Build → Test → Artifact → Deploy → Verify → Rollback if needed

---

Stage in Harness -

A Stage is a logical grouping of steps within a pipeline that represents a phase of the delivery process.

Common stages

• Build Stage
• Deployment Stage
• Approval Stage
• Security Scan Stage

Example:

Pipeline
 ├── Build Stage
 ├── Test Stage
 └── Deploy Stage

---

Deployment strategies Harness supports -

Harness supports several deployment strategies:

Strategy	Explanation
Rolling	Deploy gradually to instances
Blue-Green	Switch traffic between environments
Canary	Deploy to small subset first
Recreate	Stop old version then deploy new
Shadow	Mirror traffic to new version

Example:

In a Canary deployment, a small percentage of traffic is routed to the new version to validate its performance before a full rollout.

---

Harness Continuous Verification (CV) -

Continuous Verification uses machine learning to analyze application metrics and logs during deployment to detect anomalies.

It integrates with tools like:

• Prometheus
• Datadog
• Splunk
• New Relic

If anomalies are detected:

• Harness automatically rolls back the deployment.

---

Harness Delegate -

A Delegate is a lightweight service installed in your infrastructure that performs tasks on behalf of Harness.

In simple words, Delegate is an agent of Harness who perform all the steps required for deployment on infrastructure.

Harness itself does not directly access your infrastructure; instead, the delegate performs those operations locally and communicates results back to Harness.

Responsibilities

• Execute pipeline steps
• Communicate with infrastructure
• Connect with artifact repositories
• Perform deployments

Example:
A Delegate in Harness is a lightweight agent installed in the target infrastructure that executes pipeline tasks such as deployments, integrations, and scripts execution. It acts as a secure communication bridge between the Harness platform and the infrastructure resources.

---

Connectors in Harness -

Connectors allow Harness to connect with external systems.

Examples

• Git repositories (like stash)
• Artifact registries (like nexus)
• Cloud providers (like GCP, Azure or AWS)
• Kubernetes clusters

Common integrations:

• GitHub
• Docker Hub
• Amazon Web Services
• Kubernetes

---

Infrastructure Definition in Harness -

Infrastructure Definition defines where the application will be deployed.

Examples

• Kubernetes cluster
• AWS EC2
• Azure VM
• Google Cloud

It includes:

• Cluster details
• Namespace
• Deployment environment

---

GitOps in Harness -

GitOps is a deployment method where Git repositories act as the single source of truth for infrastructure and application configuration.

Harness GitOps integrates with:

• Argo CD
• Flux

Workflow:

Developer commit → Git repo → GitOps tool → Kubernetes cluster

Alternate:
You can create  trigger inside pipeline triggers using Github webhook, that will trigger your pipeline execution on code commits.

---

Rollback in Harness -

Rollback happens automatically when:

1. Deployment verification fails
2. Error thresholds are crossed
3. Manual rollback is triggered

Steps:

1. Harness detects failure
2. Stops current deployment
3. Restores previous stable version

---

Harness Templates -

Templates allow reusable pipeline components.

Example reusable templates:

• Deployment step
• Security scan
• Build process

Benefits:

• Standardization
• Reusability
• Reduced configuration errors

---

Harness Triggers -

Triggers automatically start pipelines based on events.

Common triggers:

• Git commit
• Pull request
• Schedule
• Webhook

Example:

Git Push → Trigger Pipeline → Build + Deploy

---

Difference between Harness and Jenkins -

Feature	Harness	Jenkins
Setup	SaaS / Managed	Self-hosted
AI verification	Yes	No
UI	Modern UI	Basic
Deployment strategies	Built-in	Plugin based
Rollback	Automated	Manual scripting

---

Secrets in Harness -

Secrets store sensitive information securely in encrypted form and decrypted when to use.
Or you can ingrate external store like AWS Secret Manager, Secret Vault etc.

Examples:

• API keys
• Passwords
• Tokens

Harness integrates with secret managers like:

• HashiCorp Vault
• AWS Secrets Manager

---

Harness supports Kubernetes deployments -

Harness supports multiple Kubernetes deployment types:

• Kubernetes Rolling Deployment
• Kubernetes Canary Deployment
• Helm Chart Deployment
• GitOps deployment

Tools used:

• Helm
• Kubectl

---

Advantages of using Harness -

Advantages include:

• AI-driven deployment verification
• Automatic rollback
• Reduced deployment failures
• Built-in security scanning
• Native cloud and Kubernetes support

Harness | Core Concepts

 Core components of Harness

1. Application

An Application is the top-level container in Harness.

• It represents a complete project or system
• Contains all services, environments, workflows, and pipelines for that project

Example

Application: E-commerce Platform

Inside it you may have:

• payment-service
• order-service
• notification-service

---

2. Service

A Service represents a deployable microservice or application component.

It defines:

• Artifacts (Docker image, JAR, ZIP, etc.)
• Service configuration
• Deployment variables

Example

Service: Order Service

Artifacts:

• Docker image from Docker
• JAR file from a repository
• Lambda package

Possible service types include:

• Secure Shell
• Kubernetes
• AWS Lambda
• ECS

Example:

• If deploying a container to Kubernetes → Kubernetes service type
• If deploying serverless → use AWS Lambda service type.

---

3. Environment

An Environment represents where the service will be deployed.

Typical environments:

• Dev
• QA
• Staging
• Production

It defines:

• Infrastructure
• Cloud provider
• Target cluster or server

Example:
Environment: Production

Infrastructure:

• Kubernetes cluster
• AWS account
• VM instances

---

4. Workflow

Workflows are part of First Gen Harness in Next Gen Harness its moved under Pipelines Execution.

A Workflow defines how the deployment happens.

It contains:

• Deployment steps
• Pre-deployment tasks
• Post-deployment verification
• Rollback steps

Example workflow steps:

1. Pull artifact
2. Deploy container
3. Run database migration
4. Perform health check
5. Verify deployment

Harness can also integrate with monitoring tools for verification.

---

5. Pipeline

A Pipeline orchestrates multiple workflows.

It allows:

• Sequential deployments
• Multi-environment promotion
• Approval gates

Example pipeline:

Build → Dev Deploy → QA Deploy → Approval → Production Deploy

Example integration:

• Build triggered from Jenkins
• Deploy to Kubernetes cluster

---

Complete Example

Application

Online Banking System

Services

• account-service
• transaction-service
• notification-service

Environments

• Dev
• QA
• Production

Workflow

Deploy container → Run health check → Verify logs

Pipeline

Build → Dev → QA → Manual Approval → Production

---

Easy way to remember

• Application → Project
• Service → What you deploy
• Environment → Where you deploy
• Workflow → How you deploy
• Pipeline → Deployment process across environments

CI/CD - Ideal Pipeline Characteristics

 An Ideal CI/CD Pipeline with Harness means an automated flow where code goes from developer → build → test → security → deploy → monitor with minimum manual work and strong governance.

Think of it as a production assembly line for software.

---

High-Level Flow

Developer → Git Push → CI Build → Test → Security → Artifact → CD Deploy → Monitor → Feedback

Harness mainly shines in Continuous Deployment, but it also supports CI.

“An ideal CI/CD pipeline with Harness automates build, test, security scanning, artifact versioning, progressive deployment strategies like canary or blue-green, governance approvals, and automated rollback with continuous monitoring across environments.”

---

Stage-by-Stage Ideal Pipeline

1. Source Control (Git)

Tools: GitHub / GitLab / Bitbucket

What happens

• Developer pushes code
• Pull request triggers pipeline

Best Practice

• Branch strategy (main / develop / feature)
• Mandatory code review

---

2. Continuous Integration (CI)

Steps

1. Checkout Code
2. Build
3. Unit Tests
4. Code Quality
5. Security Scan
6. Create Artifact (Docker / JAR / DLL)

Typical Tools

• Build: .NET CLI / Maven / npm
• Quality: SonarQube
• Security: Snyk / Trivy
• Artifact Repo: Nexus / Artifactory / ECR

Goal: Ensure every commit is buildable and safe.

---

3. Artifact Storage

Store versioned outputs:

• Docker Images → AWS ECR
• NuGet / JARs → Artifact repo

Key Rule:
Only deploy immutable artifacts, never rebuild in CD.

---

Continuous Deployment (Harness Strength Area)

4. Environment Promotion Flow

Dev → QA → Staging → Prod

Harness provides:

• Visual pipeline
• Rollback automation
• Approval gates
• Feature flags
• Canary / Blue-Green deploy

---

5. Deployment Strategies

Blue-Green

• Old version live
• New version parallel
• Switch traffic instantly

Canary

• 5% → 25% → 50% → 100%
• Auto rollback on failure

Rolling

• Replace containers gradually

Harness automates health checks and rollback without manual SSH.

---

6. Approvals & Governance

Before Prod:

• Manual approval
• Security approval
• Change-management integration
• RBAC controls

This is crucial for enterprises.

---

7. Infrastructure Integration

Works with:

• Kubernetes (EKS)
• ECS / Fargate
• VMs
• Serverless (Lambda)
• Terraform / CloudFormation

Harness doesn’t replace infra tools — it orchestrates them.

---

8. Monitoring & Feedback

After deployment:

• Metrics (CPU, memory, error rate)
• Logs
• APM tools
• Automated rollback triggers

This closes the DevOps loop.

---

Ideal Pipeline Characteristics

Characteristic	Why Important
Automated	Removes human error
Fast	Short feedback cycle
Secure	Scans before deploy
Immutable	Predictable releases
Observable	Quick failure detection
Rollback Ready	Reduces risk
Multi-Env	Dev → Prod consistency

---

Example Ideal Flow (AWS + .NET + Docker)

1. Developer pushes code
2. CI builds Docker image
3. Unit + security tests
4. Push to ECR
5. Harness picks image
6. Deploy to Dev ECS
7. Auto test
8. Promote to QA
9. Manual approval
10. Canary to Prod
11. Auto health check
12. Rollback if error > threshold