Visions In Code

Friends of Sitecore may October be a wonderful month, soon Halloween friends 🎃

In my last post, “Why You Should Always Validate Serialized Sitecore Items Before Deploying to XM Cloud,” we discussed the importance of validating serialized items before deployment. This ensures that no invalid or incomplete data is deployed to your environments, reducing the risk of errors and downtime.

In this post, let’s explore how you can deploy different content to staging and production environments using environment-specific xmcloud.build.json configurations.

The Importance of Managing Environment-Specific Configurations

For readers who are unfamiliar, managing content for different environments is crucial because each environment serves a distinct purpose. Staging environments might include test sites and configurations, while production should only contain finalized content. This helps avoid exposing unfinished content to users and ensures better control during releases.

Setting Up xmcloud.build.json per Environment

To achieve this separation, you can set up distinct build configuration files:

• xmcloud.stage.build.json for staging
• xmcloud.prod.build.json for production

These files will define which Sitecore items are deployed to each environment.

Automating Deployment Using CI/CD

By automating the copying and renaming of the appropriate build configuration in your CI/CD pipeline, you can seamlessly deploy different items per environment. Here’s how it looks in a GitHub Actions workflow:

name: CI-CD - XM Cloud
on:
  workflow_dispatch:
  push:
    branches: [ main ]
  pull_request:
    types: [opened, reopened, synchronize, closed]
    branches: [ main ]

jobs:
  validate-data:
    if: github.event_name == 'push' || github.event_name == 'pull_request' || github.event_name == 'workflow_dispatch'
    uses: ./.github/workflows/validate-xmcloud.yml

  deploy-to-stage:
    name: Deploy the XM Cloud STAGE environment
    runs-on: ubuntu-latest
    environment: stage
    needs: validate-data
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-dotnet@v2
      with:
        dotnet-version: '8.0.x'
    - run: dotnet tool restore
    - name: Authenticate CLI with XM Cloud
      run: dotnet sitecore cloud login --client-credentials --client-id ${{ secrets.XM_CLOUD_CLIENT_ID }} --client-secret ${{ secrets.XM_CLOUD_CLIENT_SECRET }} --allow-write
    
    - name: Copy and rename xmcloud.build.json
      run: cp xmcloud.build.stage.json xmcloud.build.json 

    - name: Deploy the CM assets to XM Cloud
      run: |
        dotnet sitecore cloud deployment create --working-dir . --environment-id ${{ secrets.XM_CLOUD_STAGE_ENVIRONMENT_ID }} --upload --json
        echo "Deployment Completed"

  deploy-to-prod:
    name: Deploy the XM Cloud PROD environment
    runs-on: ubuntu-latest
    environment: prod
    needs: validate-data
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-dotnet@v2
      with:
        dotnet-version: '8.0.x'
    - run: dotnet tool restore
    - name: Authenticate CLI with XM Cloud
      run: dotnet sitecore cloud login --client-credentials --client-id ${{ secrets.XM_CLOUD_CLIENT_ID }} --client-secret ${{ secrets.XM_CLOUD_CLIENT_SECRET }} --allow-write
    
    - name: Copy and rename xmcloud.build.json
      run: cp xmcloud.build.prod.json xmcloud.build.json 

    - name: Deploy the CM assets to XM Cloud
      run: |
        dotnet sitecore cloud deployment create --working-dir . --environment-id ${{ secrets.XM_CLOUD_PROD_ENVIRONMENT_ID }} --upload --json
        echo "Deployment Completed"

Leveraging the Power of GitHub Environments and Managing xmcloud.build.json

One critical aspect of the workflow is the copying and renaming of the environment-specific xmcloud.build.json. This step ensures that the right content is selected for each environment—whether it’s the staging or production environment. By using the simple command:

- name: Copy and rename xmcloud.build.json
  run: cp xmcloud.build.stage.json xmcloud.build.json 

you make sure the appropriate configuration is deployed, reducing the chances of accidental content deployment.

In addition, the power of GitHub environments is fully utilized to enhance your CI/CD process. Environments in GitHub allow for seamless control of environment-specific variables, secrets, and permissions. This further reduces manual intervention and ensures content is deployed to the correct environment—automating the workflow in a scalable and reliable manner.

By combining environment-specific configurations with GitHub’s powerful environment features, you can significantly streamline your deployments while keeping the system organized and adaptable to different needs.

Benefits of Using Environment-Specific Builds

• Content Separation: Ensures that staging-only content is not accidentally deployed to production.
• Controlled Releases: Allows better control over what content gets deployed and tested before hitting production.
• Streamlined CI/CD Process: Automates the process, reducing human error and manual intervention.

By adopting this approach, you can manage environment-specific Sitecore deployments in a way that is scalable, flexible, and efficient. Whether you’re deploying test content for QA or finalized items for production, this method helps keep your environments clean and fit for purpose.

That’s all for now folks 😊