Episerver World's DXP deployment flow (tagging based)

TL,DR: Deployment process for specific environment using git tagging syntax for automation and easy tracking.

Currently we saw some blog posts related to DXP, as Episerver World team also use it as a service as well, we would like to quick mention some customization and practice that we have done a long the way.

Like many others take advantage of Azure Devops, we use it for smooth flow from development to deployment.

Due to specific requirement and work-flow, everyone has his own way to make it work properly. As our team is small and sometimes we would like to test things on different environments, we rely on tags to deploy and track issues.

Based on tag feature, via Pinelines here:

we create an YAML to track each time when a tag is pushed to a commit (via Git client tool or Visual Studio), the automatic tasks like build, publish and related one will be triggered and executed:

trigger:
  tags:
    include:
      - inte.a.*

After a build, we would like to track current version of deployment on our web app, so we write it somewhere so we can visit it later in case of investigation for issues.

* Note: In this example the file "currentVersion.html" must be created and included in the project first. If we create new file here, it won't be included in the package afterward for tasks of build and publish.

- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      $tags = git tag --sort=-creatordate
      $tag = $tags[0]
      Write-Host "##vso[build.addbuildtag]$tag"
      Set-Content $(Build.SourcesDirectory)/currentVersion.html $tag

The $tag is the latest one pushed to git source. Besides, we use Write-Host command to write down current tag that trigger next phase's Releases (config below). When some things went wrong and we would like to investigate problem, Paas portal Trouble Shooting tab might come in handy:

Then we check the current tag by visiting Web-app-url/currentVersion.html to detect which version is currently online, and double check with Repos \ Tags for source code:

From the pipeline you can see information of build include commit's comment and tag:

* Note: YAML changes must be checked to master branch, by checking in or via azure devops portal. Creating YAML file in other branches won't trigger auto tasks that we defined within. Moreover, git's history of creation of YAML files are unable to overwritten by a git client tool so it will create new  check-in each time you modify the content. We must take trials and errors, even it makes our git tree not so nice looking.

That's it for YAML! After we're done with the Pipelines, coming up next is the Releases section for tasks of deployment:

As mentioned above, by command Write-Host to trigger Releases, we also need to declare it in the artifact section:

At first I tried build tags input on the right but it seems not to work (still not figure it out why). Declare using build branch works without any issue. You can see from screen-shot the release name and tag of current release. Same trackdown as Pipeline tag above.

And finally, depends on requirement we got stages, tasks should be done for the deployment, with the support of EpiCloud PowerShell Module:

Illustrated above is our old work flow as in the past, some processes need to be done manually or rely on third party apps. At the moment when Deploy API is available, we don't have to use them any more.

And voila, that's all for our process! It might work or might not applicable for your work-flow. However, we hope it can provide with some information and ideas when you are on duty for this one.