As of Update 357, Optimizely (EpiServer) released Direct Deploy into their Deployment API, Episerver.PaaS.EpiCloud. This update changes a couple of my scripts to allow major speed improvements when deploying into the integration environment.
In this post, we will go through the following:
- How does the current deployment to Integration work?
- Why Direct Deploy? Why does this make sense?
- How to utilize Direct Deploy
- Script updates
- Conclusion
Current Deployment Workflow
As mentioned in my previous blog series about the Deployment API, the current workflow is that for each environment you must go through the web app slot and then into the live environment. This has a few steps and bits of manual interaction in it.
This process takes anywhere from 20-40 minutes, based on how much manual interaction that you have for each of the steps. This is fine for environments such as Production or Preproduction, but for environments that are set up to have a CI/CD pipeline, such as Integration, this can get quite backlogged
Why Direct Deploy?
Direct Deploy is such a welcome change for deploying into the Integration environment. As mentioned before, the current process takes a LOT of time to use the Deployment API to publish to Integration.
What this feature does is takes out the need to deploy to the Integration slot environment, and deploys directly to the Integration live environment.
This process takes significantly less time to complete. In the tests that I have run, the deployments to the Integration live environment takes between 4-5 minutes.
This is about an 80% reduction in time between the old process and the new process.
How to Utilize Direct Deploy
This is now the question that you’re probably asking….How can I use this?
Well, this is currently something that is available via the Deployment API only, not PaaS portal.
I do have my previous posts (One, Two, Three) that detail how to use the API, or even my open source scripts, EpiCloud-Scripts, that can be utilized.
Script Updates
This update applies to two of the scripts:
This adds a new parameter into both of these scripts.
[ValidateSet($true, $false, 0, 1)]
[bool]$DirectDeploy = 0
It also has some new validations to ensure that the Target Environment is Integration.
if($DirectDeploy -eq $true -and $TargetEnvironment.ToLower() -ne "integration"){
throw "Direct Deploy only works for deployments to the Integration environment."
}
Lastly, since the Deployment API is simply checking for the switch to be there (not the value), we only have to include it into the splat when the value is true.
(There is no great way to send in a switch via a splat without a value, so I’m always sending in a True value)
if($DirectDeploy -eq $true){
$startEpiDeploymentSplat.Add("DirectDeploy", $true)
}
Conclusion
Honestly, I missed this change in the release notes, but I am so glad I found this as I was looking at previous releases in Epi World.
In my previous project, we would regularly have deployments to Integration fighting with each other, since it took so long to deploy.
This is absolutely an amazing feature that is going to help create quick and efficient CI/CD pipelines! Thank you Epi/Opti team!!
Thank you for this blog post Eric! We’re really glad you find this useful! 🙂