Hide menu Last updated: Dec 19 2017
Area: Episerver DXC Service Applies to versions: Not applicable

Deploying code changes

This topic describes continuous deployment of code changes from your local development environment to the Integration environment in Episerver DXC Service

When is this applicable?
Follow this procedure for an existing site running in the Integration environment, to which you want to deploy code updates. This can be done incrementally to upgrade your site during the development process, after a first-time deployment. See DXC Service self-deployment guide to deploy to Preproduction. Contact Episerver to deploy to Production.

Deployment methods

You can deploy code changes continuously using either deployment tools for a version controlled source code, or through Visual Studio using the Episerver extensions and publish profiles. In both cases you need to contact Episerver before you deploy for the first time, to get the needed deployment integration settings information.

Before you start

  • See Requirements for recommended versions of software, tools and services to use.
  • See Getting started for information needed to deploy.

Deploying from a version controlled environment 

If you work in a development team using version control for your source code, you can use any deployment tool that supports Azure Resource Manager (ARM), for example Octopus Deploy, Visual Studio Team Services or TeamCity

See Continuous deployment of Episerver solutions for an example using Octopus Deploy.

Follow the steps below to initiate the setup of the deployment integration for your environment.

  1. Contact Episerver to request setup of the integration.
  2. When the integration has been set up, the following information will be sent to you:
    • Client application ID
    • Password key
    • Subscription ID
    • Tenant ID
  3. When you have received the information, refer to the documentation for the specific deployment tool that you use, for details on how to set up the deployment integration there.

Deploying using publish profiles

In this example we will deploy code changes for a Commerce solution, which has two sites (front-end/back-end). The steps are the same for a solution with only CMS, in this case you will only have one site.

  1. Right-click on the project in Visual Studio and select Publish.
       

        
  2. Browse and select the publish profile for the Integration environment.
  3. Click Import to import the settings from the publish profile and click Next.
       

       
  4. The next step, Connection, should display the imported publish profile settings, no changes are required here. Click Next (not Publish).
        

       
  5. Select Configuration and Release, and click Next.
         


    When using the setting Remove additional files at destination, be careful not to touch the files stored in the newrelic folder. To avoid issues with these files being removed or blocked during publish, you can edit either the publish profile or project file, and add the following settings:

    1. Inside the PropertyGroup-element:
    <AfterAddIisSettingAndFileContentsToSourceManifest>AddCustomSkipRules</AfterAddIisSettingAndFileContentsToSourceManifest>
    2. Inside the Project-element:
    <Target Name="AddCustomSkipRules">
      <ItemGroup>
        <MsDeploySkipRules Include="SkipFilesFolder">
          <AbsolutePath>newrelic</AbsolutePath>
        </MsDeploySkipRules>
      </ItemGroup>
    </Target>
      
  6. Preview the changes and click Publish to finalize the code deployment.
        

        
  7. Repeat steps 1-6 for the Commerce Manager back-end site. Note: ensure that the Apps folder is included in your Commerce Manager project.
  8. Log in to the site using the URL provided for the Integration environment, and verify that it is working.

Protecting New Relic files

The New Relic files for application performance monitoring reside in a main top level folder called newrelic. These files are added by Episerver and should not be modified. To avoid issues with these files being removed or blocked during publish, ensure that you do not remove or modify the newrelic folder during deployment, see step 5 in the description above. See also this blog post on how this can be done for multiple web apps.

Related topics

Comments