Epinova DXP deployment extension for Azure DevOps Part 1 - Introduction
Introduction to Epinova DXP deployment Azure DevOps extension. Make it simple to create CI/CD pipelines to Episerver DXP without PowerShell skills.
This blog post is the first in a series
• Part 1: Introduction
• Part 2: Branch and release strategies
• Part 3: A closer look at the Epinova DXP deployment extension for Azure DevOps
• Part 4: How to set up a CI/CD pipeline (Prerequisites and Release candidate strategy)
• Part 5: How to set up a CI/CD pipeline (Classic Strategy, Reset and Hotfix pipelines)
Background
Deployment through Episerver DXP was for a long time quite limited and based on that a package was uploaded to the DXP service and then manually deployed to the different environment through manual interaction in the PAAS portal. For half a year or more – this has changed though with Episerver adding their DXP deployment APIs where it’s possible to push packages and deploy from your favourite CD/CI-Tool directly to any of the three DXP environments. There are several different blog posts on how to do deployment with different tools like Octopus deploy and Azure DevOps. However – not all developers feel comfortable with these kind of tools in for instance PowerShell – and our experience is that tweaking around with this is usually a black box. You do a change, deploy with this and try to figure out if you got the desired behaviour.
At Epinova we use Azure DevOps for all new projects. Since we want to standardize our CD/CI-pipelines we started discussing how this could be done in the best possible way with a new Episerver DXP project, but also to quickly add support when Episerver releases new functionality to their deployment API. To take some examples of powerful new changes that further minimizes our need to open a support case for manual interaction – Episerver recently added the ability to sync content between environment or to create a downloadable backup.
Epinova DXP Azure Tasks
Since I have experience from creating custom Azure DevOps tasks from before – I figured out that this would be a very powerful way to contain this logic in a way where it could easily be added to all our projects. The tasks themselves abstract the interaction with the Episerver DXP deployment API – and on top of that I’ve created a few YAML files with common functionality that uses these Azure Tasks:
- Publish a package to Episerver DXP
- Deploy to a given DXP environment
- Smoke test after deploying to slot
- Complete deploy
- Reset deploy
- Export DB
If you have a DXP solution – it should be as simple as adding these files to your solution, creating an Azure pipeline for each of these files. On top of this you’ll need to set up a few shared variables with for instance your ClientKey and ClientSecret to be able to authenticate with the Episerver DXP deployment API. We’ll go through this step by step in the following blog posts…
YAML vs traditional Azure DevOps task
Azure DevOps supports two ways to set up and configure builds and pipelines:
- Classic UI-configured tasks that are managed in the Azure DevOps UI.
- YAML-files that can be edited both on the Azure DevOps UI – but also versioned and edited within your code base.
The support for YAML is more limited that the traditional tasks in Azure develops – however, it has the benefit of being able to version control the flow as well as easily copy/pasting this to easily get started with a new project.
The following YAML files are currently available as examples in the GitHub repo:
- Build and deploy develop branch as NuGet package to DXP integration environment
- Build and deploy develop branch as web package to DXP integration environment*
- Build and deploy release branch as NuGet to DXP preproduction/production environment
- Build and deploy master branch as NuGet to DXP integration/preproduction/production environment
- Reset all environments (resets ongoing/failed deployments)
*) We’ve experienced that a traditional deployment with a web package through a service connection is much faster than deploying a NuGet package through the deployment API – and therefore we use this for our projects since we want to be able to build and deploy for any check ins to our development branch to the DXP Integration environment.