6 May 2021
For people who have been working with the Sitecore CMS for a long time, their acquisition of Boxever might seem like a bit of an odd choice.
We’ve recently seen a number of discussions on Sitecore Community Forums about the modern development processes needed to support the automation of site builds and the testing and deployment of code. So much so that we decided to weigh in and offer our thoughts on the toolsets we use to support this process, in the hope that it will help make things a little clearer on this subject.
We store all the files related to the Sitecore solution (source code, tests, Unicorn files, third-party Sitecore packages etc.) within a repository for each project.
We have also been using JIRA’s software development tool for many years and it integrates well with Bitbucket. JIRA also has a new (and little known) code review feature which is loved by our Sitecore project architects.
We tend to use a common branching strategy for all of our projects with three base branches, these are: default, staging and live. Also, we can have additional ‘feature branches’ for any extra tickets raised.
In the past we have used Jenkins but recently switched to TeamCity. The main reason for this was that we wanted to use it for deployments as well, and TeamCity has far better error reporting and alerting functions than any other CI server. What’s more, using this means we only need to read the relevant information on the build log - which is of course a big time saver.
Currently, we use a set of build agents to run builds and for unit testing while running on the CI server itself. This also ensures there are dedicated build agents for each environment for deployments.
These ‘deployment agents’ are only responsible for retrieving artifacts from the CI server and for deploying them onto a server in the client’s environment. For security reasons we also configure these agents for ‘unidirectional communication’ - basically so we don’t need to open any additional ports on the live environment firewalls.
Our developers prefer using NUnit and for mocking up Sitecore content structures. Also for unit testing we employ the Sitecore.FakeDb library.
Our QA Team creates end-to-end real browser tests using Selenium 2 and writing tests in C# in NUnit format. This is because using the same C# language and common framework for both tests and code allows backend developers to create and update integration tests by themselves without needing additional help.
We also run automated integration tests after each staging deployment or in UAT, to ensure that there are no bugs.
We use Web Deploy because it’s Microsoft’s default tool for deployment to IIS and it can be easily installed and scripted to pack and deploy sites.
This ensures that our CI server first builds a Visual Studio solution, before then creating a package containing all needed files (including all Sitecore files). The deploy agents can then pull the package and run Web Deploy to deploy the site to all the servers in solution.
A big part of every Sitecore project actually consists of managing the items (sites, sections, templates, settings, layouts, etc.) that are created in the Sitecore database. Recent Sitecore Helix guidelines also highlight the need for a clear strategy to manage any changes to these items.
There are two types of these different items to consider here, these are:
With this in mind, in our strategy we use two tools for these two different types of items.
Hopefully with the above recommendations you and your team should be on the right path with the right toolsets to support the automation of site builds and the testing and deployment of code. If you need any further advice, why not drop our team of experts a line on: firstname.lastname@example.org.