Migration of our Harness Production SaaS to Harness Next Generation Platform
Around this time last year, we started transitioning our production SAAS CD pipelines to our nextgen platform; which we concluded in April. The migration procedure we employed while utilizing several new features of our next-generation platform is summarized in this blog.
Throughout this blog, we will use the below notations, CG (Current/Older Platform for Continuous deployment CD-1.0). NG (Next generation Platform for Continuous deployment CD-2.0). Continuous Delivery(CD) is one of the modules in NG, as NG has many other modules of Harness Platform architecture . In the current context, our area of focus is CD module and all the new features we have used to build our production pipelines in NG.
“Our direction was to use same pipeline from non-production till production in our NG platform.”
Kubernetes service manifest migration
Our SAAS application runs on Google’s GKE, and our first actionable task was to migrate the Kubernetes manifests to align with changes in the NG. The NG platform doesn’t support inline manifests like the CG, and there are changes in harness built-in variable support Built-in and Custom Harness Variables Reference. If existing customers on the CG platform have enabled git sync, they can start using the same manifests with modifications to harness variables. We have a blog How we configured our manifests for k8s micro service pipelines in Harness CD 2.0 that gives a detailed approach to how we built our Kubernetes service manifests.
Building pipelines in CG vs NG
In CG, we have workflows stitched together with service, infrastructure into a pipeline. In a stark contrast its a complete easy and intuitive inline experience in NG.
Below is a pipeline which deploys our Harness CG Platform using our new NG Platform CD module.
Let’s dive in details to see how the above pipeline was realised. We have the manifests built, we can start to build a pipeline for deploying the services with our inline experience of NG pipeline editor.
But wait before we deploy a image we should ensure we are not introducing security vulnerabilities in a release. Harness platform provides STO (Security Testing and Orchestration ) module, ability to left shift image security to address security vulnerabilities during the build phase of image. This linked blog Harness Security Testing Orchestration (STO) — Key Capabilities | Harness gives more details for this module.
Once the above security vulnerabilities are addressed we are ready to deploy the image using the NG pipeline.
Pipeline Inline experience
A harness pipeline is a combination of Stage(s) in serial or parallel and each stage is a collection of steps. Let’s see how a stage in the pipeline is defined using its Pipeline editor to answer below.
- What to deploy ? [Service Definition tab ]
- Where to deploy ? [Infrastructure Definition tab ]
- How to deploy ? [Execution tab ]
- What action to take on failure ? [Advanced tab ]
- Service definition : We start by creating a service name or identifier for the service we plan to deploy and choose a type of harness-supported deployment( for us it was Kubernetes). We register the git connector (created inline) for picking the manifest repo to deploy our k8s service. Harness gives the flexibility to override the values in your yaml manifest’s [shown in 3 below figure] which is handy when using same manifests across multiple environments. Further we register artifacts [primary & sidecar ] to be deployed from harness supported artifact repository [GCR in our case].
2. Infrastructure definition: Next we define our infrastructure and tag the environment, where harness CD will deploy the service.
3. Execution : Now Harness has info on what to deploy & where to deploy this section tries to answer how to deploy using various strategies provided in the Step Library listed below in diagram. Some of the steps we have used extensively in our pipelines are Jira Approval, Shell Scripts, Rollout Deployment.
4. Advanced : This tab provides us with options which will let one control conditions for execution and actionables on failure at stage level [a similar option is available at step level too].
Some of the other features used in building our prod pipelines.
Role Based Access Control for Users
We have used new Harness RBAC feature which provides granular features via Resource groups,Roles & User groups. This helps us giving relevant permissions for CRUD on the pipeline for a user or a group.
Service Reliability Management [ SRM ]
We are using Verify step in our pipeline post the rollout of a service to ascertain the health post deployment.
Going live in production with new pipeline with validated configs
When pipeline and manifests are both complete, you are almost ready to deploy with NG. You probably want to make sure all configurations are correct before doing so. If your service runs in Kubernetes, deploying the configMap into a non production environment and then comparing them with existing ones may be a good idea. You can achieve this by adding an “Apply” step to apply certain configMap yamls in the same way as in CG. Once all looks good, you can use the new NG pipeline to deploy.
Conclusion
Here we have highlighted only some of the features of CD module during our migration from CG to NG. Harness platform has so many features /modules in areas of CI, Feature Flags, Cloud Cost Management, Security Testing, Service Reliability and Chaos Engg for various customer use cases, if there isn’t one our Harness engineers are more than happy to create one.
Thanks for reading !!
