All Posts

I've used the Wildcard Page concept within Sitecore in a couple of solutions for clients in the past and have always enjoyed the clever piece of design that they are each time I've done so. I recently proposed using a Wildcard page solution in our Sitecore 8.2 Azure PaaS solution using Azure Search and decided to share some of my initial thoughts and learnings here.

During the move to Azure PaaS there have been a few instances where we've noticed a series of errors being logged about file I/O issues which often result in instances dying within a PaaS "load balancer".

As a 'back in the day' Sitecore developer I used to do more with Sitecore Queries than I'd care to admit. Recently I was looking for a 'good' way to set up a rendering with a default location which worked in a multi-site solution and was playing with Sitecore Queries once again. It occurred to me that the tooling that used to be available is no longer accessible through the Sitecore back end.

I have discussed the Helix design patterns before and I really love their modular approach to code architecture however whilst trying to discuss this with some colleagues and working out the cleanest way to work with Helix and a Multi-site Sitecore solution it occurred to me that if you are familiar with the "Enterprisey" Three-tier design architecture principles, well the same principles can be applied to your Helix development at a modular level.

It's been quite some time since we started our journey using Sitecore 8.2 and Azure PaaS. There has been no small amount of experimentation, failings and most importantly, learnings as we worked towards an automated build and release pipeline using VSTS so I thought I would take the opportunity at long last to share some of my experiences.