As a gold Sitecore partner, we are often asked to contribute at their Technical User Groups. They take place throughout the year and offer an opportunity for Sitecore developers to come together and discuss their approach to the platform.
Having spent the last two years building Sitecore platforms for our clients, I was invited to speak at one of these groups in London on the rapid delivery of a Sitecore-hosted site by using a ‘Vanilla’ template.
For those of you that didn’t make it, I’ve put together my key points below:
What do we mean by Sitecore Vanilla?
Sitecore Vanilla is a pre-installed version of Sitecore in its own repository that is maintained like an active project. It is configured to a standard that we have set out in a way that we believe is the best for building sites on this platform. It helps us to standardise everything and offer standard features that don’t have to be built or imported each time.
Whenever we start a new Sitecore build, we take the initial base from the Sitecore Vanilla repository so within an hour, we can have a ready-made and checked-in solution ready to tailor to the client’s needs.
What is the challenge?
We looked at our Sitecore builds and realised that we spent a lot of time in the beginning just getting it set up how we wanted it, installing all the modules and setting up templates, the config files and our MVC layouts and views.
Once the system was set up and checked in, we spent even longer adding new widgets that, apart from the design, were functionally similar to other ones we had written in the past.
We saw that we weren’t very efficient at building sites. We spent a lot of build time just re-implementing the same basic features; ending up installing the same modules like redirect and WFFM into every site along with the same homepage, site node and content page templates with a standard set of fields, feeling as if we wasted time.
Even if we just installed the packages and then took a package of the templates from the last site we built, it still seemed like it would be better to have this already built into the starting point. We were looking for a way to have all this work completed as soon as the project starts, so that we can have front end and back end developers on the project from day one.
The foundations of the Vanilla solution
For the Vanilla solution, we have a Git repository that we keep up to date with our latest ideas and changes. If Sitecore releases an update, we get it installed into our Vanilla solution as quickly as possible so that it is always up to date and ready for a new project to be created from it.
We have automated builds using Team City and Octopus Deploy so we can test it with unit tests in the build and user testing to make sure we have confidence that the base we are working from is solid.
The basic site that we have in Vanilla is pre-styled and cross-browser tested to make sure that from a front end point of view, all of the heavy lifting is already taken care of and we can just focus on styling the functionality to match the designs.
The site also contains all of the best practices that we have accumulated over the years, including a full set of SEO features, dynamic placeholders to enable content authors to easily create layouts and customisations to the Sitecore configuration.
Creating an initial build
We run automated builds on all our projects. It helps standardise and simplify the process and remove human error. For our Sitecore Vanilla build process, we run these steps:
- First, we run a NuGet package restore along with installing gems (for SCSS compilation), Npm packages (for Gulp tasks) and Bower packages (for front end dependencies)
- Now that all the dependencies are fulfilled and the static files are compiled, we build the actual .Net solution. This also runs Octopack which, upon successful build, will package up the entire solution into a package file and push it to Octopus Deploy which, in turn, deploys it to the continuous deployment environment
- Once Octopus Deploy has deployed the package, it runs some Powershell scripts that configure IIS and copy over the correct config files
We can then copy this build configuration and with minimal changes, a new project can be built using it.
Core components of Vanilla
We always keep up to date with the latest version of Sitecore and embrace all the new features. Most recently, we have been looking at ways to extend the Sitecore xDb and add more relevant data to contacts by making sure that all ways that could capture user data are reporting it to the xDb so we build up a good picture of the client.
We try not to change the Sitecore config files too much, but there are always things that need tweaking based on how you want the site to function. Some of the changes we do have are a custom site node pointed at our items in Sitecore, a custom 404 resolver which generates the correct responses and a modified link provider. We also set custom indexes for the navigation and search, among other things.
The front end benefits from a lot of standardisation as well. We use our own custom framework built by one of our front end developers, which means we always know exactly how to change it and tweak it to each individual site without having to spend ages trying to force our customisations over the top of a commercial framework. It also means that the basic styling is already done and we will just have to create a new style guide and then style up any new elements to match the designs.
We also have the basics of a site already configured, with a homepage, 404 page, content page and content left navigation page. We also have sitemap functionality, robots.txt and configurable navigation already built and configured. This really allows us to focus on some amazing and unique features instead of just re-implementing the basics.
The future of Vanilla
We will continue to develop the Vanilla site further to enhance our basic offering and make it as advanced and feature-rich as possible. Some of the things we currently plan to include are:
- Pre-set up workflows
- Introduce an ORM (Object Relational Mapper), which takes care of mapping our Sitecore items to our code-based models, enforcing stricter standards and streamlining the development process
- Turn some of our customisations into Sitecore modules and post them on the Sitecore marketplace
- Remove Sitecore from the repository and just store our custom code. Currently, there isn’t a perfect way to do this, but we will most likely have to create a private NuGet feed to host the Sitecore packages
Also included in the slides is a discussion on our responsive shelf system, something we put into all of our sites enabling content authors to design their own layouts and content with ease, in addition I will explain a few issues I have had to solve recently with Web Forms for Marketers in Sitecore. I will be writing additional posts in the near future discussing these aspects in more detail.
Follow the link below to download the slides:
For more information on Sitecore please click here.