Harness Continuous Delivery & GitOps vs GitHub Actions

SaaS & On-Premises:

GitHub Actions used to be SaaS-only, but as of May 13th (just 11 short days ago at the time of this writing), a version was made available for customers on GitHub Enterprise Server 3.0 or later. From our understanding, there are some minor limitations, but most actions are available on the on-prem version. Harness provides SaaS and on-prem versions of the product, with feature parity between both.

No Scripting Required:

GitHub Actions does unfortunately require a decent amount of scripting. The good part is that if you do have to write an action, you can publish it as a container image, so you can write it in whatever language you want. There are also lots of pre-written actions out there on the actions marketplace, including integrations to plenty of tools. While scripting isn’t the bane of our existence, it is time that could be spent shipping code. It is toil. It’s something that needs maintenance by your brightest engineers. Harness is much more intuitive and takes away the burden of scripting.

Ease of Use:

You can get up and running with GitHub Actions fairly quickly. Assuming you have a GitHub repo already, you can add your first workflow into the repo and your action should run. Managing secrets is painless: you have the ability to set your secrets at the organization level as well as at the repo level, which is relatively flexible. One of the larger sticking points is that the way you pass data around your workflow between jobs can be a bit tricky at first. There’s a learning curve. When trying to pass data between actions and jobs, you’ll find yourself needing to use cryptic action syntax or direct .env file insertion to chain each job’s state together. With Harness, there’s no scripting needed and configurations are passed to pipelines securely and in a pragmatic way. Like most CI/CD providers, Github Actions has third-party actions that you can use as semi plug-and-play functionality. You’ll find that it’s hit or miss whether or not a task has already been solved by a publicly-available GitHub Action – otherwise you’ll need to write your own. Given that, you’ll find yourself needing to code a lot when working with GitHub Actions. In comparison, Harness offers containerized plugins featuring a vast amount of integrations – no maintenance, no writing – only simple, scalable, self-service extensibility. Lastly, because GitHub Actions is a newer offering, it still doesn’t have any sort of good reporting and oversight on what’s happening outside of a given repo. There’s no high-level overview of watching executions with a timeline or native deployment tracking, which is something Harness gives you. With GitHub Actions, you’ll be building everything yourself – besides where you get lucky and find a pre-written action.

Canary Deployments:

An Azure user put together a helpful tutorial on how to do canary deployments with GitHub Actions and Azure using Linkerd. It is possible, but as the user noted, “An end-to-end solution, fully automated and based on metrics, in a more complex production application is quite challenging. […] While I think the GitHub Action works well, I am not in favor of driving all this from GitHub, Azure DevOps, and similar solutions. There’s just not enough control.” The adage “Just because you can doesn’t mean you should” remains true here. Harness provides guided Canary deployments out of the box – no coding required, only some minor config.

Infrastructure Provisioners:

HashiCorp created an action to set up and configure the Terraform CLI in your GitHub Actions workflow. There is also an action for CloudFormation. Harness offers both infrastructure provisioners – with a simpler setup and configuration process.

Continuous Verification™:

Continuous Verification is the process of monitoring your app for abnormalities after a deployment. For example, Continuous Verification could catch a latency issue or 5xx errors and automatically roll back your app to the previous version. The idea is to catch errors as quickly as possible – ideally, before customers notice – and make a seamless transition back to the prior version. We found some basic deployment status actions out there, but those only tell you if a deployment passed/failed, not how it’s doing post-deployment. It seems that to have complete visibility into deployments, you would need to write your own actions to achieve this. There are integrations into some observability tools like Lightstep, so it could be done – manually. Harness, however, provides Continuous Verification out of the box, effectively reducing risk and reputational damage from downtime. Harness supports many vendors, including Prometheus, Datadog, AppDynamics, New Relic, StackDriver, CloudWatch, and custom monitoring and observability tools.

Change Management Jira/SNOW:

Atlassian has created an action to integrate Jira into your workflow. From the actions available, though, it seems more for recordkeeping purposes than an approval mechanism. The SNOW action is much more comprehensive, allowing for publishing and rollback of apps. Harness offers full integrations for Jira and SNOW, insofar as they can be used for recordkeeping purposes and as approval mechanisms.

Secrets Management:

GitHub Actions provides different ways of scoping secrets. For one, secrets can be set up at a global organization-wide level. Instead of having to update secrets across a number of Git repositories, they can be handled in a centralized place. Additionally, you can restrict whether secrets are exposed to forked repositories or not. Onto the downsides: GitHub Actions doesn’t have granular access control mechanisms. Also, secrets in GitHub Actions are natively handled for CI/CD – third parties, like HashiCorp Vault, cannot be leveraged. While Harness does offer its own secrets management solution, it also integrates with third party vendors like HashiCorp Vault, Amazon Secrets Manager, Google Secret Manager, AWS Key Management Service, Google Cloud Secret Manager, CyberArk, and Azure Key Vault.

Accelerate Metrics & Reporting:

There are four key metrics when it comes to software development: Lead Time (the average amount of time it takes from the time code is checked in to the version control system to the point in time where it is deployed to production), Deployment Frequency (the number of times deploys to production occur in a time period), Mean Time to Restore (MTTR: how long it takes to resolve or rollback an issue in production), and Change Failure Rate (what percentage of changes to production fail). These metrics are paramount in truly understanding performance. GitHub Actions does not provide native Accelerate metrics dashboards. Harness offers a beautiful dashboard specifically for these metrics and allows you to set alerts as needed – for example, you could set an alert to notify you if the Change Failure Rate goes above 1%.

*Please note: Our competitors, just like us, release updates to their products on a regular cadence. We keep these pages updated to the best of our ability, but there are bound to be discrepancies. For the most up-to-date information on competitor features, browsing the competitor’s new release pages and communities are your best bet.

Try Harness For Free