Skip to main content

Optimizely

Restoring production DXP content for local Episerver development

Zen

While developing new features in Episerver CMS, it can be incredibly useful to have a local copy of the production content.  Here are the steps required for extracting content from Episerver’s DXP platform and restoring it into your local environment for development.

Step 1: Request a database backup from the PaaS portal

The first step in the process is the only one you can’t fully control.  You need to initiate a database export from the PaaS portal.  Navigate to paasportal.episerver.net, select the appropriate account, and initiate a production export from the Troubleshoot tab.

Paasportal

This process takes anywhere from a few minutes to a few days.  I personally like to initiate this after a successful production deployment, or after we do large content manipulation efforts.  Once it’s complete, you’ll see a link to download a .bacpac file in this same section.

Step 2: Import backup into your local SQL Server

Once you receive the .bacpac file, you’ll need to import it into your local development environment.  I always run Episerver under IIS with SQL Server, so these instructions are tailored to that setup (as opposed to IIS Express and SQL Express).  I usually start by turning off IIS, closing existing connections to my current database, and deleting it.  From there, run a Data Tier import to restore the production .bacpac with the same name as your local dev setup.

Import

Another tip here: All developers working on the same solution share a SQL Alias called “episerver” resolving to their local SQL installation.  We all use a local SQL account called “episerver” which is an admin on the local SQL installation, all with the same password.  From there, we usually call the database episerver.projectname.  Regardless of your setup, just make sure you import the production database and configure your connection string in your web.config accordingly.

Step 3: Run SQL command to update versioning

This is a little hidden step that I think trips a lot of people up.  We automate the installation of code through our devops platform of choice (e.g., Azure Devops).  As part of this setup, we always introduce assembly versioning, so each new version of the application gets an automatically assigned and incrementing version number.  These version numbers get stored within Epi’s database, and Epi will avoid updating ContentTypes which have a lower version than those found within the database.  To correct this, set the version back to 1.0.0.0 (or whatever is in your local AssemblyInfo.cs file).  Here’s the SQL script to do it (replace MySite and x.y.z.0 accordingly):

UPDATE [episerver.mysite].[dbo].[tblContentType] 
SET
  ModelType = REPLACE(ModelType, 'x.y.z.0', '1.0.0.0'),
  Version = '1.0.0.0'
WHERE ModelType like '%MySite%'

Step 4: Export/Import Blobs from production

Now that you have the content, you need the Blobs to go with it.  This step is fairly simple- we typically opt to store Blobs in the “For This Site” or “For All Sites” area.  Login to production, navigate to the admin tab, and initiate a content export of the necessary roots.  From here, log back into your local environment, and import these roots.

You can read about exporting and importing from here.

Don’t forget, because you restored the production database on your local environment, you need to login with your production credentials.

Step 5: Update your site configuration

Finally, log back into your local Episerver instance, navigate to the Admin tab, and configure your Site definition with the appropriate hostnames.  If you have a wildcard hostname in production, you may not need to do this- but I recommend doing this to be thorough.

Step 6: Profit!

And that’s it!  Keeping your local environment in sync with production is vital to being an effective developer on an Epi project.  Hope this helps, happy coding.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Dylan McCurry, Solutions Architect

I am a certified Sitecore developer, code monkey, and general nerd. I hopped into the .NET space 10 years ago to work on enterprise-class applications and never looked back. I love building things—everything from from Legos to software that solves real problems. Did I mention I love video games?

More from this Author

Categories
Follow Us