dev4dxc-coursebook (1)

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Deployment environments Deployment and access information As part of the onboarding, the technical contact associated with your order receives an email form Episerver with the following information: • Default URLs for each of the environments included in your order. • Publish profile for Visual Studio, to be used when deploying to the Integration environment. A publish profile contains settings for publishing targets, databases to deploy, and other configurations. • Login credentials needed to log in to the Episerver environments. • Contact information for support from Episerver. Episerver Copyright © 2019 Episerver. All rights reserved. Page 68

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Deployment environments *Partners and customers will be able to self-manage deployments in the future. Deployment environments Website visitors Visitor Request Production to Website Environment Your responsibility CDN “Content Delivery” CDN 1. Create site and deploy it to Editors, Marketers 3 CDN Episerver Managed 4 Integration environment. Merchandisers Service Deploy Content Changes 2. QA test site in Preproduction Pre-Production environment. 2 Environment 3. Manage content in the QA 1 “QA/UAT/Staging” Production environment. Code / Config / Episerver Managed 4 Managed Services* responsibility DB Deploy Service Deploy 4. Deploy to Preproduction and Integration Production environments. Environment http://world.episerver.com/digital- Developers “Development” experience-cloud-service/deploying/ Episerver Copyright © 2019 Episerver. All rights reserved. Page 69

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Deployment environments Integration Partners and customers deploy their websites to the Integration environment, as regular builds or continuous releases. The Integration environment has fixed configuration and no automatic scaling. Developers can use the Integration environment to: • validate integrations with external systems, • perform functional testing, and • add initial content for a first-time deployment: /App_Data/DefaultSiteContent.episerverdata Additional Deployment Environment (optional, available for an additional cost) This is an Integration-like environment that is a replica of the primary Integration environment. The primary Integration environment is considered the \"master\" and is the only one that can be used to follow the standard deployment flow to Preproduction and Production. Common usage would be when there are multiple development streams running in parallel. Episerver Copyright © 2019 Episerver. All rights reserved. Page 70

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Deployment environments Preproduction and Production Good Practice Start UAT for performance as soon as you can. Episerver uses the Preproduction environment to: • test for meeting the SLA before Production deployment, and verify performance and operational functionality. Developers should use the Preproduction environment for: • User Acceptance Testing (UAT), Each of the three environments will have their own Episerver • performance and load testing, Find index. In a multisite scenario the sites share the same • approved penetration testing. index, but each individual site will have their own partition of the index, as well as a shared partition for shared content. In the Production environment: • content editors will author content, using the Episerver content publishing flow or Projects, and • visitors can access public content. Episerver The Preproduction and Production environments scale automatically and use minimum of S1 instances for App Service and SQL Database. Integration environment might use S0s. You need to contact Episerver to register a ticket to initiate deployment to Preproduction and Production environments, since this can only be done by Episerver. All instances in the Production environment are identical, so you cannot follow Episerver’s recommended practice for on premise deployment, i.e., for extra security, create a server for editors and admins that is separate from the load balanced servers used by visitors. Copyright © 2019 Episerver. All rights reserved. Page 71

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Deployment environments Scheduled jobs in deployment environments We configure enableScheduler=\"false\" for the App Service instances that serve visitor requests, and create separate App Service instances dedicated to scheduled jobs. They have the same codebase and configuration as the primary ones, except enableScheduler=\"true\" • Set the IsStoppable property to true and implement the Stop() method. • Configure the job as Restartable and implement checkpoint and resumption tracking. Episerver Scheduled jobs with Azure’s auto healing feature If you use a scheduled job to do heavy CRUD syncing of data, for example, for an Episerver Commerce catalog, then beware of Azure’s proactive auto healing feature. This will spot VM instances that use excessive memory and kill them, aborting the scheduled job. To mitigate this, developers can write code in a way that avoids overuse of memory, or ask Episerver to disable Azure’s auto heal feature, or ask Episerver to enable additional VMs for scheduled jobs if we haven’t already spotted the issue and done so automatically. Announcing the New Auto Healing Experience in App Service Diagnostics https://blogs.msdn.microsoft.com/appserviceteam/2018/09/10/announcing-the-new-auto-healing-experience-in- app-service-diagnostics/ Scheduled jobs in the DXC & The Autoheal Policy & Architecture https://world.episerver.com/blogs/scott-reed/dates/2018/11/scheduled-jobs-in-the-dxc--the-autoheal-policy/ Copyright © 2019 Episerver. All rights reserved. Page 72

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Deployment process Deploying an Episerver site to Azure To deploy an Episerver website project to Azure, you must: 1. Install the EPiServer.Azure NuGet package in your Episerver Web Site project. 2. Create Azure resources (with DXC Service this is done for you). 3. Transform the Episerver Web Site’s configuration*: a. Database connection string (from local database to SQL Database) b. Blob provider (from local file system to Azure Storage) *Some values like connection strings c. Remote Events provider (from WCF to Azure Service Bus) can be controlled through the Azure d. Indexed search provider (for example, from Search to Find) Portal as Application Settings. These 4. Deploy code, data, and blobs to Azure resources. would override values in Web.config. Episerver What Managed Services does for you • Set up of environments • First-time deployment of code, content and configuration to Preproduction and Production. • Initial troubleshooting and roll-back if issues arise. • Continuous deployment of code to Preproduction and Production after go-live. • Deployment of production content back to Preproduction and Integration. You can purchase additional Integration environments but they won’t be part of the deployment chain. Copyright © 2019 Episerver. All rights reserved. Page 74

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Deployment process Deployment process – step-by-step Users Managed New Code services 1. Users (visitors and editors) are interacting NeWw eWbeAbpAppp Configuration with the Production website. Slot transform Azure SQL 2. Developer uploads new code to Integration database Production environment, uses PaaS to deploy and test in Preproduction, then raises a support ticket. 3. Managed Services: a) Copies new code from Preproduction to a Production slot. b) Applies configuration transforms to slot. c) Starts website in the slot, warmup and verify. d) Swaps the slots. e) Users interact with new Production website. Episerver It can take longer to deploy new code into Preproduction or Production than you are used to. Initially you may find this process annoying, but it's a good thing. It guarantees that deployments are always done in a consistent manner and Episerver takes responsibility for the application’s SLA. When you're ready to deploy to Production or Preproduction, you send a deployment ticket to our Managed Services department who (1) create a backup of the existing environment, (2) moves the code to Preproduction, (3) runs tests to make sure your code meets SLAs. We have people who only do deployment, and they usually get to work on it within an hour. How long it takes to check the code depends on the solution. An upgrade that involves data migration might take 24 hours. We can also deploy production data back to the other environments. This makes it really easy for developers or QA to work with real data in those environments without adding much work to their day. You can also specify a time window for deployment, for example, if you have an online store and don't want to deploy when you have a lot of visitors. Copyright © 2019 Episerver. All rights reserved. Page 75

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Deployment process Create a custom maintenance page To take an ASP.NET Web Application temporarily offline you can create a file named app_offline.htm in the root of a website. The application’s AppDomain will be unloaded and the contents of the static file displayed instead of any response along with a status code of 503 (Server Unavailable). • Warning! Versions of Internet Explorer older than 8.0 give a missing file error with small app_offline.htm files, so add about a screen full of HTML comments to make it big enough (it must be more than 512 bytes)! DXC has a similar feature that is only needed if an application update does something to the database. Add an HTML page called maintenancepage.htm in the root directory of your application, and it will be used during deployments that update the database. The file must be less than 1 MB and resources like stylesheets and script must be embedded in the file or use resources hosted outside DXC Service. Episerver Setting hostnames for all environments Add all hostnames to the production database for integration and staging/test environments as well. This will make it much easier if you need to copy the content down to Preproduction and Integration. Copyright © 2019 Episerver. All rights reserved. Page 76

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – PaaS portal PaaS portal for customers and partners PaaS portal sets up the Azure services, Episerver software and services including Find, CDN, monitoring, and more. It is a provisioning and deployment tool intended to simplify, standardize, and streamline our managed service and operational processes. The PaaS portal is available for use by customers and partners to manage your own DXC Service environments. It has these features: • One-click and scheduled deployments, including validations during deployments • Deployment progress and details • Today, it enables deployments from Integration to Preproduction. • Configuration transforms • In future, we plan to enable deployments from Preproduction to Production. • Set maintenance page • Error handling and logging, including streaming of logs from all environments https://world.episerver.com/dxc-service-self-deployment-guide/ Episerver View the live log stream, or generate a download link. Copyright © 2019 Episerver. All rights reserved. Page 77

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – PaaS portal PaaS portal user interface Performing deployments Viewing application logs Episerver View output during deployment process in PaaS portal. Copyright © 2019 Episerver. All rights reserved. Page 78

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Building and deploying manually Visual Studio Publish – Issue with transformations As a general rule, never perform deployment manually! Always use an automated tool like Octopus. If you do use a manual tool, one of the most frequently used is Publish, built in to Visual Studio, but it’s convenience has some traps to be aware of. DXC Service allows you to create configuration transformation files. These include a name as part of the file extension, for example, Web.Release.config. The problem is that Publish refuses to deploy these files! Even if you explicitly include the file in a project using the GUI, Publish has been hard-coded to explicitly exclude them! This means that if you have created a Web.Integration.config it will not be deployed with Publish. In Exercise B1, you will learn how to get around this problem by manually editing the .csproj file to break the dependency on Web.config so Publish treats the configuration transformation files like any other content file. Episerver Copyright © 2019 Episerver. All rights reserved. Page 80

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Building and deploying manually Visual Studio Publish – Issue with removing old files A second potential trap with Publish, is that it has an option to Remove additional files at destination. This is good practice because it means there won’t be any files left over from previous deployments that interfere with the new deployment. But DXC Service environments have some files that we deploy for you like License.config. If those files are deleted, then DXC Service breaks, and you will have to raise a support ticket for us to redeploy those special files! Luckily, we can configure to allow the use of this option without deleting these extra files (see Notes uEpnisedrveer r this slide). When using the setting Remove additional files at destination, edit either the publish profile or project file to configure Publish to ignore special folders during deletion, as shown in the following markup: <PropertyGroup Condition=\" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' \"> <AfterAddIisSettingAndFileContentsToSourceManifest>AddCustomSkipRules</AfterAddIi...> <Target Name=\"AddCustomSkipRules\"> <ItemGroup> <MsDeploySkipRules Include=\"SkipFilesFolder\"> <AbsolutePath>newrelic</AbsolutePath> </MsDeploySkipRules> </ItemGroup> </Target> </Project> Copyright © 2019 Episerver. All rights reserved. Page 81

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Continuous integration (CI) and delivery (CD) Continuous Integration Build and deployment tools – TeamCity and Octopus or Azure DevOps Build You can use any build and deployment tools that works with Azure Resource Manager (ARM), for example Octopus Deploy and TeamCity, or Azure DevOps Unit Tests Services (previous known as Visual Studio Team Services). TeamCity is a build server and Octopus is a deploy server, and they are typically Integration Tests part of the build and deploy process for many of our partners. UAT/Performance http://world.episerver.com/articles/Items/continuous-deployment-of-episerver-solutions/ Production Octopus version 3.3 or later works with Azure RBAC (Role Bases Access Control): Continuous https://octopus.com/company/roadmap Delivery AppVeyor is another build server you might want to look at. It includes a built-in deployment and NuGet server: https://www.appveyor.com/ Episerver Ensure that the modules and modulesbin folders are included in the project so that these are published as well. Copyright © 2019 Episerver. All rights reserved. Page 83

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Continuous integration (CI) and delivery (CD) Octopus deployments DXC Service environments Preproduction Octopus works with your build server to enable reliable, secure, automated Integration Production releases of ASP.NET applications and Windows Services into test, staging Managed and production environments, Services or you whether they are in the cloud or on- can use self- premises. manage portal. https://octopus.com/ Episerver Continuous deployment with Octopus In the steps below, we will configure Octopus to automatically create a release and deploy to DXC Integration environment, each time the project is built: 1. Creating a project account - done for each new customer project. 2. Configuring Octopus - done once if you use the same deployment process. 3. Configuring Visual Studio - done for each new customer project. 4. Setting up the deployment process - done once if you use the same process. Continuous deployment of Episerver solutions http://world.episerver.com/articles/Items/continuous-deployment-of-episerver-solutions/ If you have set up your deployment tool as described above, code changes and Episerver updates done by your team will be pushed to your build and deploy servers, whenever you build. From there, a release will be automatically created (if you selected that option), and pushed to the Integration environment in the Azure cloud. If you are new to using Octopus, we suggest reading the getting started guide: http://docs.octopusdeploy.com/display/OD/Getting+started Copyright © 2019 Episerver. All rights reserved. Page 84

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Continuous integration (CI) and delivery (CD) Azure DevOps Services deployments Continuous integration and delivery in Azure DevOps Services simplifies setting up a robust deployment pipeline for your application. Azure Repos stores your source (or use something else). Azure Pipelines builds, runs tests, and deploys your code to your DXC Service Integration environment. You can easily extend this deployment automation to handle any other operations your application requires during deployment, for example, functional tests to validate features, provision additional Azure resources, run scripts or upgrade your database. Warning! We recommend that you disable parallel processing in the NuGet Restore process or you might get random timeout errors, as shown in the Notes section under this slide. Episerver Configuring VSTS Releases From a single package to work with New Relic on the DXC https://world.episerver.com/blogs/scott-reed/dates/2017/12/configuring-vsts-releases-from-a-single-package- to-working-with-new-relic-on-the-dxc/ Example of a timeout error when parallel processing is enabled Copyright © 2019 Episerver. All rights reserved. Page 85

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Configuration transformations Understanding Web.config transformations A local development Web.config might look like this while developing: <connectionStrings> <system.web> <add name=\"MyDB\" <compilation debug=\"true\" ... connectionString=\"Data Source=TestServer;...\" During deployment we would want to change the database connection string to connect to a production server and we would want to remove the debug attribute from compilation. Create a Web.Release.config transformation file and choose Release configuration when deploying: <connectionStrings> <system.web> <add name=\"MyDB\" <compilation xdt:Transform=\"RemoveAttributes(debug)\" /> connectionString=\"Data Source=ProductServer;...\" xdt:Transform=\"SetAttributes\" xdt:Locator=\"Match(name)\" Episerver Web.config Transformation Syntax for Web Project Deployment Using Visual Studio https://msdn.microsoft.com/en-us/library/dd465326(v=vs.110).aspx Copyright © 2019 Episerver. All rights reserved. Page 87

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Configuration transformations DXC Service Web.config transformations With DXC Service, you can create additional transformation files named for the three environments: • Web.Integration.config, Web.Preproduction.config, Web.Production.config. If you have Web.config files at multiple levels/folders that needs transformation, just make sure you add a transform file next to each one. These transformation files can form a chain, so the Production one can make changes to the results of applying the Preproduction one. To make applicationHost transforms: • Integration: applicationHost.xdt • Preproduction: applicationHost-Preproduction.xdt • Production: applicationHost-Production.xdt Episerver Use case example for applicationHost transforms You could make your Web App in DXC Service act as a proxy, forwarding requests from company.com/blog to company.bloghost.com like this: <rules> <rule name=\"Proxy\" stopProcessing=\"true\"> <match url=\"^blog/?(.*)\"/> <action type=\"Rewrite\" url=\"http://company.bloghost.com/{R:1}\"/> </rule> </rules> https://world.episerver.com/blogs/david-buo/dates/2017/11/support-for-applicationhost- transforms-in-dxc-service/ Copyright © 2019 Episerver. All rights reserved. Page 88

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Configuration transformations Configuration transformations for connection strings and providers You will want to change the database connection to use Azure SQL database instead of LocalDb: <connectionStrings> <add name=\"EPiServerDB\" connectionString=\"{...}\" xdt:Transform=\"SetAttributes\" xdt:Locator=\"Match(name)\"/> You could also define Web.config entries for blobs and events, but during the Module B exercises you will instead define the connection strings in the Application settings for the App Service in Azure Portal, which is how DXC Service does it. Episerver The following is a typical partial Web.Integration.config transformation file: <episerver.framework> <blob defaultProvider=\"azureblobs\" xdt:Transform=\"Insert\"> Container will be manually created <providers> by you and blobs uploaded to it. <add name=\"azureblobs\" container=\"dxcalloy-assets\" type=\"EPiServer.Azure.Blobs.AzureBlobProvider,EPiServer.Azure\" connectionStringName=\"EPiServerAzureBlobs\" /> </providers> </blob> <event defaultProvider=\"azureevents\" xdt:Transform=\"Insert\"> Topic will be created automatically <providers> <add name=\"azureevents\" topic=\"DxcAlloyEvents\" by Episerver initialization process. type=\"EPiServer.Azure.Events.AzureEventProvider,EPiServer.Azure\" connectionStringName=\"EPiServerAzureEvents\" /> </providers> </event> Copyright © 2019 Episerver. All rights reserved. Page 89

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Configuration transformations Examples of common transformations To get detailed ASP.NET error messages while testing in the <customErrors mode=\"Off\" ... Integration environment set custom errors Off in Web.Integration.config: <customErrors mode=\"On\" ... Make sure custom errors is set back On in Preproduction and See the Notes under this slide for Production by using a Web.Preproduction.config transform file: an example of configuring email. When deploying Commerce Manager between different environments, use transform files to update Commerce Manager links specifically for each environment. For example, for deploying to Preproduction the Web.Preproduction.config transform file would include this: Episerver <appSettings> <add key=\"CommerceManagerLink\" value=\"{LinkToCommerceManager}\" xdt:Transform=\"SetAttributes\" xdt:Locator=\"Match(key)\" /> Configuring the email server In order for Episerver to send out email notifications, you need to configure your email server with a server endpoint that is reachable from the site, and is allowed to send emails using a specified from-address. Episerver will set up a an email service account for you, and the required host, username and password will be provided. <system.net xdt:Transform=\"InsertIfMissing\"> <mailSettings> <smtp from=\"[email protected]\"> <network host=\"[provided by Episerver]\" password=\"[provided by Episerver]\" userName=\"[provided by Episerver]\" port=\"[587, 465, 25 or 2525]\" /> Copyright © 2019 Episerver. All rights reserved. Page 90

Module B – Deploying to DXC Service – Configuration transformations Restricting environment access Pattern matches: *inte.* and *prep.* e.g. • custom12a3binte.dxcloud.episerver.net • custom12a3binte.azurewebsites.net • custom12a3bprep.dxcloud.episerver.net • custom12a3bprep.azurewebsites.net You might want to lock down environments such as Integration and Preproduction, or UIs such as Edit or Admin view in Production, but since all traffic flows through the CDN, IP restrictions cannot be used to achieve this because only the IPs of the CDN nodes are visible to this feature. <system.webServer> <rewrite> <rules> <rule name=\"Block unauthorized traffic in integration and preproduction\" stopProcessing=\"true\"> <match url=\".*\" /> <conditions> <add input=\"{HTTP_HOST}\" pattern=\"inte\\.|prep\\. \" /> <add input=\"{HTTP_True_Client_IP}\" pattern=\"88\\.250\\.74\\.6\" negate=\"true\"/> </conditions> <action type=\"CustomResponse\" statusCode=\"403\" statusReason=\"Forbidden\" statusDescription=\"Site is not accessible\" /> Episerver The implementation of an ipSecurity section in web.config is not supported because it will not work reliably in DXC-S. https://world.episerver.com/digital-experience-cloud-service/dxc-security/restricting-environment-access/ {HTTP_HOST} This is the hostname of your Web App as entered by the user browsing it, such as mywebapp.azurewebsites.net or www.mydxcsite.com. The {HTTP_HOST} supports matching by pattern. {HTTP_True_Client_IP} Contains the originating IP address of a client connecting to your site through the CDN. Supports matching by pattern. <system.webServer> <rewrite> <rules> <rule name=\"Block logins and dashboard in production\" stopProcessing=\"true\"> <match url=\"login.aspx|/episerver\" /> <conditions> <add input=\"{HTTP_HOST}\" pattern=\"www\\.mydxcsite\\.com|prod\\.\" /> <add input=\"{HTTP_True_Client_IP}\" pattern=\"88\\.250\\.74\\.6\" negate=\"true\"/> </conditions> <action type=\"CustomResponse\" statusCode=\"403\" statusReason=\"Forbidden\" statusDescription=\"Site is not accessible\" /> </rule> </rules> </rewrite> You can use any server variable or HTTP header when you create these rules. For information about matching the different parts of a URL with these rules: https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/url-rewrite-module-configuration- reference#Accessing_URL_Parts_from_a_Rewrite_Rule Page 91

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Troubleshooting Debugging in the Integration environment Debugging of code and functionality should always be done in the Integration environment. Ensure that your Integration configuration includes the full PDB, otherwise you will be able to attach to the remote process but not set breakpoints or handle exceptions with Visual Studio. http://world.episerver.com/digital-experience- cloud-service/troubleshooting/ Before deploying to Preproduction, remove reset debugging information to None and re-deploy to Integration for best performance. Episerver Debugging recommendations and tips • Running in debug mode in production is not recommended. If your production web app is not scaled out to multiple server instances, debugging will prevent the web server from responding to other requests. • Avoid long stops at breakpoints when remote debugging. Azure treats a process that is stopped for longer than a few minutes as an unresponsive process, and shuts it down. • While you're debugging, the server is sending data to Visual Studio, which could affect bandwidth charges. • A timer starts on the server when you enable the remote debugging feature, and after 48 hours the feature is automatically turned off. This 48 hour limit is done for security and performance reasons. You can easily turn the feature back on as many times as you like. • You can manually attach the debugger to any process, not only the web app process (w3wp.exe). Copyright © 2019 Episerver. All rights reserved. Page 93

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Troubleshooting Logging in Azure App services An ASP.NET application that runs in an Azure App Service can create the following kinds of logs: • Application tracing logs: The application creates these logs by calling methods of the System.Diagnostics.Trace class. • Web server logs: The web server creates a log entry for every HTTP request to the web app. • Detailed error message logs: The web server creates an HTML page with some additional information for failed HTTP requests (those that result in status code 400 or greater). • Failed request tracing logs: The web server creates an XML file with detailed tracing information for failed HTTP requests. The web server also provides an XSL file to format the XML in a browser. Logging affects web app performance, so Azure gives you the ability to enable or disable each type of log as needed. For application logs, you can specify that only logs above a certain severity level should be written. Episerver Server Explorer – App Service – View Settings One of the benefits of the Server Explorer compared to Cloud Explorer is the ability to view and modify App Service settings from Visual Studio. Right-click an App Service and choose View Settings, as shown in the following screenshot: Copyright © 2019 Episerver. All rights reserved. Page 94

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Troubleshooting Logging in DXC Service DXC Service redirects all Episerver logs into .NET Diagnostic Trace, as long as the code uses the Episerver logging abstraction EPiServer.Logging.LogManager. If you are using log4net and deploying to DXC, replace log4net with EPiServer.Logging http://world.episerver.com/documentation/developer- guides/CMS/logging/logging-into--net-diagnostics-trace/ http://world.episerver.com/documentation/developer-guides/CMS/logging/ Use the download/FTP options available in Azure Portal under Diagnostics logs for the environment to download the logs: Good Practice Make sure logging is configured as early as possible in the project. Episerver Activate logging DXC Service allows writing to the diagnostics log using BLOB storage. In the Azure portal, for the Integration environment Web App, under Diagnostics logs, enable Application Logging (Blob) and choose an appropriate Level e.g. Error. Use the download/FTP options to download the logs. You can use Kudo by adding \"scm\" to the environment URL, for example: https://appname.scm.azurewebsites.net/ Copyright © 2019 Episerver. All rights reserved. Page 95

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Troubleshooting Application Insights with DXC Service Application Insights (AI) is configured automatically for all sites in DXC Service, but depending on the site architecture, some further configuration might be needed to fully utilize its features. If you use NLog, log4Net or System.Diagnostics.Trace for diagnostic tracing in your ASP.NET application, you can have your logs sent to AI, where you can explore and search them. Your logs will be merged with the other telemetry coming from your application, so that you can identify the traces associated with servicing each user request, and correlate them with other events and exception reports. Explore .NET trace logs in Application Insights https://docs.microsoft.com/en-us/azure/application-insights/app-insights-asp-net-trace-logs Episerver Common performance issues When there is a difference in performance between a local on-premise environment and Azure, the cause is frequently that an SQL command is slower in Azure SQL than in local SQL Server. There are certain query constructs that are slower in Azure SQL that you should avoid. Any functionality that does a lot of 'chatting' with the database tends to get worse in Azure. Copyright © 2019 Episerver. All rights reserved. Page 96

Module B – Deploying to DXC Service – Troubleshooting Application Insights settings and customer access Episerver adds the following to Application Settings in each environment: • APPINSIGHTS_INSTRUMENTATIONKEY: instrumentation key for each environment’s Application Insights account. • APPINSIGHTS_JAVASCRIPT_ENABLED: true, to collect information about page views and user telemetry. Partners and customers get access to Application Insights in all environments by adding your account to a custom role called \"Application Insights Limited Contributor\" that provides read-only access to the Application Insights accounts. With this you can: • Browse and search in telemetry, and perform advanced querying in Analytics • Not enabled: Creating alerts, exporting data, availability testing, performance testing, API access. How Application Insights recognizes returning users and efficiently send telemetry data to Azure 97 https://www.patrickvankleef.com/2018/02/07/application-insights-user-telemetry-data-send-to-azure/ Episerver Page 97

Module B – Deploying to DXC Service – Troubleshooting Run time and build time instrumentation By default, all sites in DXC-S use run time instrumentation. This does not require any changes to your code, but no log messages get stored in AI. The logs will only be in the DXC-S Management Portal. To use all AI features, you must enable build time instrumentation by installing Application Insights SDK. This consists of two NuGet packages: • Microsoft.ApplicationInsights.Web to collect telemetry, and • Microsoft.ApplicationInsights.TraceListener to get the logs. https://docs.microsoft.com/en-gb/azure/azure-monitor/app/monitor-performance-live-website-now To call AI directly so that you can put relatively long data in the message, like encoded POST data: var telemetry = new Microsoft.ApplicationInsights.TelemetryClient(); telemetry.TrackTrace(\"Slow response - database01 - ...\"); Episerver Application Insights Instrumentation Key If you already have your own Application Insights settings via ApplicationInsights.config file, when you deploy your site to DXC-S, note that your Instrumentation Key will be overridden by that of the Application Insights resource provisioned by DXC-S. This means that any custom logs or telemetry information that you are adding will now be saved to Application Insights resource provisioned by DXC-S. Application Insights logging adapters https://github.com/Microsoft/ApplicationInsights-dotnet-logging#systemdiagnostics Page 98

Episerver – Developing for DXC Service Module B – Deploying to DXC Service – Troubleshooting Single Page Application (SPA) considerations By default, page views are tracked when a new page loads into the browser. SPA sites will load pages dynamically and additional code is needed to track page views. After adding Microsoft’s client-side JavaScript, this code is used to track a custom page view: if (typeof appInsights !== 'undefined') { appInsights.trackPageView(myPageName); } Application Insights for web pages https://docs.microsoft.com/en-us/azure/application- insights/app-insights-javascript Episerver Add Application Insights to an Angular SPA The following steps are specifically targeted at the front-end developers building with Angular and TypeScript that want to start tracking their Single Page Applications. https://blogs.msdn.microsoft.com/premier_developer/2017/05/11/add-application-insights-to-an-angular-spa/ Copyright © 2019 Episerver. All rights reserved. Page 99

Episerver – Developing for DXC Service Module B – Deploying to DXC Service Exercises for Module B (120 minutes) 1. Transforming Web.config (20 mins): write transformations to configure environments. 2. Manually deploying with Visual Studio Publish (30 mins): handle the issue of transformation files not deploying. 3. Debugging remotely and monitoring with Application Insights (30 mins): use Visual Studio tools to remotely debug your site, enable logging, trigger some issues, and monitor the logs. 4. Continuous integration and delivery (45 mins): configure Azure DevOps Services to Episervebr uild, test, and deploy your site. Copyright © 2019 Episerver. All rights reserved. Page 100

Episerver – Developing for DXC Service Module C – Development Considerations Module C Development Considerations In this module, you will learn how to write code to follow recommended good practice and cloud design patterns to ensure success for a DXC Service project. Episerver Copyright © 2019 Episerver. All rights reserved. Page 105

Episerver – Developing for DXC Service Module C – Development Considerations Module agenda Hosting your site in DXC Service, or any cloud environment, requires new coding strategies. Follow these recommendations to ensure smooth development experience and site reliability and scalability. • Multi-sites • Exercises C1 to C4 • Asynchronous operations • Caching • Exercise C1 – Improving scalability with asynchronous operations • Controlling the Content Delivery Network • Exercise C2 – Controlling the caching of • App service environment responses • Data storage • Transient fault handling • Exercise C3 – Handling transient faults • Cloud design patterns • Exercise C4 – Implementing queue-based patterns • Integrating other Azure services Episerver Copyright © 2019 Episerver. All rights reserved. Page 106

Episerver – Developing for DXC Service Module C – Development Considerations – Multi-sites Implications and benefits of multi-sites You can only run one ASP.NET Web Application project (aka code base) for each package in a DXC Service solution, however you can have up to 500 Episerver sites in that application. The sites will share the same code base and the same Find index. Multi-sites is a very popular feature because previously you had to pay for this. You can launch campaign or other related sites easily, not having to think about extra licenses or associated costs. A single Web App with multi-sites: • allows you to follow best practices for object-oriented code reuse, • makes development, upgrading, testing and deployment easier, • reduces cost, • less complexity, and • requires shared content, users, and shopping carts across web sites. Episerver Episerver CMS is multi-tenant, meaning that a single running instance of the Episerver CMS can host multiple websites using a shared database and code base. We call this multi-site. Websites in a multi-site setup can share the same content assets, such as media files and blocks. You also can have site-specific content folders for content that should not be shared between sites. You have a single CMS site as a base (default site) and let an administrator create additional new sites that share the same root page, database, and code base. The additional sites are automatically mapped and require no additional configuration (if the base site is mapped to wild card), or need manual configuration of the host name. http://world.episerver.com/documentation/developer-guides/CMS/Deployment/Setting-up-multiple-sites/ http://world.episerver.com/Blogs/Johan-Bjornfot/Dates1/2013/12/Multisite-feature-in-EPiServer-75/ Securing multi-sites If the sites are administered by different editors, be sure to set the rights so that they don’t have access to confidential information or publish on each other’s websites by mistake. If you have one site per brand/concept, then create one role/group per site: • BrandARole, • BrandBRole, and so on. A content editor for a single brand/concept could then be added to both CmsEditors and BrandARole to have access to only BrandASite. https://www.cjsharp.com/blog/2018/09/28/architecting-multi-site-episerver-solutions/ Copyright © 2019 Episerver. All rights reserved. Page 108

Episerver – Developing for DXC Service Module C – Development Considerations – Multi-sites Designing your code base for multi-sites – different models and controllers Since the code base is shared in a multi-site scenario, here are some suggestions how to create a Web Application with each site having different models (including page, block, and media types). • Define one abstract base site page type and one Start Page type for each site. • Apply [AvailableContentTypes] to each Start Page to restrict which page types are allowed underneath that Start Page. • Apply [AllowedTypes] to content type properties that should only allow a subset of page, block, and media types. • Remember that assets like media and blocks can be stored in the For This Site folder. Episerver Designing your code base for multi-sites – shared models, controllers, databases Alternatively, keep the amount of content types down, make them as generic as possible (having several content areas), and have flexible blocks to allow different layouts. Have shared models and controllers, but different views. For example, Varner Group has five concepts (aka retail store brands) that share the same set of content types and controllers but different views. Use a UI framework like Bootstrap (or something more lightweight) that helps in giving them different style while still using consistent mark-up. Brand A Brand B Brand C Brand D Brand E Shared views views views views views Commerce Manager site Shared content types and controllers Shared CMS and Commerce databases Copyright © 2019 Episerver. All rights reserved. Page 109

Episerver – Developing for DXC Service Module C – Development Considerations – Multi-sites Episerver Personalization and Episerver Find with multi-sites Multi-sites within the same code base have access to the same Visitor Groups. Ensure that members of VisitorGroupAdmins and WebEditors who define and create personalized content have been given training or documentation to know which to use. There is currently no mechanism to enforce separation of the definition and usage of visitor groups per site. We encourage you to look at Episerver Personalization products such as Episerver Advance (for content recommendations) and Episerver Perform (for product recommendations) to implement omnichannel machine learning-based personalization in combination with Visitor Groups. http://www.episerver.com/personalization/omnichannel-personalization/ In a multi-site scenario the sites share the same Find index, but each individual site will have their own partition of the index, as well as a shared partition for shared content. The behavior of Episerver Find changed in version 9 and later to automatically filter by site by calling FilterOnCurrentSite() by default. Episerver Control how Categories are shared across multi-sites Episerver has a built-in concept of hierarchical categories, aka tags, that can be associated with any content. CMS categories are shared between multi-sites, so use category hierarchies for site-specific categories or define your own category system. This property is on every page. Copyright © 2019 Episerver. All rights reserved. Page 110

Episerver – Developing for DXC Service Module C – Development Considerations – Multi-sites Control how Forms, display channels, and display options are shared Since all Episerver Forms will be available across all sites, you should apply access rights on form folders to restrict access. You could create a virtual role for restricted Forms: http://world.episerver.com/documentation/developer-guides/CMS/security/Virtual-roles/ Display channels and display options are active across all sites so consider how to manage these if different websites have different requirements. You could write DisplayChannel classes that detect which site is being used to customise if the channel should be active. Display Options http://world.episerver.com/documentation/developer-guides/CMS/rendering/display-options/ Display Channels http://world.episerver.com/documentation/developer-guides/CMS/rendering/display-channels2/ Episerver Control how Add-ons are shared across multi-sites Installed add-ons will be available across all sites, but you can restrict access through configuration. Set access rights on the location paths in config, to ensure that they cannot be reached by unauthorized users accessing the page directly. Copyright © 2019 Episerver. All rights reserved. Page 111

Episerver – Developing for DXC Service Module C – Development Considerations – Asynchronous operations Understanding asynchronous operations Asynchronous operations enable your web server to perform more efficiently and reliably under high load conditions. If your application code doesn’t handle tasks like database queries and web service calls asynchronously, threads are unnecessarily tied up while the server is waiting for an I/O response. To make an action method asynchronous: instead of returning an ActionResult object, you return Task<ActionResult> and mark the method with the async keyword. Inside the method, when a line of code kicks off an operation that involves wait time, you mark it with the await keyword. public async Task<ActionResult> Index() { string currentUser = User.Identity.Name; var result = await fixItRepository.FindOpenTasksByOwnerAsync(currentUser); return View(result); } Episerver Copyright © 2019 Episerver. All rights reserved. Page 113

Episerver – Developing for DXC Service Module C – Development Considerations – Asynchronous operations Entity Framework and asynchronous operations Microsoft has a guideline that any method call that could take more than 50 nanoseconds should have an async equivalent that returns a Task<T>. If you use the Entity Framework 6 or later to manage data, and you import the System.Data.Entity namespace, then the following methods are awaitable: • FindAsync() • ToListAsync() • SaveChangesAsync() Entity Framework Async Query and Save (EF6 onwards) https://msdn.microsoft.com/en-us/library/jj819165(v=vs.113).aspx Episerver Copyright © 2019 Episerver. All rights reserved. Page 114

Episerver – Developing for DXC Service Module C – Development Considerations – Asynchronous operations Episerver and asynchronous operations Episerver’s APIs have limited async operations. Newer APIs like those for working with Projects and Content Approvals include async operations, but older APIs do not. For methods like IContentLoader.Get<T>() this is not a problem because mostly you will be accessing the content from the object cache rather than the database anyway, but if you are doing a lot of IContentRepository.Save() calls then it would be good to have a SaveAsync() equivalent. For controller classes, for now you must create your own like this: public abstract class AsyncBlockController<TContentData> : ActionControllerBase, IRenderTemplate<TContentData> where TContentData : IContentData { public abstract Task<ActionResult> Index(TContentData currentContent); } Episerver Copyright © 2019 Episerver. All rights reserved. Page 115

Episerver – Developing for DXC Service Module C – Development Considerations – Caching Understanding the types of caching • Object (aka page) caching: when a content item is requested it is loaded from the database and stored in the object cache on the website server for a minimum of 12 hours (by default). <episerver> <applicationSettings pageCacheSlidingExpiration=\"12:00:00\" The object cache uses in-proc memory by default, but it can be configured to use other providers, for example Redis, for highly performant distributed caching. • Output caching: when an HTTP response is returned from the server, it can be cached. To enable it, (1) apply [ContentOutputCache] and configure <applicationSettings> in Web.config, or (2) write code to control the Response.Cache object. CDN and Browser caching: CDNs and browsers look at the HTTP response headers to determine what and how long to cache. Control this through output caching. Episerver http://world.episerver.com/documentation/developer-guides/CMS/caching/ Object Cache • Based on the ASP.NET Cache. • Automatically caches all objects in Episerver CMS that is being requested from the API, via for example IContentRepository. • Only read-only objects are stored to enable great performance. • Has a few advanced characteristics to improve scalability. For example, it uses an optimistic locking approach when multiple threads are reading the same data they will all piggyback on the same database calls to avoid putting to much load on the database for “hot” objects that have not yet been cached. Types of caching website Browser Output Caching Caching (static files) (markup) client server File Caching Object Cache client or server server DB files Cache-Aside pattern https://docs.microsoft.com/en-us/azure/architecture/patterns/cache-aside Copyright © 2019 Episerver. All rights reserved. Page 117

Episerver – Developing for DXC Service Module C – Development Considerations – Caching Making the most of output caching For static responses, set an Expires (HTTP 1.0) or Cache-Control (HTTP 1.1) header of one year. • Expires is limited to a HTTP date so browser and server times need to be synchronized. Expires: Thu, 7 Nov 2018 20:00:00 GMT • Cache-Control is more flexible. public means CDNs can also cache the content. private would mean only the browser should. max-age is an integer value of seconds (31536000 = one year). Cache-Control: public, max-age=31536000, must-revalidate • Include a version identifier in the path or filename to allow intermediary proxies like CDNs to store and serve them indefinitely, e.g. jquery-3.1.0.min.js https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control Episerver Output Caching • Based on ASP.NET Output Caching. • This is an effective method since the entire rendered markup of a full or partial view will be cached for a specified duration. • The cache is automatically invalidated when content in Episerver CMS is published. • You can define dependency rules for the cache, as well as which parts of the website should be affected. Russian Doll caching The idea with Russian doll caching is to cache items in several layers where each layer has a dependency on next layer. https://world.episerver.com/blogs/Johan-Bjornfot/Dates1/2017/12/html-caching-in-redis/ Copyright © 2019 Episerver. All rights reserved. Page 118

Episerver – Developing for DXC Service Module C – Development Considerations – Caching Output caching static application files For performance reasons, it’s a good idea to cache static application files for about a year. Modify the <clientCache> element to increase the cacheControlMaxAge from one day to one year: <system.webServer> <staticContent> <clientCache cacheControlMode=\"UseMaxAge\" cacheControlMaxAge=\"365.00:00:00\" /> But what happens when you want to change the contents of a static file that does not include a version number or date in its name, like site.css? We need to ”bust” the cached version. You can write some code that adds a ”fingerprint” to each file automatically. This blog article shows an example of how: http://madskristensen.net/post/cache-busting-in-aspnet Or: https://github.com/bjuris/EPiServer.CdnSupport Episerver Copyright © 2019 Episerver. All rights reserved. Page 119

Episerver – Developing for DXC Service Module C – Development Considerations – Caching Output caching content asset files For performance reasons, it’s a good idea to cache content asset files for about a year. Add the following in Web.config’s <configSections> element: <section name=\"staticFile\" allowLocation=\"true\" type= \"EPiServer.Framework.Configuration.StaticFileSection, EPiServer.Framework.AspNet\" /> Then add the following element after the end of the </configSections> element: <staticFile expirationTime=\"365.00:00:00\" /> You can also set cacheControl and enableOutputCache: <staticFile expirationTime=\"365.00:00:00\" cacheControl=\"Private\" enableOutputCache=\"true\" /> EpcisearvcerheControl defaults to Auto, which uses Private for authenticated visitors and Public for anonymous. Copyright © 2019 Episerver. All rights reserved. Page 120

Episerver – Developing for DXC Service Module C – Development Considerations – Caching Output caching dynamic content To enable output caching, you can use Episerver’s content-aware [ContentOutputCache] attribute: // response cached for 2 hours <episerver> Default is 00:00:00 [ContentOutputCache] public ActionResult Index(ProductPage currentPage) <applicationSettings httpCacheability=\"Public\" httpCacheExpiration=\"02:00:00\" // response cached for 20 minutes Do not use Microsoft’s [OutputCache] [ContentOutputCache(Duration = 1200)] because it will not be invalidated when public ActionResult Index(ProductPage currentPage) content is published! Only applies to GET requests from anonymous visitors. • Logged in users will never receive cached responses. • Content personalized with visitor groups will also not be cached. Episerver Copyright © 2019 Episerver. All rights reserved. Page 121

Episerver – Developing for DXC Service Module C – Development Considerations – Caching Using Response.Cache to control output caching of dynamic content Set cacheability and max-age in the HTTP response headers just before returning an action result (TimeSpan will automatically convert into seconds): Response.Cache.SetCacheability(HttpCacheability.Public); Response.Cache.SetMaxAge(TimeSpan.FromDays(1)); return View(); To set a sliding expiration so each request renews the cache: Response.Cache.SetSlidingExpiration(true); To set Expires header (the older HTTP 1.0 standard): Response.Cache.SetExpires(DateTime.Now.AddDays(1)); Episerver Copyright © 2019 Episerver. All rights reserved. Page 122

Episerver – Developing for DXC Service Module C – Development Considerations – Caching What types of dynamic output caching work? PartialView View ASP.NET MVC has built-in: • View caching: the entire HTML page is cached. PartialView • Partial View caching aka ”donut hole” caching: Donut one or more parts of an HTML page are cached. ASP.NET MVC does not have built-in: • ”Donut” caching: most of the HTML page is cached EXCEPT one or more parts. Episerver DevTrends’ MvcDonutCaching NuGet package Donut caching is a server-side caching technique in which the entire page is cached, except for small portions that remain dynamic. ASP.NET MVC Extensible Donut Caching brings donut caching to ASP.NET MVC 3 and later. The code allows you to cache all of your page apart from one or more Html.Actions which can be executed every request. Perfect for user specific content such as personalization by Visitor Groups. This post describes MvcDonutCaching, a new open-source NuGet package that adds donut caching to MVC3 in a simple and performant manner: http://www.devtrends.co.uk/blog/donut-output-caching-in-asp.net-mvc-3 Jon Jones has written one especially for Episerver: http://jondjones.com/learn-episerver-cms/episerver- developers-guide/episerver-caching/how-to-implment-a-donut-hole-cache-in-episerver Copyright © 2019 Episerver. All rights reserved. Page 123

Episerver – Developing for DXC Service Module C – Development Considerations – Controlling the Content Delivery Network CDN cache hitrate for a DXC Service customer Average is around 68% in this period across all our customers. Episerver Set up CDN as soon as possible (with certificates if needed). Setting up everything except for the final go-live can be done in advance, and has no additional cost. CDNs consist of a globally distributed network of proxy servers deployed in multiple data centers. CDNs will deliver content from the fastest and closest server available. The CDN has its own URL pointing to the original URL. The visitor will navigate to something like \"www.customer.com\". The request will go to the CDN, which in turn goes to the origin URL for non-cached data. The request will return to the CDN, which will cache the content. The CDN servers are designed to cache content according to the cache rules you define in the HTTP headers from your application. It is critical that these caching rules are correctly set in order for your solution to scale properly. Content Delivery Network (CDN) configuration http://world.episerver.com/documentation/developer-guides/CMS/Deployment/content-delivery-network- cdn-configuration/ Copyright © 2019 Episerver. All rights reserved. Page 125

Episerver – Developing for DXC Service Module C – Development Considerations – Controlling the Content Delivery Network Cloudflare CDN cache control default Cloudflare will read the Expires and Cache-Control headers if your website returns them. Cloudflare will set the Cache-Control header to a value of four (4) hours, if: • You do not respond with a Cache-Control header. • You respond with a Cache-Control header that is less than four hours. https://support.cloudflare.com/hc/en-us/articles/200169266-Does-Cloudflare-honor-my-Expires-and-Cache-Control-headers-for-static-content- One effect of these defaults is that if you publish a new version of a media asset, Cloudflare will cache the old version for four hours. Cloudflare image optimization (look for response headers: 126 cf-bgj, cf-cache-status, cf-polished) DXC Automatic Image Optimization: https://world.episerver.com/blogs/scott-reed/dates/2018/5/dxc-automatic-image-optimization/ Episerver Controlling ETags The ETag or entity tag is a part of the HTTP protocol determining cache validation, and is best used for static content such as files, uploaded assets, and pages without output caching. For requests to resources composed from dynamic content objects such as a landing page, using ETags is not recommended. To control Etags, you can add an outbound rule to rewrite the response, for example: <system.webServer> <rewrite> <outboundRules> <rule name=\"Remove ETag\"> <match serverVariable=\"RESPONSE_ETag\" pattern=\".+\" /> <action type=\"Rewrite\" value=\"\" /> https://world.episerver.com/forum/developer-forum/-Episerver-75-CMS/Thread-Container/2017/1/dxc-etag- support/ http://mark.mymonster.nl/2011/10/18/improve-the-yslow-score-remove-the-etags Copyright © 2019 Episerver. All rights reserved. Page 126

Episerver – Developing for DXC Service Module C – Development Considerations – App Service environment // add reference to sysglobl.dll using System.Globalization; Registering custom culture codes Some developers, especially in Europe, like to register additional culture codes to enable custom combinations. For example, en-SV, meaning English as the language (used to localize the user interface) and, say, Swedish as the region, for currency, date/time formats, and so on. var builder = new CultureAndRegionInfoBuilder(\"en-SV\", CultureAndRegionModifiers.None); builder.Register(); Unfortunately, doing this requires registering the custom culture code with the Windows OS. Microsoft makes that impossible in Azure App service, and therefore you cannot do it for DXC Service either. Luckily, if you are building an Episerver Commerce website then it can have multiple markets, each with its own custom combination of language and currency. See the Notes section under this slide for more details. Episerver Using Commerce markets for mixed cultures A market is represented by an instance of the IMarket interface. The data associated with each market is typically used as a set of guidelines for regional markets. However, the market system is not specifically tied to a region; and languages and currencies are not automatically filtered based on the value of the current market. http://world.episerver.com/documentation/developer-guides/commerce/markets/ Instead, you could re-purpose an existing culture code that you don’t use, like en-AU, and modify it to have the same behaviour as Swedish region, but that could confuse users. http://www.informit.com/articles/article.aspx?p=664144 Copyright © 2019 Episerver. All rights reserved. Page 128

Episerver – Developing for DXC Service Module C – Development Considerations – App Service environment Using a cloud PDF generator Azure App Service does not allow execution of out-of-process COM or GAC components. Shared components of the OS are also restricted, like the registry, graphics subsystems, and cryptography. If you currently use a library for PDF generation on-premise, it likely uses GDI and out-of-process components that are not compatible with DXC Service. Switch to a cloud PDF generator like: • HTML 2 PDF Rocket: https://www.html2pdfrocket.com/ • Winnovative HTML to PDF Converter for Azure: http://www.winnovative-software.com/html-to-pdf-converter-azure.aspx Azure Web App sandbox: https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox Episerver PDF Generation in Azure Functions V2 https://odetocode.com/blogs/scott/archive/2018/02/14/pdf-generation-in-azure-functions-v2.aspx Using Azure App Services to Convert a Web Page to PDF https://msdn.microsoft.com/en-us/magazine/mt707529.aspx Copyright © 2019 Episerver. All rights reserved. Page 129

Episerver – Developing for DXC Service Module C – Development Considerations – App Service environment Limiting the number of content types and the size of your code base Limit the number of content types. During start up, all assemblies will be scanned and all views will be cached. A large number (200+) of content types significantly affects the start up time. Keep the App Service size below 1 GB. This includes wwwroot, e.g. binaries and .cshtml views, but would not include media assets and logs, which should be stored in Azure Storage Blobs. Avoid writing to the file system. See the Notes section under this slide for more details. Episerver Avoid writing to the local file system The VM hosting your Web App can be restarted at any time, losing any information stored in the local file system. Some third-party components such as Lucene.NET that use local files therefore do not work. BLOBs should be configured to use an alternative provider, e.g. Azure or AWS Blobs. DXC Service does include a 1 GB local cache for files but you should: • Ensure that you never store more than 1 GB • Avoid it anyway because using it limits scalability! Copyright © 2019 Episerver. All rights reserved. Page 130

Episerver – Developing for DXC Service Module C – Development Considerations – App Service environment Warm up your site with application initialization When you upgrade your code base, or when Azure patches the underlying OS, or when a scale out happens to handle additional load, Azure must restart the processes that host your site. This increases the response time for initial requests because assemblies must be loaded and caches are empty. You can “warm up” your application by adding one or more URLs (with optional domains) to request during application initialization. Each request must respond before it moves on to the next, but those responses can include 500s. Once all requests are made, visitors can then access the site. In the following example, warmupCustom could be a registered route that executes code to do any other custom initialization not managed by Episerver. Episerver <system.webServer> <applicationInitialization> <add initializationPage=\"/\" hostName=\"www.example.com\" /> <add initializationPage=\"/about-us\" hostName=\"www.example.com\" /> <add initializationPage=\"/warmupCustom\" /> Application Initialization <applicationInitialization> https://docs.microsoft.com/en-us/iis/configuration/system.webServer/applicationInitialization/ Azure Web App Application Initialization This article covers nine things that are not mentioned in the Microsoft documentation, including that initializations are response ignorant, so applicationInitilization doesn't care if a page returns 200, 404 or 503. As long as it returns something it will consider it's job done. This means if your page times out, IIS will still think that you are good to go. http://www.zankavtaskin.com/2016/12/azure-web-app-application-initialization.html Copyright © 2019 Episerver. All rights reserved. Page 131