Have you ever accidentally deployed the wrong set of Sitecore items (the wrong ones, or too few items) to production as part of a release? I certainly have, because pushing changes via manually generated Sitecore packages or TDS can be error-prone.

With the release of Sitecore 10 and Sitecore Content Serialization (https://doc.sitecore.com/xp/en/developers/100/developer-tools/sitecore-content-serialization.html) the Sitecore item deployment process can be automated and added to your CI/CD pipelines. The same set of items will be deployed by the same ruleset to each environment, giving you more confidence to push to production.

I won’t go into detail about how to define what items should be serialized – the Sitecore documentation provides that. However, Sitecore documentation does not concisely detail all of the steps for scripting out the deployment.

Package Generation

In Azure DevOps, you can add a Powershell task to your pipeline that is responsible for generating and staging the itempackage to later deploy.

- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      dotnet new tool-manifest
      dotnet tool install Sitecore.CLI --add-source https://sitecore.myget.org/F/sc-packages/api/v3/index.json
      cd ./Source
      dotnet sitecore ser pkg create -o {example}.itempackage

- task: CopyFiles@2
  inputs:
    SourceFolder: '$(build.sourcesDirectory)\Source'
    Contents: '{example}.itempackage'
    TargetFolder: '$(Build.ArtifactStagingDirectory)'
    OverWrite: true
    CleanTargetFolder: false

Package Deployment

Now that the pipeline is generating a package to deploy, you will need to:

1. Set up non-interactive client logins (https://doc.sitecore.com/xp/en/developers/100/developer-tools/configure-a-non-interactive-client-login.html)
2. Deploy the generated package via your release pipeline

Sitecore provides ample documentation around setting up the non-interactive client login credentials. Below are the basic details of what you would need to add to your release pipeline. You can add these steps within an Azure Powershell release pipeline step.

$package = "$(System.DefaultWorkingDirectory)\{pipelineName}\{artifactRoot}\{example}.itempackage"

#add whitelist rules here

dotnet new tool-manifest
dotnet nuget add source -n "Sitecore NuGet Feed" https://sitecore.myget.org/F/sc-packages/api/v3/index.json
dotnet tool install Sitecore.CLI --add-source https://sitecore.myget.org/F/sc-packages/api/v3/index.json
dotnet sitecore init
dotnet sitecore ser pkg install -f $package --authority https://{sitecore-si}.azurewebsites.net --cm https://{sitecore-cm}.azurewebsites.net --client-id SitecoreCLIServer --client-secret "{client-secret-from-step-1}"

#remove whitelist rules here

Write-Output "Finished ser install"

I’ve normally worked on sites that have IP address restrictions placed on the ContentManagement and Sitecore Identity servers to prevent access to backend systems. Depending on whether your build server has a static IP address or not, you may wish to dynamically update the IP address restrictions within the release pipeline. You can use ipinfo.io/json or another service to gather your outbound IP address.

$currentIp = Invoke-RestMethod http://ipinfo.io/json | Select -exp ip

Write-Output $currentIp

Add-AzWebAppAccessRestrictionRule -ResourceGroupName "sitecoreResourceGroup" -WebAppName "{sitecore-cm}" -Name "Azure DevOps Release Pipeline" -Priority 101 -Action Allow -IpAddress "$currentIp/32"
Add-AzWebAppAccessRestrictionRule -ResourceGroupName "sitecoreResourceGroup" -WebAppName "{sitecore-si}" -Name "Azure DevOps Release Pipeline" -Priority 101 -Action Allow -IpAddress "$currentIp/32"

Remove-AzWebAppAccessRestrictionRule -ResourceGroupName "sitecoreResourceGroup" -WebAppName "sitecore-si" -Name "Azure DevOps" -ErrorAction SilentlyContinue
Remove-AzWebAppAccessRestrictionRule -ResourceGroupName "sitecoreResourceGroup" -WebAppName "sitecore-cm" -Name "Azure DevOps" -ErrorAction SilentlyContinue

Now after running your release pipeline, you should see output similar to what is shown below.

Next Steps

Now you can release Sitecore item changes with confidence, knowing you are pushing the same changes to each environment.