When thinking about Continuous Integration and Continuous Delivery for Sitefinity CMS, we should think of those processes as the standard ones that are applied to ASP.NET applications.
First we choose the environment—single server, multiple servers with load balancer, Azure or Amazon. In order to automate the delivery process and eliminate manual work for Sitefinity CMS, we need to know the specifics of the product and how to manage projects between environments.
Here are the main aspects of Sitefinity applications that we should focus our attention on when it comes to the continuous delivery process:
For all of the above, we apply individual approaches when we sync between different environments. Let’s take a closer look at each of them and the main flows that we should follow during continuous delivery.
Delivery Flow
The foundation of each continuous delivery procedure is based on a specific flow.
If we simplify the above it looks like this:
It is important to note that only the code implementations and configurations are going from dev to live. The only thing that comes from production is the Database.
Before we deploy something on our live servers we need to go through many testing environments to make sure that everything is working well and all our tests are passed. Here is a flow chart from a real world scenario from the telerik.com web site.
In some cases we have only one test environment but it always depends.
For small websites, a single server is enough to handle the load. For the rest of the scenarios where we need to handle large amounts of traffic, scalability is necessary.
To handle traffic and load, we need to distribute it to many machines and use a load balancer.
One of the most popular, simplest and widely used techniques for distribution is round-robin. Progress adopted this approach for the telerik.com web site. In order to avoid complex updating between nodes, we need our configurations to be split between DB and config files. With Sitefinity 9.2, its auto mode of storage configuration property automatically solves this.
When it comes to the cloud, we always think about scalability and availability. The good news is that Sitefinity fully supports deployment in the cloud without any issues. Before we decide which platform to use we need to be very well informed about our case. We can find a good comparison table between Azure and Amazon that can help us to make the better informed choice here.
With Azure we have two options—a virtual machine and app services. Some guides on the web conclude that App Services are the preferred option in many cases. You can find our internal guide how to deploy your Sitefinity application to Azure here.
With Amazon we need to create a virtual server and host our application on it. You can find our internal guide how to deploy your Sitefinity application to Amazon here.
All of the code implementations and configurations should come from the Dev environment to Production with the help of the source control and builds. The only thing that is opposite to that workflow is getting the Database from Production/Test and adding it to Dev. If we follow those two major rules there shouldn’t be any caveats or issues.
The flow here is pretty straightforward. When we check-in to the source control, a build is triggered and all of our tests are executed against the new code base. If all of the tests pass, we can promote the new version to the UAT and Production servers. Here is an example of what the delivery pipeline could look like.
For back-end structures we should consider dynamic modules, custom fields for built-in modules, taxonomies, sites and web services. With version 9.2, Sitefinity delivers functionality that helps us to export all of those types and import them easily. Keep in mind that only the structures are exported, not the content.
To import them we need to add the folder into our application and check it into the source control. When the website is started in the new environment, it automatically imports everything.
One of the most common use cases that this feature solves is when we add a dynamic field to an existing type and we want to have it in our production environment. Until now, the process included a lot of manual work and potential for failure because we would create it in the Dev environment as well as the other environments in our pipeline. The other case is when we want to remove a field from our content module. The process here is in two steps. First update all the widgets in all environments not to use this field anymore and once the column is free, remove it with a new update of the structure. This approach is very handy especially in load balanced scenario when you have multiple nodes and you have to update them one by one.
Here is an example of how the above procedure should be executed:
If we want all of the synchronization to be automatically applied to our particular website without any manual work, we should enable “Configure by default”. The system will then apply everything in our project and all of the dynamic content types will be visible when the site starts for the first time after a new version is deployed.
To have the same content through different environments, we need to use SiteSync. With this feature we can instantly sync content or schedule it for a particular date. In terms of continuous delivery, we are covered with the option to schedule our syncs (e.g. every day at 5:00 am).
Before we discuss how to sync environment and application configurations, we need to define them.
For the environment configurations we need to have different values throughout different development environments. Also we don’t want to change them in the back-end. The best way is to have different config files between the environments and change their values with the help of transformations. Those settings should be kept in the config files of the system.
The application configurations are settings that are changed during runtime and should be kept in the database. That separation is needed in order to avoid cases where the config files are updated with the latest version and all of the configurations made during runtime are wiped out.
In addition, this keeps the continuous delivery process more straightforward and, in load balancing scenarios, we avoid any complications by having the same environment configuration across all nodes—only the application settings are shared in the DB. This way the update of every single node is easy and the downtime is minimized.
It’s really easy to achieve this since the system will take care of which settings should be in the DB or in the file system if you simply set the configuration storage mode to Auto.
In order to be certain that no one is can change the configuration settings in the back-end system, we should set the configuration mode to “read-only.” This is the recommended option for each Test/Live environment so that we can be sure that environment modifications will be done only by developers in specific config files.
With the latest release of Sitefinity, all of the necessary functionality to fully cover the continuous delivery process are now available. The first step is to identify your scenario and how many environments you need. Then you can follow the complete guidelines from the documentation and avoid all of the manual work.
Peter Filipov (Pepi) is a Product Builder focused on building the future of Sitefinity, relying on the newest technologies such as .NET 6 (and up), React and Angular. His previous experience as a Developer Advocate and Manager of Engineering helps him to understand the customers’ and market needs of Sitefinity. He also is passionate about being active and healthy.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Learn MoreSubscribe to get all the news, info and tutorials you need to build better business apps and sites