Deploy code changes

Sitefinity Cloud provides out-of-the-box Continuous Integration (CI) and Continuous Delivery (CD) processes that enable you to test and release new functionality at the click of a button. Releases can be easily traced and there is an interface for manual approval of deployment to specific environments. Moreover, in cases where the system fails to start after a package has been deployed, an automatic rollback is triggered to restore the system to the previously running state.

The following preconfigured CI/CD pipelines are available for the different applications that are part of the Sitefinity Cloud setup:

• For ASP.NET Core Renderer: DotNetCoreRenderer.CI.CD
• For Next.js Renderer: NextJsRenderer.CI.CD
• For Sitefinity CMS: CI.CD
  

  NOTE: This pipeline is available only when the Developer Extensions toggle is enabled. 

• For Sitefinity backend UI extensions: Extensions.CI.CD
  For more information, see Decoupled extensibility for your backend UI.

By default, the deployment workflow is in line with the software development practice of Continuous Delivery (CD) for deploying new changes across environments. During this process, the deployment package is prepared from the main/master branch of the repository and is then subsequently deployed to each environment, following an approval/verification/testing step until reaching Production. By following these best practices, committing your changes directly to the main/master branch is restricted. Instead, all code development must be done in a dedicated feature branch, which you create from main/master branch, and then you merge your changes into main/master via pull request from the feature branch.

This flow can be customized according to the customer needs. For example, you may need a different branch or set of branches configured for each environment. The process of merging pull requests between branches will trigger a build and deploy to the environment of the target branch. In addition, you can configure deployments to any environment to be triggered manually.

The same is valid for the repositories of the ASP.NET Core Renderer, Next.js Renderer, and Sitefinity backend UI extensions applications.

Once your feature branch with the desired code changes has been pushed to the origin, you can proceed by merging these changes to the main/master branch and deploying them.

Create a pull request to push your code to the main/master branch

Perform the following steps:

1. Log in to your Sitefinity Cloud project Management Portal.
2. Navigate to Repos » Pick the repository from the dropdown » Pull requests and click New pull request.
3. From the source branch selection dropdown, select the feature branch you want to merge changes from. From the target branch selection dropdown, select main/master.
4. Fill in the pull request details and click Create.
   

Approve and merge pull requests

Each pull request must be approved before merging the changes to the main/master branch. By default, all users who are in the Contributors role can approve pull requests. To view pull requests that are pending approval and approve them, follow these steps:

1. In your Sitefinity Cloud Management Portal, navigate to Repos » Pick the repository from the dropdown » Pull requests and click the Active tab.
2. Click the name of desired pull request from the list.
3. On the next screen, you can review the pull request and approve it by clicking Approve.

As a result, all policy requirements are marked as met and an automated CI build is triggered to test the changes against the main/master branch. To complete merging the changes, click Complete (located next to the Approve button).

NOTE: Once the merge is successfully completed, the feature branch is automatically deleted as it is no longer needed.

Approving a merge triggers an automated CI build and upon successful completion, the changes are merged in the main/master branch and a deployment is triggered to apply the changes on the corresponding non-Production environment(s). You can browse the non-Production environment(s) where the changes have been deployed to verify your newly deployed functionality is working as expected.

Promote your code to the Production environment

1. In your Sitefinity Cloud Management Portal, navigate to Pipelines » All.
2. Select the CI/CD pipeline for the application.
3. Locate the Run that is pending approval to Production and open it.
4. Click Review next to the message 1 approval needs your review before this run can continue to Production

5. In the dialog box that opens, click Approve or Reject.

The non-Production environment(s) can also be configured to require approval from users in a Promote to {Environment Name} group.

NOTE: NuGet package cache is available only with the CI.CD pipeline for Sitefinity CMS application, if the Developer Extensions toggle is enabled. 

The CI stage of the pipeline uses the built-in Azure DevOps Cache task to cache NuGet packages across builds. 
For more information, see Azure DevOps documentation » Cache task.

This reduces the time it takes to execute the CI stage, because NuGet packages are downloaded from the cache, instead of restored from scratch on each run. The cache key is based on the contents of all packages.config files. This way, the cache is not being used in case packages change.

NOTE: Preview deployment tasks are available only with the CI.CD pipeline for Sitefinity CMS application, if the Developer Extensions toggle is enabled.

The preview deployment functionality checks that the newly deployed version of the application on Production can start up using a DB copy from Production before switching to the actual Production DB. This is important in case of DB schema changes and Sitefinity upgrades that come with the new deployment package, because if the application fails to start or corrupts the DB copy, the actual Production DB will not be affected.

A set of default configuration values are applied to the Renderer application and Sitefinity CMS application when deployed to a Sitefinity Cloud environment, as specified in the tables below.

Sitefinity CMS application

ASP.NET Core Renderer application

Next.js Renderer application

To facilitate the needs of customizing the CI/CD process, Sitefinity Cloud offers a mechanism for extending the existing CI/CD pipeline and include custom tasks for the following events:

• Pre-build tasks in CI stage
• Post-build tasks in CI stage
• Post-deployment tasks in CD stage
  

  NOTE: Post-deployment tasks are available only for the CI.CD pipeline of Sitefinity CMS application, if Developer Extensions toggle is enabled. 

Customize CI stage in CI.CD pipeline of Sitefinity CMS

1. Open the CICD.yaml file located in the repository of the respective application (Sitefinity CMS, ASP.NET Core, Next.js).
2. Locate the parameters element for the extended YAML template.
3. Add a new parameter of type stepList called preBuildSteps or postBuildSteps, and add tasks using the standard YAML task/step syntax.

The example below demonstrates custom pre-build steps installing and building frontend assets with npm, and post-build steps for running unit tests in the CI.CD pipeline of Sitefinity CMS application:

The example below demonstrates custom pre-build steps for adding custom NuGet sources and post-build steps for running unit tests:

Customize CD stage in CI.CD pipeline of Sitefinity CMS

NOTE: Post-deployment tasks are available only for the CI.CD pipeline of Sitefinity CMS application, if Developer Extensions toggle is enabled.

1. Open the CICD.yaml file located in the repository of the Sitefinity project.
2. Locate the parameters element for the extended CICDTemplate.yaml.
3. Define environments collection and list the environments where CD stage needs to be customized.
4. Add a new parameter of type stepList called postReleaseSteps as part of the environment object, and add tasks using the standard YAML task/step syntax.

The custom steps are defined per environment and only an allowed list of task types can be used. Currently the allowed task types are:

• DownloadPipelineArtifact@2
• VisualStudioTestPlatformInstaller@1
• VSTest@2

The example below demonstrates a custom post-release task to run web tests, based on an artifact called tests: