Bridging the Gap – Devops on Sitecore I

It’s been a long time.., and… as some of the inner circle already know.. I have defected …

Well.. by defected, I mean I am no longer a developer by day (still helping on Glass and some project work by night.) I decided that I would try and make an active change in my working in life to start working in the arena I feel plagues most projects I have worked on… Delivery (DevOps)..

I thought I would start looking at a series focused more on delivery of systems and solutions on the platform including commmon scenarios, potential solutions, etc.

Continue reading


Who do we (back end developers) think we are?

I know this may well be one of my controversial views, but… One of my pet hates of the modern era of Sitecore development is the insistence that front end developers work in the same place / same way as back end developers. I have been involved in many projects (100s for sure), small and large and on differing technologies. Whilst this approach can work ok on a simple MVC application, I think it is pretty poor on the Sitecore platform and here is why: Continue reading

Sitecore Boost Release

Today I have released a minor update following community feedback, this should hopefully address a few issues seen on Content Management instances. This release disables the cache usage except when the page is running in normal mode.

CI / CD Build Tooling for Sitecore

Being a sell sword, I can comment on a lot of different stacks (along with providing my preferred). Following on from a discussion Sitecore Community – CI / CD I thought I would share my thoughts a little on this subject:

Fundamentally most Continuous Integration / Delivery environments involve the following elements (in a very rough ordering): Source Control > Build Tool > Automated Testing Tools > Code Metrics Tool(s) > Deployment Tool(s) > Sitecore Content Deployment Tools > Environment Scaffolding > Monitoring

Before I go any further, I think I should state what I believe to be the MOST important goals of your CI build environment.

  • The simplest to manage / manipulate. The tooling should get out of you way and soak close to zero time.
  • Should be maintainable by the majority of the development team, not ‘key holders’.
  • Deployments should be done by non-developers.
  • It just works – once set up, you shouldn’t have to tinker with it.

My biggest bug bear of any system is where only the Solution Architects / Team Leads can manage the build process. QA’s testers / product owners should be responsible for sending stuff to QA / Production (if there is to be ANY human involvement at all).

So hear it is split down by element:

Continue reading

Advanced Content Security Module (ACS) Released

A while ago I started the process to soft release a little module I have been working on. It is called the ‘Advanced Content Security’ module (ACS). It’s primary purposes are the following:

  • To provide alternative layouts to pages that are ‘restricted’ but not unreadable by users – think the average newspaper site that allows you 10 views before you have to sign up.
  • To provide rules based read and restriction security
  • To provide a rules engine based solution to the initialisation of users

Today, the latest version was approved and added to the market place.

For a more detailed overview, you can find more information about it here:

The source code resides here:

The module itself can be downloaded here

The constructor ‘work done’ dilemma

In a recent Glass release I was working on an issue that led to Mike making a comment on how I work as a programmer. The particular issue in question was actually quite straight forward to solve – I wrote unit tests that showed the issue, wrote some sandbox tests that showed how code behaved in the underlying Sitecore library, then fixed the tests approriately. All typical of TDD. The normal thing for me though is then to write a unit test that performs this simple fix 1,000,000 times emitting the result of stopwatch timings at various points. Mike jokingly commented at the time that this was ‘typical Nat’ which, to be fair, he was right on.

In this post I will look at the effect on work done in the constructor and how it has affects your development life in the context of modern DI practice – in particular – the DI principle.

Continue reading

Using RequireJs to manage script dependencies based on attributes in your Sitecore Solution

A common architectural issue I hear amongst developers is how to prevent Sitecore loading all and sundry when it comes to javascript dependencies. Indeed it is often the case that front end developers don’t inform us or assume that we will use a single page type model and therefore don’t really need to worry about the number of script dependencies. The reality is that in actual fact if we included every script that a front end developer used throughout all of the scripts within the site – we would have 20 odd script tags in our markup, something you may well be keen to avoid.

As a solution to this, myself and many other developers including former colleague and Sitecore Solution Architect Richard Seal in his post Using Require to Organize your Sitecore Javascript opt to use an advanced module loader such as RequireJs. If you haven’t used it before, I recommend first reading their documentation as there are definite ways to write your javascript (and in particular jQuery) code to maximise your success with it.

Continue reading

100% Code Coverage for Unit Testing is attainable (even in Sitecore)

This should hopefully be a short and probably quite marmite post.

As the unit testing debate rages on with should we / shouldn’t we? How much does it cost? How long does it take? How much of it should we test? I have continued developing my skills as a developer, lead and designer of solutions. During this time I have learned a lot about approaches to unit testing and how I could achieve better ways to test my solutions.

I do qualify what I am about to say with the following: I have been doing automated testing in some guise or other since the middle of the last decade. As such, I have been through multiple generations of the pains that developers now face in the modern era (believe me when I say, the record / replay model for early mocking frameworks was far from the ease of the current NSubstitute / Moq we have now). Also – code coverage is a metric, like all metrics – it has it’s place and I believe that it is a very worthwhile one to isolate out untested (and often potentially flawed or unknown) area’s of your codebase. As a metric, it has to have some intelligence applied the other side of it to see what it is that is untested and refactor / test accordingly.

The Common Arguments & Questions
I am going to set aside the should we (not) unit test our code. My belief is very simple – we should and we should also achieve 100% test coverage. Below are listed some of the most common ones which I will cover.

  • It has no logic – why should I test it?
  • It is too difficult to test.
  • It takes too long to write tests

Continue reading