One of the most important things when designing a Sitecore solution is how you intend to deliver aspects of the solution. In many cases this could be large scale releases of the whole implementation, but in my experience this only serves to limit cadence and increase complexity of delivery over time.
“Modularity refers to the concept of making multiple modules first and then linking and combining them to form a complete system.”
In the case of many Sitecore projects, it can be considered that Helix shows one approach for a component based software solution (strictly speaking in c# is by nature modular as a module is considered to be a an assembly).
A common use case you hear from content editors is to add the ability to ‘auto-publish’ content so that they can schedule the introduction of new content to the cms. On some of these occasions, this can be achieved by applying a window to content rather than attempting to publish it in a given window.
It is worth noting – to make this a more complete solution, additional work may be required to ensure links etc do not show, this has to be treated more specifically.
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.
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
Well – another SUGCON EU has been and gone and I was very proud not only to present, but to be a part of such an awesome community 😀
I particularly enjoyed:
Brian Beckham’s – “SITECORE USING PLATFORMS AT ENTERPRISE SCALE”: A great and positive insight to some of the challenges faced when really trying to push the boundaries of multi-tenant builds in the enterprise space.
Nick Hills’ – “DEVOPS WITH SITECORE IN THE CLOUD”: Thought Nick did a great job of giving real world insight into the world of cloud based devops using cases from a large scale client running on AWS.
For those who were gracious enough to watch my demo, I truly thank you. As promised, you can find the code from my demo from my Github page here:
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.
Sitecore Boost received a small but important bug fix to relax the caching of Rendering Items for renderings added on standard values.
Following on from my first introduction to Sitecore.Boost post, I have made some further improvements.
Before delving into the results of the announcement, Sitecore.Boost patches will also work for Sitecore pre 8.1 😉
You can find the project here: https://github.com/cardinal252/Sitecore.Boost
A small update has been released for Sitecore.Boost. This update results in the following:
- An approximate 61% improvement in rendering performance over Sitecore 8.1 OOTB
- An approximate 84% improvement in rendering performance over Sitecore 8.2 OOTB
Using all boost patches on both 8.1 and 8.2, this results in Sitecore 8.1 being 67% faster than Sitecore 8.2. Sitecore 8.1 is still slower than its predecessors, so the trend continues – at least this takes it some of the way back 😀
Happy boosting 😉 😀
For a while now, I have been (not so) quietly working away on performance testing on various codebases as well as Sitecore itself for varying clients and my own satisfaction.
You can find it here: https://github.com/cardinal252/Sitecore.Boost
What is it?
With the concepts behind some of this work, I decided to create an open source project to allow others to see what has been done and contribute their production tested performance patches for the Sitecore platform.
This project contains a test harness setup complete with jMeter tests & serialized content.
The test content when deployed renders ‘Hello World’ renderings varying by the following:
- Number of renderings – 10 to 25
- Output Caching – Cached on Item, Cached on Standard Values, Cached on Rendering Definition, Uncached
- Rendering type – Controller / View Renderings
- Model – With / without
By putting the Sitecore rendering engine under load and performing profiles (using your tool of choice), many areas of Sitecore have shown consistent traits that can benefit from optimisation to their code.
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: