Blog posts by Anders Wahlqvist

Blog posts by Anders Wahlqvist2021-12-10T10:43:49.0000000Zhttps://world.optimizely.com/blogs/anders-wahlqvist/ Optimizely World EpiCloud 1.0.0 released!This week we have released an update to the PowerShell module used to perform deployments through <a href="/link/cecd04dddeea47f89a14d7f163913728.aspx">the deployment API</a>, it's available through <a href="https://www.powershellgallery.com/packages/EpiCloud/">the PowerShell Gallery</a>. No changes in this module should be breaking, but we have improved a couple of things: <ul> <li>The module is now officially cross-platform compatible Are you using Linux to run your builds? No problem! </li> <li>Clearer error message when uploading a code package with the same name twice Overwriting an existing code package is not supported (for CMS 12/Commerce 14 and above) and the deployment API will throw an error when this is attempted. That error message has now been improved so it's clearer. </li> <li>The module no longer requires Az.Storage or Azure.Storage PowerShell modules to run The module is now completely standalone, making it easier to use on the various build runners that are available in Azure DevOps etc.</li> </ul> Our hope is that this will make deploying changes to DXP even simpler than before!2021-12-10T10:43:49.0000000Z

Blog post

Introducing "Direct Deploy", a quicker way to deploy to integration using the deployment API!<div> 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 <a href="/link/ce80e6dd766c40aeaa9be6b4f5d88430.aspx">warmup has to finish</a> 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 (<a href="/link/cecd04dddeea47f89a14d7f163913728.aspx">and is fully automatable with the deployment API</a>), 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 <a href="https://www.powershellgallery.com/packages/EpiCloud/">the EpiCloud module</a> (<a href="/link/eb85a23d0c1843aaa36f121668e1059e.aspx#webapp">using the -DirectDeploy switch for Start-EpiDeployment</a>). This will trigger a deployment that doesn't utilize slots. It will still <a href="/link/f8095ba67d6243d5960675015884e355.aspx#ConfigTransforms">apply configuration transforms</a> so you can use the same <a href="/link/d960958cd9f0474782c58adb311032b1.aspx">deployment package</a> 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. <img src="/link/5580c098b8d847939c3ee3d128028eb5.aspx" /> Finally, I would like to ask you to keep <a href="https://feedback.episerver.com/">providing us feedback</a> on how we can improve, we really appreciate it! </div>2021-03-09T08:07:37.0000000Z

Blog post

DXP deployment improvementsWe've been working on a few improvements related to DXP deployments lately and wanted to share some recent and upcoming updates with everyone, we really hope you'll enjoy these new features! <h2>Deployment API updates</h2> The deployment API has been very well received and we're therefor investing further into it's capabilities by enabling a few new features for the API first in time for it's GA release. <img src="/link/2269517d4d8a4cd4a096080a7d24dbd5.aspx" />The ones we released recently are: <ul> <li>Content syncdown The API now supports triggering content syncdown (copying of DBs and/or blobs) from the Production environment to Preproduction/Integration. If you're using the <a href="https://www.powershellgallery.com/packages/EpiCloud">EpiCloud PowerShell module</a>, you can use the Start-EpiDeployment cmdlet with the IncludeDb and IncludeBlob parameters to start a content syncdown. </li> <li>DB export (bacpac) This is a completely new endpoint in the API that supports exporting a database to a downloadable bacpac file that can be used for local development purposes for example. The <a href="https://www.powershellgallery.com/packages/EpiCloud">EpiCloud PowerShell module</a> has two cmdlets for managing this, Start-EpiDatabaseExport can be used to start the export (it has a -Wait switch if you want it to wait until the export has finished before it returns). If you don't use "-Wait" there is also a cmdlet for fetching the export status called Get-EpiDatabaseExport. </li> <li>More flexible API key management The API key management in the DXP Management Portal has been updated to allow for greater flexibility in how keys are created and can be used (it's now possible to assign access to environments on each key instead of having one key for each environment). For more information, see <a href="/link/c2456bcf1ad24c29b7e1cfddd6df20a8.aspx">the documentation</a>. <img src="/link/34abeaf419ba4c60809d58f106f106e8.aspx" /> </li> </ul> <h2>General deployment updates</h2> We've also been working on a feature that is currently in <a href="/link/b65125e7212142059e425ee2d086c652.aspx">closed beta</a>, namely Smooth deployments (aka. Zero Downtime Deployments). This feature aims to solve the problem of applying database updates without having to take the site offline. While this feature is still in closed beta, we've added some improvements to the reset-process of deployments in general which can be used together with the maintenance page option in the DXP Management Portal. There are now three different recovery options after a deployment has completed it first stage: <ul> <li>Roll-forward We're now enabling you to start a new deployment while the maintenance page stays up if you want fix an unforeseen issue by code. </li> <li>Rollback code and database It's now possible to automatically restore the database to the point in time before the database was updated as part of the reset process together with the previous version of the code (see the "-RollbackDatabase" switch of the Reset-EpiDeployment cmdlet in the <a href="https://www.powershellgallery.com/packages/EpiCloud">EpiCloud PowerShell module</a>). </li> <li>Rollback code only Rollback only the code to the previous version (like it works today).</li> </ul> Another update we've made that it's possible to validate the restored slot before it's swapped back to receive live traffic (optional step available in the DXP Manangement Portal). More information about these recovery options and the upcoming Smooth deployment feature is available <a href="/link/016387a70e524ec4beb5c25ba936b2b9.aspx">here</a>. <h2>What's next?</h2> While these new features hopefully provide some significant improvements to the experience when developing for the DXP, we're definitely not done yet. We will soon look into more ways of accessing the blob storage in the different environments, harmonizing the functionality between the DXP Management Portal UI and the deployment API, getting Smooth deployment ready for GA and more. Meanwhile, make sure you grab the latest version of the <a href="https://www.powershellgallery.com/packages/EpiCloud">EpiCloud PowerShell module</a> and look through the related documentation to these new and updated features: <a href="/link/cecd04dddeea47f89a14d7f163913728.aspx">Deployment API</a> <a href="/link/eb85a23d0c1843aaa36f121668e1059e.aspx">Deploy using PowerShell</a> <a href="/link/016387a70e524ec4beb5c25ba936b2b9.aspx">Smooth deployments</a> <a href="/link/8211485cf8254701b1af4f75a205040c.aspx">DXP self-deployment guide</a> And finally but definitely not least, please reach out to us with any feedback you might have!2020-04-28T05:37:51.0000000Z

Blog post

Azure DevOps and Episerver deployment APIWith the release of the <a href="/link/cecd04dddeea47f89a14d7f163913728.aspx">Deployment API</a>, it's now possible to fully integrate existing CI/CD pipeline solutions with a DXC project. This blog post is using Azure DevOps as an example, but it's of course possible to use other tools to achieve pretty much the same thing. This pipeline is only a suggestion so it can of course be tweaked to better match the requirements of the specific project as needed. If you want a quick start guide related to the API and how it can be accessed and used, <a href="/link/8c86df96587141818ac16cd6ec7368ce.aspx">this blog post</a> might be of interest as well! <h2>Creating a code package</h2> First step is to generate a package that follows the standard described <a href="/link/03b842974cad4e589239047cedd4a963.aspx">here</a>. Your build process might vary slightly of course (for example the location of your nuget.config file), but an example yaml-file that works in Azure DevOps can be found in my fork of the alloy repo <a href="https://github.com/AWahlqvist/alloy-mvc-template/blob/master/azure-pipelines.yml">here</a>. The goal is basically to produce the binaries needed by the web app and then zip them up and give the resulting package a name that complies with the naming convention described by the documentation linked above. Once the above pipeline has been ran, it will produce an artifact that can be used as a deployment package in the release pipeline: <img src="/link/65e46b2e65954423a9af269636828299.aspx" /> In this case, I've configured this build to run on each new commit on the master branch. <h2>Creating a release pipeline</h2> It's now time to create the pipeline that will be used to deploy the code package we created and promote it through the DXC project environments. At an overview this pipeline looks like this: <img src="/link/a5c2ebe5e20c4d60a4796a1b04ed1e50.aspx" /> I've chosen to automatically trigger this release pipeline each time a commit is made to master: <img src="/link/5315727aad80454e8065258a760e3c17.aspx" /> <h3>Uploading the package</h3> The first step of the release pipeline is to upload the code package so it's available for the deployment API. This can be done in various ways, but here's an example that works on the built-in agents (for example vs2017-win2016) that are available in Azure DevOps): <pre class="language-markup"><code>$env:PSModulePath = "C:\Modules\azurerm_6.7.0;" + $env:PSModulePath $rootPath = "$env:System_DefaultWorkingDirectory\_AWahlqvist.alloy-mvc-template\DXC Deployment Package\" if (-not (Get-Module -Name EpiCloud -ListAvailable)) { Install-Module EpiCloud -Scope CurrentUser -Force } $resolvedPackagePath = Get-ChildItem -Path $rootPath -Filter *.nupkg $getEpiDeploymentPackageLocationSplat = @{ ClientKey = "$(Integration.ClientKey)" ClientSecret = "$(Integration.ClientSecret)" ProjectId = "$(ProjectId)" } $packageLocation = Get-EpiDeploymentPackageLocation @getEpiDeploymentPackageLocationSplat Add-EpiDeploymentPackage -SasUrl $packageLocation -Path $resolvedPackagePath.FullName</code></pre> The first line makes sure that the PowerShell module required to upload the code package to blob storage is available (the Add-EpiDeploymentPackage cmdlet in the EpiCloud module requires that the AzureRm or the Az module exists). After that, I've specified the path to my artifact folder where the code package exists so I'll be able to specify the path to the code package that I'm about to upload. Since I'm using shared infrastructure in Azure DevOps, the <a href="/link/eb85a23d0c1843aaa36f121668e1059e.aspx">EpiCloud PowerShell module</a> won't exist on the machine which is why I've added logic to install that as needed. I've also added a few pipeline variables that will be used in this pipeline: <img src="/link/3af68a5e25b0406b86df61bee4967d6a.aspx" /> In this case, I'm using the credentials for the integration environment to be able to access the API and retrieve a upload location for the package (temporary link, which is why it will fetch a new one for each deployment), and then upload that package to the target blob storage account that is used to host the deployment packages for my DXC project. Most of these variables are probably self-explanatory, but it might be worth noting that you should set the ClientSecret as a "secret variable" to have it protected, and that you can set certain variables to be settable when a release is created (which could make sense for example the "UseMaintenancePage"-parameter). If this step runs successfully, we now have a code package uploaded and ready to be used in a deployment. <h3>Deploy package to Integration</h3> It's now time to deploy this package to the integration environment and verify that it works as expected. The steps included in this stage are these: <img src="/link/b557341554544eb2bb17632cdc5f276f.aspx" /> The first step, that deploys the code package to the integration slot looks like this: <pre class="language-markup"><code>$rootPath = "$env:System_DefaultWorkingDirectory\_AWahlqvist.alloy-mvc-template\DXC Deployment Package\" if (-not (Get-Module -Name EpiCloud -ListAvailable)) { Install-Module EpiCloud -Scope CurrentUser -Force } $resolvedPackagePath = Get-ChildItem -Path $rootPath -Filter *.nupkg $startEpiDeploymentSplat = @{ DeploymentPackage = $resolvedPackagePath.Name ProjectId = "$(ProjectId)" Wait = $true TargetEnvironment = 'Integration' UseMaintenancePage = $(UseMaintenancePage) ClientSecret = "$(Integration.ClientSecret)" ClientKey = "$(Integration.ClientKey)" } $deploy = Start-EpiDeployment @startEpiDeploymentSplat $deploy Write-Host "##vso[task.setvariable variable=DeploymentId;]$($deploy.id)" </code></pre> Pretty much the same principle as the previous script. Worth noting is the last line which creates a variable that will be used to complete/reset this deployment later. This variable is also specified under "Output Variables" and "Reference name" for the job step: <img src="/link/78e0829cb7694f61aa5b6df0388616e5.aspx" /> The reset task is configured to only run if a previous task has failed (see Control Options -> Run this task) which will then reset the environment if the smoketest step failed. If it works however, the pipeline will instead proceed with completing the deployment using the following code: <pre class="language-markup"><code>$rootPath = "$env:System_DefaultWorkingDirectory\_AWahlqvist.alloy-mvc-template\DXC Deployment Package\" if (-not (Get-Module -Name EpiCloud -ListAvailable)) { Install-Module EpiCloud -Scope CurrentUser -Force } $completeEpiDeploymentSplat = @{ ProjectId = "$(ProjectId)" Id = "$env:DeploymentId" Wait = $true ClientSecret = "$(Integration.ClientSecret)" ClientKey = "$(Integration.ClientKey)" } Complete-EpiDeployment @completeEpiDeploymentSplat</code></pre> It would now make sense to run some sort of (preferably automated) acceptance tests on the integration site, if those succeed, we're ready to move on to the next stage, Preproduction. <h3>Deploy to Preproduction</h3> This stage will be quite similar to the Integration stage, but just to visualize how this might look for a real project, we can imagine that we have the following steps: <img src="/link/e9e3a0b171884fc6be53a7f97577c121.aspx" /> The difference compared to the Integration stage is that the environment in Preproduction will be better equipped to handle load, so a performance test would make more sense to run in this environment compared to the Integration environment. Could also make sense to run some automated penetration tests at this stage. In my test project, I've also configured a "Post-deployment condition", this could for example be a QA lead that should approve the release before it leaves the Preproduction-stage, for demonstration purposes, I've added myself as an approver: <img src="/link/110ddc4537c44eb9b489bb58759d736d.aspx" /> Note that "<a href="https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/?view=azure-devops">Gates</a>" can also be used to for example trigger performance tests, penetration tests or just validate that other metrics are OK before leaving the Preproduction-stage. <h3>Deploy to Production</h3> For the production environment, I've chosen to add "Pre-deployment approvals" before the deployment is started, again, just for demonstration purposes I've added myself as the approver: <img src="/link/58ac32681f434a67856577062ab22700.aspx" /> The actual deployment steps for this stage look like this: <img src="/link/f20a1e2a00a743cdbcb338b973ea9f72.aspx" /> This allows the deployment to be validated before the swap to make sure it behaves as expected. Once it has been approved it's time to either reset (cancel the deployment) or complete the deployment (Go Live). Here I use a slightly different approach to fetch the deployment id compared to the previous stages. The "Fetch deployment id" step looks like this: <pre class="language-markup"><code>$rootPath = "$env:System_DefaultWorkingDirectory\_AWahlqvist.alloy-mvc-template\DXC Deployment Package\" if (-not (Get-Module -Name EpiCloud -ListAvailable)) { Install-Module EpiCloud -Scope CurrentUser -Force } $getEpiDeploymentSplat = @{ ClientSecret = "$(Production.ClientSecret)" ClientKey = "$(Production.ClientKey)" ProjectId = "$(ProjectId)" } $deploy = Get-EpiDeployment @getEpiDeploymentSplat | Where-Object { $_.Status -eq 'AwaitingVerification' -and $_.parameters.targetEnvironment -eq 'Production' } if (-not $deploy) { throw "Failed to locate a deployment to complete/reset!" } Write-Host "##vso[task.setvariable variable=DeploymentId;]$($deploy.id)"</code></pre> Instead of using the deployment id returned from the Start-EpiDeployment cmdlet, I instead fetch deployments that has the status of "AwaitingVerification" for the Production environment. Both approaches have their pros and cons and fit different scenarios. An obvious risk with this approach might be that you can't be 100% sure you reset/complete the deployment started by the build but has the benefit of always finding the ID of an ongoing deployment if it exists if that's the goal. <h2>Summary</h2> I hope this blog post has provided some guidance on how the new API and corresponding PowerShell module can be used to setup a CI/CD pipeline for your DXC project, if you have any questions or thoughts, please feel free to reach out in the comment section below! <img src="/link/e3a82f91baf844dc9a4235e3d5098cd7.aspx" />2019-10-29T20:02:30.0000000Z

Blog post

Using routing rules to validate a site before go live/swap (DXC Service)During a deployment in DXC Service a temporary slot is created where the new version of the site is pushed, prepared and <a href="/link/ce80e6dd766c40aeaa9be6b4f5d88430.aspx">warmed up</a>. If everything looks good during the manual validation step, it will finally be swapped with the previous version of the web app. The new version of the site is usually accessible via the following link: https://{webappname}-slot.dxcloud.episerver.net/ The recommendation is to have a default site with a "*" binding or at least add the hostname above in the site bindings of the CMS (see "<a href="/link/b80fa5168ac24c0b8a637eb779f09d42.aspx">Before going live</a>") to make this URL work, but what if you need to validate more sites before you feel comfortable swapping the deployment slot? Or if this binding just isn't added for some reason? Consider the following setup as an example: <img src="/link/1b499198e6c04be08be444a55b8ccf19.aspx" /> When trying to browse this site through the slot-address mentioned above, it would just respond with a 404 like this: <img src="/link/bfb6c7afc9ab4f388b999744099137ff.aspx" /> Some implementations might also expect certain host headers to be used which could make validation of the slot quite tricky. This is where routing rules can help! <h3>So what are routing rules? How can I use them?</h3> Routing rules is a Azure feature that makes it possible to route traffic via one of the hostnames assigned to the web app to one of its slots. During DXC Service deployments, the deployment engine will automatically attempt to configure routing rules for the slot so that any of the assigned hostnames can be tested in the slot, this is done just before the "warmup step" in the deployment. Before the slot is swapped (the complete/go live step), these rules are removed again. The rule is configured so that no production traffic is routed to the slot (100% to "production slot" and 0% to the deployment slot) while still allowing the routing rule to be used if a special cookie is added. Using a cookie to browse the slot using a custom hostname While there are actually two ways of triggering this behavior, using a cookie is the most reliable way. You simply need to add a cookie named "x-ms-routing-name" to your browser session with the value of the slot you want to browse (which for DXC Service deployments will be "slot"). The following example shows how it can be achieved in Chrome: <ol> <li>Browse the hostname you want to use, for example www.alloytech.biz (you might want to use "incognito"/"private"-mode to avoid having this cookie stored in your normal session after you've validated the slot, or make sure you remember to remove it) </li> <li>Press F12, go the the "Application"-tab and expand "Cookies on the left hand side: <img src="/link/186ae60fb92949ddb79ac029661334a4.aspx" /> </li> <li>Double-click under the last cookie in the list and enter "x-ms-routing-name" as the cookie name: <img src="/link/a49b05113ec44ffa935bf9c10d126b71.aspx" /> </li> <li>Enter the slotname in the "value" field for the new cookie, for DXC Service deployments, the name should simply be "slot": <img src="/link/bb9efb8b40404cca96a76073d7a852f1.aspx" /> </li> <li>Press Enter, and refresh the page and you will be browsing the slot using the hostname you entered in step 1!</li> </ol> It is also possible to use a query string to trigger this behavior, you simply add "?x-ms-routing-name=slot" to the address, however, this method isn't as reliable since requests issued by scripts on the site could still be routed to the "production slot", so it's recommended to use the "cookie method" instead. <h3>How are routing rules used during deployments then?</h3> During deployments in DXC Service, routing rules are used to check the status of <a href="/link/ce80e6dd766c40aeaa9be6b4f5d88430.aspx">the warmup process</a>, the deployment engine will look for a hostname to use in the application initialization-section of Web.config. If you want to check what hostname was used to validate the slot during the deployment you can check the deployment output log, after each site in the deployment has been warmed up the results are posted to the log which includes a "ManualValidationLink": <img src="/link/e1d3a7255c314edc9866386f05da23d8.aspx" /> This link can be used directly in the browser, but since the cookie method is more reliable, it's recommended to use that instead (but you could of course still find and copy the cookie name and value from this link!)2019-03-26T13:02:11.0000000Z

Blog post

Web application warmup during DXC Service deploymentsWhen deploying through the DXC Service Management Portal, warmup is both configured (when needed) and tested automatically as a part of the deployment. Since it's usually the most time-consuming part of a deployment, this blog post is aimed at providing a few more details on what's going on at this step and provide some information on how it can be done as quickly as possible. <h3>How is warm up configured for sites in DXC Service?</h3> During the first part of the deployment where code is copied and transformations are applied, the deployment engine will check if an <a href="https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-application-initialization">applicationInitialization</a>-section exists in Web.config, if it doesn't, it will be automatically created (more information about this is available <a href="/link/947015c1d514443b9d33caa03b953c2c.aspx">here</a>). Because of the way Application Initialization works on the underlying web server, some further configuration related to rewrite rules and redirects will be applied if needed as well to ensure that the warmup requests will be as effective as possible (a redirect response will be accepted in the same way as a 200 OK response by application initialization (and not "followed"), which means that a simple http to https redirect could render the whole application initialization configuration almost useless, therefor, rewrite rules are configured so that the application initialization requests are excluded from any redirects). Once the "code copy"-part of the deployment has finished, the warmup process will begin. <h3>What is happening during the warm up step?</h3> Autoscaling is first temporarily disabled before any warmup starts (making the current number of instances of the web app "fixed") to avoid any unnecessary scaleouts that could otherwise be triggered by the warmup process. After that the first part of a Azure web app "swap with preview" is initiated which ensures that the deployment slot created during the deployment process will be ready to receive production traffic after the swap is completed and avoid any restarts of the web app. Once that has finished the application initialization process will begin automatically within each individual instance of the web application. On top of this, the deployment engine will also perform a couple of checks to try to validate that this process works as expected. First, each individual instance's <a href="https://docs.microsoft.com/en-us/azure/app-service/overview-local-cache">local cache</a> status is verified to ensure the best possible performance and stability of the web app once it's swapped. The application initialization section is also analyzed to find a suitable hostname that can be used to poll the web app and its instances in the slot and check its response (whenever possible, a feature called <a href="/link/6ba35c7a2dde44daacc95c4fd8d42fe8.aspx">routing rules</a> is utilized to be able to use a "real" hostname to reach the deployment slot). Some of the things analyzed in the response are: <ul> <li>If the header "X-AppInit-WarmingUp" is returned, it means that the Application Initialization engine is still running</li> <li>Which web app instance that sent the response, if the response doesn't come from the same instance as the request was sent to, it indicates that the load balancer in Azure has redirected the request because the Application Initialization engine is still running</li> <li>If the request times out, or if the instance responds with errors, it could potentially indicate that the Application Initialization engine is still running and therefor the process will keep polling the site until the response changes or if a timeout value is met</li> </ul> Once all instances of the web app have been validated successfully (or if the timeout value has been met), the deployment will continue with re-enabling autoscaling and allow the site to be swapped after a manual validation. <h3>What can be done to speed this up?</h3> Local cache When it comes to local cache, the only thing that can be done to make this as quick as possible is to keep the web app file size as small as possible, it's otherwise an internal process in Azure that could potentially be affected by for example network congestion in the underlying infrastructure. Local cache can sometimes take only a few seconds to be ready, but it could also take several minutes. There is no guarantee that it will be ready on all instances at the same time, which is why the deployment engine will check all of them individually. Application Initialization The amount of time the application initialization process takes is highly dependent on the site and how quickly it starts, it's also affected by the number of links that have been added to the applicationInitialization-section of course, especially if each page takes a significant time to load (it's run sequentially). Configuring a minimal applicationInitialization-section to save time during deployment is of course not recommended since that could cause new instances to be slow in production instead, but it could of course potentially be a balance between being able to scale out faster or making sure that every single page on the web app has been warmed up. The logic used to create this section automatically during deployments have been tried and tested over thousands of deployments and has the primary goal of making sure that scale outs and potential restarts of instances will be as seamless as possible, so it's not recommended to create this section manually. Making sure that the site in the slot is able to respond with "200 OK" however could save several minutes since it allows the deployment engine to actually detect if the application initialization process has finished (the "X-AppInit-WarmingUp" header is only returned on succesful responses) instead of letting it try to validate this until it hits the timeout. At the time of writing this blog post, the timeout values are as follows: <ul> <li>If no warmup is detected (for example if the site just keeps responding with errors), it will wait for up to 10 minutes</li> <li>If warmup is detected for at least one instance, it will wait for a maximum time of 25 minutes</li> </ul> <h3>Why does this have to finish before I can swap the site?</h3> As part of the swap process Azure also tries to validate the slot before the swap is made, these checks includes things like warmup and local cache to ensure that the new slot will behave as it's supposed to after the swap. If these checks fail, it will simply block the swap request so there isn't really any point in trying until the site is ready. <h3>How can I know what took so much time in my latest deployment?</h3> The details of the warmup process for each individual instance is logged in the detailed deployment log which can be accessed by first opening the output log of the deployment and then click the "Get Detailed Log"-button (see "Deployment job log output" in <a href="/link/8211485cf8254701b1af4f75a205040c.aspx#joblog">this article</a>).2019-03-26T10:35:06.0000000Z

Blog post

Web application warmup during DXC Service deploymentsWhen deploying through the DXC Service Management Portal, warmup is both configured (when needed) and tested automatically as a part of the deployment. Since it's usually the most time-consuming part of a deployment, this blog post is aimed at providing a few more details on what's going on at this step and provide some information on how it can be done as quickly as possible. <h3>How is warm up configured for sites in DXC Service?</h3> During the first part of the deployment where code is copied and transformations are applied, the deployment engine will check if an <a href="https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-application-initialization">applicationInitialization</a>-section exists in Web.config, if it doesn't, it will be automatically created (more information about this is available <a href="/link/d3ec9948a8d74f6f83a730d44f337783.aspx">here</a>). Because of the way Application Initialization works on the underlying web server, some further configuration related to rewrite rules and redirects will be applied if needed as well to ensure that the warmup requests will be as effective as possible (a redirect response will be accepted in the same way as a 200 OK response by application initialization (and not "followed"), which means that a simple http to https redirect could render the whole application initialization configuration almost useless, therefor, rewrite rules are configured so that the application initialization requests are excluded from any redirects). Once the "code copy"-part of the deployment has finished, the warmup process will begin. <h3>What is happening during the warm up step?</h3> Autoscaling is first temporarily disabled before any warmup starts (making the current number of instances of the web app "fixed") to avoid any unnecessary scaleouts that could otherwise be triggered by the warmup process. After that the first part of a Azure web app "swap with preview" is initiated which ensures that the deployment slot created during the deployment process will be ready to receive production traffic after the swap is completed and avoid any restarts of the web app. Once that has finished the application initialization process will begin automatically within each individual instance of the web application. On top of this, the deployment engine will also perform a couple of checks to try to validate that this process works as expected. First, each individual instance's <a href="https://docs.microsoft.com/en-us/azure/app-service/overview-local-cache">local cache</a> status is verified to ensure the best possible performance and stability of the web app once it's swapped. The application initialization section is also analyzed to find a suitable hostname that can be used to poll the web app and its instances in the slot and check its response (whenever possible, a feature called <a href="/link/6ba35c7a2dde44daacc95c4fd8d42fe8.aspx">routing rules</a> is utilized to be able to use a "real" hostname to reach the deployment slot). Some of the things analyzed in the response are: <ul> <li>If the header "X-AppInit-WarmingUp" is returned, it means that the Application Initialization engine is still running</li> <li>Which web app instance that sent the response, if the response doesn't come from the same instance as the request was sent to, it indicates that the load balancer in Azure has redirected the request because the Application Initialization engine is still running</li> <li>If the request times out, or if the instance responds with errors, it could potentially indicate that the Application Initialization engine is still running and therefor the process will keep polling the site until the response changes or if a timeout value is met</li> </ul> Once all instances of the web app have been validated successfully (or if the timeout value has been met), the deployment will continue with re-enabling autoscaling and allow the site to be swapped after a manual validation. <h3>What can be done to speed this up?</h3> Local cache When it comes to local cache, the only thing that can be done to make this as quick as possible is to keep the web app file size as small as possible, it's otherwise an internal process in Azure that could potentially be affected by for example network congestion in the underlying infrastructure. Local cache can sometimes take only a few seconds to be ready, but it could also take several minutes. There is no guarantee that it will be ready on all instances at the same time, which is why the deployment engine will check all of them individually. Application Initialization The amount of time the application initialization process takes is highly dependent on the site and how quickly it starts, it's also affected by the number of links that have been added to the applicationInitialization-section of course, especially if each page takes a significant time to load (it's run sequentially). Configuring a minimal applicationInitialization-section to save time during deployment is of course not recommended since that could cause new instances to be slow in production instead, but it could of course potentially be a balance between being able to scale out faster or making sure that every single page on the web app has been warmed up. The logic used to create this section automatically during deployments have been tried and tested over thousands of deployments and has the primary goal of making sure that scale outs and potential restarts of instances will be as seamless as possible, so it's not recommended to create this section manually. Making sure that the site in the slot is able to respond with "200 OK" however could save several minutes since it allows the deployment engine to actually detect if the application initialization process has finished (the "X-AppInit-WarmingUp" header is only returned on succesful responses) instead of letting it try to validate this until it hits the timeout. At the time of writing this blog post, the timeout values are as follows: <ul> <li>If no warmup is detected (for example if the site just keeps responding with errors), it will wait for up to 10 minutes</li> <li>If warmup is detected for at least one instance, it will wait for a maximum time of 25 minutes</li> </ul> <h3>Why does this have to finish before I can swap the site?</h3> As part of the swap process Azure also tries to validate the slot before the swap is made, these checks includes things like warmup and local cache to ensure that the new slot will behave as it's supposed to after the swap. If these checks fail, it will simply block the swap request so there isn't really any point in trying until the site is ready. <h3>How can I know what took so much time in my latest deployment?</h3> The details of the warmup process for each individual instance is logged in the detailed deployment log which can be accessed by first opening the output log of the deployment and then click the "Get Detailed Log"-button (see "Deployment job log output" in <a href="/link/9b6c9ddb7ae54ebcbe1857d4f30ae984.aspx">this article</a>).2019-03-26T10:35:06.0000000Z

Blog post