World is now on Opti ID! Learn more

Anders Wahlqvist
Mar 9, 2021
  59
(0 votes)

Introducing "Direct Deploy", a quicker way to deploy to integration using the deployment API!

Deployments in DXP are designed to be as seamless and non-disruptive as possible. We've also added a few steps that might not always be associated with a deployment process (like automatically configure warmup, validating some configurations to make sure they're compliant with the service, migrate environments to the latest version of the service configuration etc.).

Before the new code is live, you also have an option to validate the results before live traffic hits the new version (using slots). This can be very useful, but since warmup has to finish before the site can be swapped, it's also quite slow compared to a deployment where binaries are simply pushed to a web app.

While this approach makes a lot of sense for production sites (and is fully automatable with the deployment API), we've received feedback that it would be nice to have a quicker option to deploy to DXP as well, especially to the integration environment. This has been possible for quite some time, but we felt it was a bit awkward to have to use a different method to deploy to Integration compared to the Preproduction/Production environments, especially if you're already using deployment packages.

We've therefor added a new option for deployments targeting Integration, Direct Deploy.

Direct Deploy can be triggered through the deployment API and the EpiCloud module (using the -DirectDeploy switch for Start-EpiDeployment). This will trigger a deployment that doesn't utilize slots. It will still apply configuration transforms so you can use the same deployment package for all environments, but it will simply just push that package directly to the "live-slot" of the target environment (which will be disabled during the deployment, meaning the target environment will be offline for the duration of the deploy). It will send a request to the target site to trigger the warmup process, but it won't wait for it finish. Nor will it configure a warmup section automatically even if it doesn't exist.

This makes it possible for us to complete the deployment for you much quicker than before, and we hope you'll find it useful when you simply just want to run the first few functional tests in the Integration environment, and therefor want the deployment to finish as quickly as possible.

Finally, I would like to ask you to keep providing us feedback on how we can improve, we really appreciate it!

Mar 09, 2021

Comments

Please login to comment.
Latest blogs
Make Global Assets Site- and Language-Aware at Indexing Time

I had a support case the other day with a question around search on global assets on a multisite. This is the result of that investigation. This co...

dada | Jun 26, 2025

The remote server returned an error: (400) Bad Request – when configuring Azure Storage for an older Optimizely CMS site

How to fix a strange issue that occurred when I moved editor-uploaded files for some old Optimizely CMS 11 solutions to Azure Storage.

Tomas Hensrud Gulla | Jun 26, 2025 |

Enable Opal AI for your Optimizely products

Learn how to enable Opal AI, and meet your infinite workforce.

Tomas Hensrud Gulla | Jun 25, 2025 |

Deploying to Optimizely Frontend Hosting: A Practical Guide

Optimizely Frontend Hosting is a cloud-based solution for deploying headless frontend applications - currently supporting only Next.js projects. It...

Szymon Uryga | Jun 25, 2025

World on Opti ID

We're excited to announce that world.optimizely.com is now integrated with Opti ID! What does this mean for you? New Users:  You can now log in wit...

Patrick Lam | Jun 22, 2025

Avoid Scandinavian Letters in File Names in Optimizely CMS

Discover how Scandinavian letters in file names can break media in Optimizely CMS—and learn a simple code fix to automatically sanitize uploads for...

Henning Sjørbotten | Jun 19, 2025 |