When Progress Sitefinity 14 DX was announced, Allegiance Group was thrilled to learn it would be based on Microsoft .NET Core. Advancing the version of .NET past the legacy .NET framework and to the new .NET Core brings Sitefinity into the future of .NET development. The Microsoft .NET language (they remove “Core” from the name starting with version 5) is rebuilt from the ground up and can run on multiple platforms including Linux. This means you are no longer tied to Windows machines for development or deployment.

Why should you care? All this is important to our clients because we are constantly looking for ways to optimize our process and reduce costs. And these improvements help bring down Dev Ops and operational costs during builds, the advantages of which we pass on to our clients.

Allegiance Group uses Docker Desktop for local development and containerizing applications for uniform deployment across different environments. Using docker for local development allows each developer to get up and running much more quickly than provisioning virtual machines or servers to host applications. Docker also allows for the infrastructure of the containers to be versioned and maintained in source control. Any changes can be pulled, tested, and distributed to different environments more easily and in a more structured way. Containers can also be deployed to different (or multiple) cloud providers such as Amazon Web Services, Google Cloud, and Microsoft Azure.

Now that Sitefinity 14 is running on .NET we can easily run our builds in containers. This could have been done before, but it required much more time to spin up the necessary .NET Framework Windows container as they require more time, RAM, and CPU to run and debug them. (Note: we weren’t totally able to get away from a large windows container, you can see why below).

Now, to the fun part. Sitefinity 14 is set up to run as a three-tiered architecture setup: the data tier, the backend, and the front end. Using Docker Desktop for local development makes it easier to develop and deploy a multi-tiered architecture. We set up each tier as its own container in our solution.

1. The data tier:
   The data tier is set up as Microsoft SQL Server 2019 hosted in a Linux container.  Setting this up as a Linux container meant it would take less space and memory on the local machine.  Each developer will have their own copy of the database. Each Sitefinity instance can also use the same version of SQL server that will be used in production, which is particularly important as SQL Server is not backward compatible.  Taking backups from a SQL Server 2019 server will not work in a SQL Server 2016 environment.  This caused headaches for developers in the past as they had to ensure they set up SQL server versions to match whatever the production environment was using, which could be different for different sites.  With Docker, you can set your container to the version you will use.
2. The backend tier:
   The backend tier is set up using a Windows 2019 container with .NET Framework 4.8 as a base.  This container is used to host the backend Sitefinity CMS, which is still based on .NET Framework.   In the future, as the backend gets upgraded to .NET, we can switch the container and just use Linux.  For now, we must use the Windows container, which requires us to run Docker Desktop in Windows container mode and in “experimental” mode to allow both Linux and Windows containers to run on the same system.
3. The frontend tier:
   This is running a Microsoft Windows Nano container, a small Windows container used to run .NET projects.  Visual Studio automatically uses the Microsoft Windows Nano container for .NET projects when running Docker Desktop in Windows containers mode, and these containers have a much smaller footprint than Linux containers.  Linux containers are the standard, though, as other 3rd party containers are usually built on Linux.

Speaking of other containers:

Using containers means you can add additional containers for other services your project may need, i.e., Identity, Search, Email, etc. We included an example of using an additional container with Sitefinity in our solution by tacking on an Elastic Search container. Elastic Search works natively with Sitefinity, so we thought this would be a beneficial use case for many people. The Elastic Search container is built on Linux and runs seamlessly in our solution. We did have to use version 7.x for local development as the newer version does not work in experimental mode yet. This can easily be changed for production by providing an override file. We will go over that in a future blog post about deployments.

We have set up a blank Sitefinity solution as a starting point for a new project and the Quantum Sitefinity solution to showcase a fully working site using Docker Desktop and containers.   Please pay close attention to the ReadMe file for each project, as they contain more information about the setup and use of each solution.

github.com/renjohn/SitefinityDocker – This is a blank Sitefinity solution that you can tailor to your needs.  It comes with Elastic Search and has been modified to use Clean Architecture, which we will discuss in a future blog post.

github.com/renjohn/SitefinityQuantumDocker  – This is the sample site provided by Sitefinity running in Docker containers.  This can get you up and running quickly with a sample site for training or demos.  We will also use this site to demonstrate a different way of creating custom modules for Sitefinity 14 in .NET in another blog post.