How Does Harness Use Harness CD?

Continuous Delivery (CD) is the practice followed in the software development process of building, testing, configuring, and deploying changes of all types. This includes new features, configuration changes, bug fixes, and experiments. Furthermore, these go right from a developer's workstation, through multiple non-production environments, and then finally to an organization's production environment in a continuous manner. In this post, we’ll explore what CD is, and how Harness uses Harness CD. That’s right – we drink our own champagne here at Harness. Let’s show you how!

What Are the Main Components Involved in Continuous Delivery?

There are many components involved in CD. The following are the four main ones:

1. Continuous Integration (CI): The first step of the CD process is CI. Code that is developed on a developer’s workstation is continually committed into a version control repository, and it begins its journey through the entire pipeline automatically.

2. Non-Production Environments (NPE): NPEs are environments set up internally where only internal employees and beta users have access. All types of testing across multiple dimensions are done in these environments before customer rollout. Note that each progressing environment in the pipeline should become more like the company’s production environment. 

3. Branching Strategy: CD is as good as getting new changes into the version control system (VCS). Different teams should be able to do smooth operations, such as pushing to a branch or pulling a stable branch locally to start development.

4. Feedback Loops: Every step/stage in software development pipelines should have a feedback loop stating the result of each step/stage.

How Does Harness Use Harness CD?

How can someone experience what others are experiencing? “You must be in their shoes to experience it.” To experience what your customers are experiencing, be your own customer first and use your product like you expect customers to use it.

At Harness, we use Harness products to build, test, and deploy Harness in all environments (pre-QA, QA, Stage, and Prod). Essentially we‘re dogfooding ourselves to see how our product is performing in real-time scenarios.

The following are the workflows and environments that Harness has set up internally to build, test, and deploy Harness services.

CI Setup

Pull Request Workflow: This is the beginning of CD. Every developer develops code in their workstation within their respective local branches, pushes their changes to GitHub, and creates pull requests in GitHub against the develop branch. In Harness, GitHub is integrated with Harness CIE using GitHub Connector, where multiple checks are configured to run on every PR request that is created against the develop branch. 

As soon as the PR is raised, a series of jobs/pipelines run in Harness CIE and report the status back to GitHub. If all of the jobs/pipelines are successfully executed, then GitHub will mark the PR as green and PR is ready to merge to the develop branch.

CD Setup

PR Env: Harness CD deploy services to Kubernetes in the best way possible. Minimal babysitting means that the deployments can deploy swiftly as well. Therefore, as part of the code merge/pull request to develop branch, developers build their services into Docker images using Harness CIE and use PR env setup. This is a GKE cluster where individual services get deployed by developers as part of testing on an individual level. 

This is done to test and deploy their services in Google Kubernetes cluster. Once the changes are tested in PR env, then developers push the code to the develop branch and the configurations used by services to the configuration repository.

Non Production Environments

PRE-QA

Once the service is tested in PR env, then the configuration changes from the master branch in the configuration repository. Next, it is applied to PRE-QA env where services from different teams get deployed after every 6-8 hours. Furthermore, automation suites run against this environment and results are produced and published to various slack channels accordingly.

QA

This is another environment setup using Harness CD that runs more aggressive automation suites. Additionally, stress testing is done in this environment. This environment is almost the same as PROD env, and the whole setup is tested across multiple dimensions to make sure that everything works well, there are zero security vulnerabilities, and the binaries are stable under multiple situations.

STAGE 

This is an on-premises setup version, unlike the SaaS version of the Harness application. This environment contains multiple deployment pipelines to deploy Harness services to QA and PROD environments. RBAC applied to this environment makes sure that no one apart from concerned team members can access any deployment pipelines.

Why Is Harness Investing More in CD?

CD makes sure of what is really done and tested. Moreover, CD can enable many things for every company that adopts these practices:

1. Overall Testing: CD enables developers to test their changes beyond just unit tests, so that they can verify their changes across multiple dimensions before deploying to production servers.

2. Faster Feedback: CD reduces the risk involved in deploying software because your code is getting verified across multiple environments and each and every environment provides feedback.

3. Deployable Ready: CD lets you make sure that your main/master branch will stay deployable-ready at all times. Deploying release from every commit/change is possible.

4. Easy Debugging: The area to debug will be a lot less in case of any breakage because you are releasing software in small chunks and not with huge chunks continuously.

5. Release Frequency: Let's look at the trend of releases from the past 10-15 years until today for every company. Release cycles were approximately once every couple of months, whereas today they are at least twice per week. The frequency of releases has increased drastically. Everyone wants to roll out updates as fast as possible to stay ahead of competition. Without CD, this fast release frequency will be a bottleneck for application and operation teams. Manual processes led to unreliable releases that produced delays and errors.

6. Transparency: Every piece of script to set up that is involved in the CD pipeline gets scrutinized. Therefore, everyone is aware of the changes made to the CD pipelines and no personal settings can get passed to pipelines/jobs.

Conclusion

Be Your Own Customer (BYOC) if you really want to experience what your customers are facing while using your product. Using Harness to build, test, and deploy Harness enables everyone here to find bugs before they reach customers. Furthermore, it enables everyone to contribute to finding gaps in the product, which leads to feature development in Harness. Last but not least, it improves the User Experience as well.

We'd love for you to continue reading about how we use our own products. Here's an article on our migration from Jenkins to Harness CIE.