Our engineering team has been getting ship done the past six weeks during May and June. Being a Continuous Delivery vendor, we've done roughly 1,900 deployments the past 30 days and have kept our velocity up while onboarding lots of new customers.
Here's what the Harness team delivered in May and June:
Read on below for the full Product Update for May/June 2018.
We recently introduced a new concept to Harness called "Infrastructure Provisioners." This basically allows customers to reference and reuse their existing HashiCorp Terraform and AWS CloudFormation templates to provision and de-commission infrastructure as part of their deployment.
As you can see from the deployment workflow example (below), you can now reference your Terraform/CloudFormation templates as a pre-deployment step to provision infrastructure, and reference them (if needed) as a post-deployment step to de-commission infrastructure (think Blue/Green deployments where you might want to decommission the old environment).
As with any deployment step, Harness will provide full console visibility of the Terraform and CloudFormation steps so you can follow their execution line by line.
At launch we made the decision to start with Linux, Java, Docker, Kubernetes AWS, and GCP support. Over the past six months, we've quickly expanded our support to other technology stacks and clouds.
Unsurprisingly, the Microsoft stack of .NET, IIS, and Azure were the most requested platform(s). We've now added IIS Websites, IIS Applications, and IIS Virtual Directories as first-class citizens for artifact support. We've also added Powershell and WinRM support so Harness can execute and communicate within the Microsoft ecosystem.
The second most requested Cloud platform by customers was Pivotal Cloud Foundry. This platform has a large footprint within F500 companies, specifically financial services, so it was critical we added this platform support. Read the blog.
Harness now has the ability to perform true service impact verification across all microservices within your application environment. A large F500 bank requested this feature so they could instantly know the upstream and downstream impact of every microservice deployment. Now when you deploy a new microservice container, Harness will identify and verify all microservice dependencies so you know the real impact. Read the blog.
Want to synchronize and control the flow of many microservice deployments? Not a problem. Simply add "Barriers" to your deployment workflows so that all workflows reach the same point of execution before they continue.
This feature was requested by customers who wanted to deploy many microservices in parallel, but only wanted to verify to begin after all deployments had completed. For more info, read the blog.
Want to register your Harness deployments as events or flags within your APM solutions? Not a problem. You can now add a "deployment marker" as a verification step within your deployment workflows.
For example, click "Add Verification" and select "New Relic Deployment Marker." Next, select your New Relic Server and Application Name so Harness has the correct context.
Finally, you can edit the body of the deployment marker. This is the message that will be injected into your APM solution so users receive deployment context.
The above deployment marker would then look like this in New Relic:
In the past, you could define/set variables and secrets at both the Service and Environment level. Now you can define/set global application variables for all your deployment pipelines. We're also working on more capabilities in this area, so stay tuned!
Here's a small list of other features/capabilities we shipped:
Thanks for reading the Product Update for May/June 2018. Catch us next time for more updates!
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.