Developing with Episerver DXC
Adage developers build, maintain and upgrade hundreds of Episerver sites every year. As we increasingly utilize Episerver DXC for projects we continue to learn and document best practices. This article will cover components of Episerver DXC, benefits of use and what we’ve learned from our extensive experience developing solutions with Episerver DXC. Let’s start with an overview of Episerver Digital Experience Cloud Service.
Episerver DXC Service Overview
Episerver Digital Experience Cloud Service (DXC Service) is a cloud-based platform developed by Episerver to maintain and support web applications in the cloud using high availability, elastic scaling, robust security, and managed services in one package. In addition, included in the DXC Service are the software licenses for Episerver cloud CMS and Episerver Find.
Using DXC service to host and support your solution means that you as a member of a development or infrastructure team do not have to worry about setting up and configuring the required components in Episerver.
Episerver DXC Service Components
The DXC service is built based on the Microsoft Azure cloud technology to natively integrate with cloud platforms and services. All domains hosted in DXC service are terminated using a CloudFlare content delivery network (CDN) and are provided an SSL certificate at the CDN for no additional charge. These components are included in all DXC service installations:
- Azure WebApps
- Azure SQL Databases
- Azure Blob Storage
- Azure Service Bus
- Content Delivery Network
DXC Service Management Portal
This is the self-service portal hosted within Episerver DXC to promote releases between the Integration, Preproduction, and Production environments. In this portal you can do the following:
- Deploy from integration to Pre-Production and Production
- View application logs
- View stack trace errors
DXC Service Dashboard
This dashboard is an additional tool to review data about usage, and availability for components associated with your DXC Service subscription. In this dashboard you can:
- View domains availability
- View insights to consumption
- View insights to performance
*An Episerver cloud account is needed to access these resources
Why Use DXC Services
There are many benefits to utilizing Episerver DXC services.
Microsoft Azure Platform infrastructure and security
Microsoft cloud infrastructure is audited at least once a year for SOC 2 and ISO 27001 compliance. A full list of audit reports are published and available for you to view.
Episerver DXC gives you the ability to use Elastic scaling without manual intervention to add additional resources at peak times when you need extra performance to meet your user’s demands. With Elastic scaling your application can increase the number of concurrent visitors without impacting load times and performance.
Full-stack Redundancy, Backup, and Disaster Recovery
In case a disaster strikes Episerver DXC gives you peace of mind with full-stack redundancy, backup, and disaster recovery. In the digital era, we often hear when applications become unavailable due to outside forces such as inclement weather, power outages, and human errors. With multiple layers of redundancy and a disaster recovery plan, you can rest assured that even if a disaster strikes you are covered.
Word-class Content Delivery Network
Access to a word-class content delivery network to serve content to your visitors faster and without incurring additional bandwidth from your hosting provider. Having your web assets in a content delivery network frees up hardware resources from your front-end webservers to focus on handling visitors requests and not images or videos.
Episerver DXC Best Practices
Next, I’ll share what we’ve learned along the way that can help with your Episerver DXC implementation. You’ll find tips and best practices for the start of a project, during the development stage and things to consider once you are close to go-live.
Have Your Team Create Episerver Cloud Accounts
Episerver cloud accounts are required in order for team members to access DXC Azure information and services, such as the Management Portal (for deployment) and the Service Dashboard (for usage information). When you know you will be working on a DXC-hosted project, you should identify the members of your team who will need access to DXC services and have them create accounts. Do this early as it may take a few business days to get everything set up and confirmed. Note that it may be beneficial for your DevOps/IT team members to request Episerver Cloud Accounts in addition to your developers.
Request Production Deploy Access Early
As of a few months ago, developers can now trigger deployments to production without having to go through Episerver support. Determine which team members will need production deploy access and have them request Production deploy and troubleshoot access for your project. Do this early as it may take a few business days to get everything set up and confirmed.
Set Up Your Local Development Site First
Starting with a brand new Episerver site? I would recommend getting the solution up and running on your local development environment first before worrying about deploying to DXC. Once your project is in a stable enough state (home page created, basic functionality confirmed, etc.), you should start planning for your first deployment to the DXC Integration environment. Leverage the great documentation on World for more information about your first DXC deployment.
Do Not Include node_modules in Integration Deployments
If your project leverages npmjs for package management, I am sure you are familiar with the infamous node_modules folder. Make sure that when you deploy to Integration that this folder is not included, as it has a tendency to cause problems when trying to promote code from Integration to Pre-Production.
If you are working with 3rd party integrators, they may require your website IPs to be whitelisted in order to work. If this is the case, you’ll need to reach out to Episerver Support to get the correct IP ranges for your DXC environments. It is best to get the ranges for all three DXC environments (Integration, Pre-Production, and Production) in one request to save you feedback loops down the road.
Change Time Zone to Client’s Local Time
If you are working on a project which relies on DateTime data populated from CMS editors, I would advise you request Episerver Support to change the time zone of the DXC environments. This will help curtail potential issues with date displays on your templates.
Deploy to Production Early
Each Episerver DXC environments comes with their own accessible urls out-of-the-box which are unique. This means that you and your clients can test the features of each environment without having to worry about end users seeing your new site too early. With this in mind, I would recommend deploying to the Production environment early and often. This will allow you to test things like configuration transforms well ahead of your launch date. Don’t wait until the last moment to deploy and test the Production environment!
Redirects to enforce https and www in your URLs
Do not write custom rewrite rules to handle these scenarios, as they are handled through Cloudflare and Azure if you are hosting with DXC. Having these rules in your web.config may lead to infinite redirect loops, so it is best not to include them at all.
Know Your Transforms
Make sure your developers understand how to properly write environment configuration transforms when working with DXC. I want to call particular attention to the fact that transforms are applied sequentially as code moves from Integration to Pre-Production to Production, so be especially careful that you are not inserting configurations multiple times.
Be Aware of CDN Caching of Uploaded Files
Every Episerver DXC service package includes a CDN, which is great for optimizing site performance. Do note that the CDN also caches assets uploaded by CMS Editors into the Asset library, which can lead to confusing situations if you they have documents which update frequently. For important files, consider adjusting your cache settings or implementing cache busting.
Closer to Go Live
Coordinate DNS Migration Plan
You will need to coordinate with Episerver Support when you are ready to change your DNS to point to DXC. Make sure to let them know early regarding the timing of the DNS switch so that they can confirm they will have resources available at the specified time. We recommend scheduling the pre-launch DNS switch for the night prior to going live to minimize the impact to end users.
Every Episerver DXC service package includes a multi-domain SSL certificate. If your client has an SSL certificate for their current site, they may want to consider terminating it so they are not paying redundant costs. You will need to coordinate with Episerver Support to switch over to their SSL certificate, so make sure to bake the time to coordinate this transition into your launch plan.
Get a Feel for How Long It Takes to Deploy to Production
Since deployments occur through the Management Portal, there may be more overhead time needed to get your latest code changes live. Do a few test runs before the site is live to get a feel for how long it will take to do a production deployment. This will help you gauge how big a window you should allow your team to have when planning out deployment expectations with your clients.
Always Remember You Can Pick Up the Phone
Sometimes coordinating with Episerver Support via email can take time, especially if you are in a different time zone than your support representative. Never hesitate to call the support line in your region if you have immediate needs or questions!
I trust you found this information helpful and have a few takeaways for your next Episerver DXC project. I want to thank Andres Herrera, Network Administrator at Adage Technologies for contributing to this article. If you have questions, please do not hesitate to reach out.
MktoForms2.loadForm(“//app-ab30.marketo.com”, “692-OSL-876”, 1035);