Skip to main content

Migrating from GitHub Actions to Harness Continuous Delivery

Migrating from GitHub Actions to Harness Continuous Delivery (CD) can be beneficial due to Harness’s powerful deployment strategies and streamlined CD pipelines.

Here's a step-by-step tutorial on how you can migrate from GitHub Actions to Harness CD.

High level guidance

Step 1: Preparation

  • Review and document your current GitHub Actions workflows and configurations.
  • Identify and list all the required environment variables, secrets, and deployment scripts.
  • Ensure you have access to a Harness account. If not, create one.

Step 2: Harness Delegate installation

  • Download and install the Harness Delegate to your Kubernetes cluster or a VM within your network.
  • The Delegate will connect your Harness account to your infrastructure.

Step 3: Project configuration

  • In the Harness platform, navigate to Projects and create a new project.
  • Set up your environment and infrastructure definitions in Harness. This will include specifying your Kubernetes clusters and any other necessary infrastructure.

Step 4: Pipeline creation

  • Under your project, create a new pipeline.
  • Design your pipeline using the Harness visual editor, mirroring the steps from your GitHub Actions pipeline such as building, testing, and deploying. 

Step 5: Pipeline translation

  • Manually translate each step of your GitHub Actions pipeline into corresponding steps in your Harness workflow.
  • Harness has native steps for common tasks, and you can use shell script steps for custom actions.

Step 6: Secrets management

  • Import or add your secrets (for example, Docker Hub credentials, SSH keys, etc.) into the Harness Secrets Manager.
  • Update your workflow steps to use these secrets where necessary.

Step 7: Trigger setup

  • Set up triggers in Harness to initiate the workflow. This can be based on different conditions like new commits to your GitHub repository.
  • This replaces the event triggers you had in GitHub Actions.

Step 8: Testing

  • Execute your new Harness workflows in a non-production environment to ensure they operate as expected.
  • Debug and refine your Harness workflows as necessary.

Step 9: Deployment

  • Once satisfied, update your deployment configurations to point to your production environment.
  • Run your Harness workflows to deploy to production.

Step 10: Monitoring and optimization

  • Set up monitoring and alerting within Harness to stay informed about the state of your deployments.
  • Utilize Harness’s Continuous Verification to automatically verify deployments and rollback when necessary.

Step 11: Documentation and training

  • Document your new Harness CD setup and train your team on the new process.
  • Ensure everyone is comfortable with Harness and knows how to use it for deployments.**

Analyzing the Github Actions YAML and mapping it to Harness Pipeline YAML

This migration process will require a thorough understanding of both GitHub Actions and Harness CD. Take advantage of Harness’s documentation, support channels, and community forums to assist with the migration.

In GitHub Actions, you create pipelines using a YAML file within your repository. In Harness, configurations are typically done via the UI, but you can export them as YAML.

Here is a simple example to show the differences.

GitHub Actions:

Here's a simple Kubernetes deployment GitHub Actions pipeline:

name: Deploy to Kubernetes

- main

KUBECONFIG_FILE: kubeconfig.yaml

runs-on: ubuntu-latest

- name: Checkout code
uses: actions/checkout@v2

- name: Set up Kubectl
uses: azure/setup-kubectl@v1
version: '1.20.0'

- name: Configure kubeconfig
run: echo "${{ secrets.KUBECONFIG }}" > $KUBECONFIG_FILE

- name: Deploy to Kubernetes
run: |
kubectl apply -f deployment.yaml
kubectl rollout status deployment/my-deployment

Harness CD:

In Harness, configurations are done through the UI, API, or YAML.

Below is a simplified representation of how a Kubernetes deployment might look in YAML in Harness:

name: Kubernetes Deployment
identifier: Kubernetes_Deployment
projectIdentifier: Platform_Engineering
orgIdentifier: Product_Engineering
tags: {}
- stage:
type: Deployment
deploymentType: Kubernetes
serviceRef: nginx
environmentRef: dev
deployToAll: false
- identifier: devk8s
- step:
name: Rollout Deployment
identifier: rolloutDeployment
type: K8sRollingDeploy
timeout: 10m
skipDryRun: false
pruningEnabled: false
- step:
type: K8sDelete
name: Clean up
identifier: Clean_up
type: ReleaseName
deleteNamespace: false
timeout: 10m
- step:
name: Rollback Rollout Deployment
identifier: rollbackRolloutDeployment
type: K8sRollingRollback
timeout: 10m
pruningEnabled: false
- onFailure:
- AllErrors
type: StageRollback
name: Deploy
identifier: Deploy
tags: {}


  1. Triggering:
    • In GitHub Actions, the workflow is triggered by a push to the main branch, specified under on.
    • In Harness, similarly, the trigger is defined with an onPush trigger.
  2. Environment Setup:
    • In GitHub Actions, you need to set up kubectl and kubeconfig in the workflow.
    • In Harness, environment setup is handled outside the pipeline in the environment and infrastructure configurations.
  3. Deployment:
    • In GitHub Actions, the deployment steps are defined inline using run and shell commands.
    • In Harness, the deployment steps are defined using built-in step types like KubectlApply, which abstracts away some of the lower-level details.
  4. Clarity and Abstraction:
    • Harness YAML is more high-level and abstracted, aimed at simplifying the deployment process.
    • GitHub Actions YAML is more verbose and requires manual setup of environment and deployment commands.
  5. Configuration Management:
    • In GitHub Actions, kubeconfig and other secrets are managed within the workflow file.
    • In Harness, secrets and configurations are managed centrally outside the pipeline, providing better organization and security.

The migration from GitHub Actions to Harness would involve translating detailed command-line operations into higher-level Harness pipeline steps and configuring environments and secrets within the Harness platform.