🔧 Maintenance Alert: World will be on Read-Only Mode on February 18th, 10:00 PM – 11:00 PM EST / 7:00 PM – 8:00 PM PST / 4:00 AM – 5:00 AM CET (Feb 19). Browsing available, but log-ins and submissions will be disabled.
🔧 Maintenance Alert: World will be on Read-Only Mode on February 18th, 10:00 PM – 11:00 PM EST / 7:00 PM – 8:00 PM PST / 4:00 AM – 5:00 AM CET (Feb 19). Browsing available, but log-ins and submissions will be disabled.
Views: | 16893 |
Number of votes: | 5 |
Average rating: |
This article provides an example of how to manage continuous deployment for Episerver solutions. In this scenario we are using Octopus Deploy, to deploy code changes to the Integration environment in Episerver Digital Experience Cloud (DXC) Service, the cloud-based service offer from Episerver using Microsoft cloud technology.
You can use any deployment tool that supports Azure Resource Manager (ARM), for continuous deployment. In this scenario we use Octopus Deploy, describing the steps needed to set up and execute continuous deployment of code changes.
This scenario assumes a first-time setup and deployment of code changes for a customer project to an Octopus server and the Integration environment. There are different options for configuring your Octopus server, depending on how you prefer to manage continuous deployments. In the steps below, we will configure Octopus to automatically create a release and deploy to the DXC Integration environment, each time the project is built.
As this is a first-time deployment setup, you need to create an environment, modify the lifecycle, create a project group, a customer project, and an Octopus user. If you already have these items in place, you can skip these steps.
In this step you will configure Visual Studio to create Octopus-compatible NuGet packages, and push them to your Octopus deploy server. This step needs to be done for each new project.
<!--RUN OCTOPACK START-->
<RunOctoPack>true</RunOctoPack>
<OctoPackPublishPackageToHttp>http://YOUR-OCTOPUS-SERVER-ADDRESS</OctoPackPublishPackageToHttp>
<OctoPackPublishApiKey>YOUR-USER-API-KEY</OctoPackPublishApiKey>
<!--RUN OCTOPACK STOP-->
OctoPack: Packaging an ASP.NET web application (Web.config detected)
OctoPack: Attempting to build package from 'dxcdeploy.nuspec'.
OctoPack: Successfully created package 'c:\users\name\documents\visual studio 2015\Projects\dxcdeploy\dxcdeploy\obj\octopacked\dxcdeploy.1.0.6010.25791.nupkg'.
OctoPack: OctoPack successful
Pushing octotest 1.0.6010.25791 to 'http://your-octopus-server-address/nuget/packages'...
Your package was pushed. ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
In this step you will set up the deployment process, using the components created in previous steps. In step 3 you created a NuGet package and pushed it to your Octopus deploy server. Here you will configure Octopus to create a release, and deploy the package to the Integration environment in DXC Service.
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.
You can use the Integration environment to regularly test and verify your changes, before deploying to production. Note that in DXC Service, deployment from Integration to the Production environment is managed by Episerver. See Deploying for more information.
Nice one!
Octopus Deploy has the feature that you can ship some powershell scripts that are to be executed in the deploy, does DXC support that in the Integration environment? If so, is it also possible that these files are executed in the later environments?
http://docs.octopusdeploy.com/plugins/servlet/mobile#Customscripts-ScriptsinPackages
Well done!
Very nice article but requires a little bit of updating.