Back in November, Delete attended the Sitecore Symposium conference, in Florida. This post provides insight from a presentation delivered on Day 3 by Desta Price, EVP Product Management at Sitecore.
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.
Using Bitbucket for Source Control
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.
Using TeamCity for Continuous Integration
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.
Using NUnit for Unit testing
Our developers prefer using NUnit and for mocking up Sitecore content structures. Also for unit testing we employ the Sitecore.FakeDb library.
Using Selenium 2 and NUnit for Automated Integration Testing
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.
Using Web Deploy for Deployment
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.
Using Unicorn and Sitecore Powershell Extensions for Sitecore Content Deployment
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:
- Definition items - these items are usually owned by development teams and created as part of any implementation. These usually include: layouts, renderings, templates, fields, placeholder settings, custom field types, user profiles templates, lookup items for settings, etc.
- Content items - these items are owned by content authors and store the content that is displayed. This can be page items or items used as data source.
With this in mind, in our strategy we use two tools for these two different types of items.
- Definition items are managed by Sitecore Unicorn - which is a great and free tool that’s simple to use and fast. During deployment, Unicorn files are deserialised and the related items are updated.
- For content items and third-party packages we store them in a single folder in the repository containing Sitecore packages. We create Sitecore packages only when a new section is created and it needs some content structure to make the site work. We have a custom script using Sitecore Powershell Extensions that takes a list of packages from the folder and installs all new ones. It’s run by both developers on their local machines and by CI servers during deployment.
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: email@example.com.