Deploy code changes to the Cloud

Sitefinity Cloud is configured in a CI/CD setup, in accordance with Sitefinity website development best practices and Microsoft Azure services that are being used.  

Code deployment is the process that validates and pushes new changes to the Sitefinity Cloud project deployment instances. It is done through a build pipeline, which consists of several tasks and conditions, ensuring the success of pushing new code to the corresponding deployment stage.  

By default, your Sitefinity Cloud project runs from the master branch on both Staging and Production environments. Following best practices, committing your changes directly to the master branch has been restricted. Instead, all code development must be done in a dedicated feature branch, which you create from master, and then merge your changes into master via pull request from the feature branch.

Create a feature branch

Creating a new feature branch for development follows the standard Git development workflow. For example, if you cloned your Sitefinity Cloud project solution in Visual Studio, follow these steps to create a feature branch:

1. Clone the master branch to begin local development, following the Setting up the project code locally instruction from the Setup the project for development article.
2. From your Visual Studio Team Explorer, locate the master branch, right click on it and select New Local Branch From...
3. Name your new branch and create it.
   
   

As a result, your feature branch for local development is created and you can proceed with your project development.

Include resource files in the Visual Studio project

If you have added new resource files, such as configurations, resource files, JavaScript, or CSS, you must include them in the Visual Studio project:

1. Open your project in Visual Studio.
2. In the Solution Explorer, in the context menu of the resource, click Include In Project.
3. In the Properties pane of the resource, set the Build Action to Content.

If you do not do this, the file will not be added to the deployment package that will be deployed later. For more information, see Troubleshooting » Deployment package.

Commit your changes and sync them to Sitefinity Cloud

When you are done with your changes, you must commit them via the Visual Studio Team Explorer » Changes screen. This action commits your changes only to the local branch.

Once you are ready with your changes and want to deploy them to Sitefinity Cloud, use the Visual Studio Team Explorer » Sync screen to push your changes to Sitefinity Cloud. This operation will synchronize your new feature branch and the committed changes.

Once your feature branch with the desired changes has been synchronized to Sitefinity Cloud, you are able to proceed by merging these changes to the project master branch and deploy them to the Staging environment.

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

Proceed by following these steps:

1. Log in to your Sitefinity Cloud project Management Portal.
2. Navigate to Repos » 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 master.
4. Fill in the pull request details and proceed by clicking Create.
   
   

Approve and merge pull requests

Each pull request must be approved before merging the changes to the 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 project Management Portal, navigate to Repos » 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 will be marked as met and an automated CI build is triggered to test the changes against the master branch. To complete merging the changes, click the Complete button, 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 master branch, used by the Staging environment. You can proceed by browsing the Staging environment to verify your newly deployed functionality is working as expected.

Once you have verified your code works as expected on the Staging environment you can promote it to the Production environment. By default, each successful build to the Staging environment, requires approval from a user in the Contributors role before going to the Production environment. You can view builds pending approval to Production, and promote them by following these steps:

If you are using the New utility pipelines

1. In your Sitefinity Cloud project Management Portal navigate to Pipelines » All.
2. Select CI.CD.
3. Locate the Run that is pending approval to production and click Production.

NuGet package cache

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 be used in case packages change.

Partial deployments

The deployment process intelligently checks for the exact file changes between the previously deployed commit and the current one. If you have made changes only to files that do not require application restart, such as for example JS, CSS, TXT files, the deployment process detects this and performs a partial deployment, which is much faster.

If you are using the Old release pipelines

1. In your Sitefinity Cloud project Management Portal, navigate to Pipelines » Releases.
2. Ensure the Quantum.CD (Production) pipeline is selected.
3. Select the Releases tab.
4. Locate the desired release that is pending approval for Production and click Production.
   
   
5. On the next screen, proceed with approving the build.
   

As a result, an automatic CD build is triggered and upon successful completion the code is deployed to the Production environment.

Preview deployment is replacing the available deployment rollback functionality, which is a slower and complicated process. Preview deployment checks that the newly deployed version of the application on Production can start up and pages can be precompiled using a DB copy before switching to the 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.
This new approach is the first step towards advanced deployment preview options that can be added in the future - for example, executing custom automated tests, or manual review and approval of the deployed application before proceeding with making the new version live.

To deploy the .NET Core Renderer to Sitefinity Cloud, use the DotNetCoreRenderer.CI.CD pipeline. The rest of the deployment process does not differ from a standard Sitefinity CMS app deployment.

For more information, see .NET Core Renderer in Sitefinity Cloud.

To ensure transparency and traceability of the project’s deployments, more information about each pipeline’s releases and deployments, such as release and build version, branch, and queue date are available in the Deployment dashboard. For more information about Sitefinity Cloud dashboards, see Monitoring. Alternatively, you can also trace the status of each build from the Pipelines » Builds screen of your Sitefinity Cloud Management Portal.

In case promoting a new package fails, an automatic rollback of the project and database is triggered and handled by Sitefinity Cloud. During the rollback, the project files and database are restored to their last successfully running version.