Hi Hans

My experience is that the deployment can be very slow sometimes. Its both depending on how many other things going on in Azure, but also how long time your application takes to start. I was in a project that had to many available routes specified in the ViewEngine (to handle feature folders) that took very long time to start. When fixing that issue we could deploy the site 10 min faster. So it could also be good to make sure that the site your are building can start fast. But the end of the day... deploying to DXP is not fast. Even if you just move your application from ex Integration to Preproduction. And if you deploy both CMS and Commerce it takes even longer time.

It is also a big difference between deploying a WebPackage via "Azure App Service Deploy" or a NUGET package via Deployment API. NUGET package via Deployment API takes alot longer time. That is because it will setup the application on a slot first before it "move" it to the Integration server. The "Azure App Service Deploy" is faster because it "just install" the WebPackage to the IIS website. I could be wrong but this is how I see it at the moment. But this just rely when deploy to Integration. When you "move" your appliction from ex "Integration" to "Preproduction" there is no difference if you have used WebPackage or Nuget from the begining. 

In all my project where we use DXP, we always use WebPackage deployment to Integration because it is mutch faster. Life is short. We don´t have time to wait...right!

A tip if you dont want to create your own PowerShell scripts, to deploy to DXP, is to use Epinova DXP Deployment extension in Azure DevOps. You can install it from VisualStudio marketplace. https://marketplace.visualstudio.com/items?itemName=epinova-sweden.epinova-dxp-deploy-extension

The documentation is found in github: https://github.com/Epinova/epinova-dxp-deployment/tree/master

I have also created a serie of blogpost that describe how to use it: https://www.epinova.se/nyheter-och-blogg/utvecklarbloggen/2020/epinova-dxp-deployment-part-1-introduction/

Best regards

Ove

Ove

Thank you very much for your detailed answer. I will have a look at the Epinova extension.

Regards Hans

Hans,

The deployment from DevOps to DXP is very simple and quick to setup.

All you need to do is to create a pipeline and Service connection in project settings. For Service connection, you need service principle information that will be provided by Episerver support. The pipeline is easy to set up against code check-in on a certain branch and deploy on integration environment through this will take roughly around 4 minutes

@Adnan: 4 minutes for deploy directly to the integration environment is OK. Just as I would expect for deploy to Azure.

But we can not have Service Principal for deployment directly to preproduction and production? We must use the deployment API or the paas portal, and then deployment to preproduction and production takes 15-60 minutes.

Are there any tricks for preproduction and production?

@Tomas

I don't think there is any tricks at the present time. Not that follows some kind of ethics.... And I agree that it takes ridiculously long time to deploy/release the application between the environments.

So the only trick is to make sure that your application is as fast and well coded as possible. As I mentioned before, we lowered the time to move the code between the environment alot after make sure that the application started quicker. And that could be everything from holding down on the number of InitModules to routes to other crazy cool functions. Make sure that you have a slim and fast code so that you don´t waste time.

There is also a factor if there are many other applications that takes resources from the cloud at the same time. That will affect your deploy too. Your not alone out there. You should not forget that you are playing around on someone else's server (the cloud) :) .

I know it's someone else's server. But, i think «someone» need to fix their server! :-)

Deployments to Azure Web Apps are consistently fast, and never fails.
My experience from a week of DXP is that deployments are slow, I mean really slow, and fails too often.

I'm sorry, but my first impression is that moving from Azure to DXP (that's still Azure) is a serious downgrade when it comes to the deployment experience.

@Tomas & @Ove

Thank you for keeping up the discussion. I agree with Tomas.

As I mentioned in my question we use our own Azure DevOps (onprem). We have only one buildserver. We have had no issues with that before. But now when I have set up deployments to EPiServer DXP that can take up to 1 hour it blocks everything else. So because of that we may have to set up another buildserver. For me thats weird. I think there should be quicker ways to deploy to prep and prod.

/Hans

I'm also quite unhappy with the time it takes to deploy DXP code. I thought it's because my web app can't be properly warmed up because it does not allow public access, but after some trial and error, it seems like it is what it is.

I'm using DXP at the moment because the client already has a site there, but if someone will ask me whether to go with DXP or not, I definitely will voice my concerns about deployment time and suggest against DXP.

@Jerzy I understand your frustration.

But I think it also good to have in mind all the good things that you get with DXP.

• Harmonization of content out of the box.
• You dont need to setup a CI/CD pipeline that is different every time.
• Search and Navigation (Find)
• Posibility to change your server setup very easily 
• Posibility to export BLOBs, DB, web logs, application logs
• etc...

So I would say that the bad part is the time it take to deploy. But everything else is, in my point of view, in the forefront of things that you want as DevOps/developer. And you also notice how much effort Episerver put in to make DXP really good. So hopefully they will be able to fasten up the deploy time soon. I hold my breath.... or at least I hope :)