In my Sitecore symposium session “Sitecore in the
enterprise: Optimize your time to deliver toward the speed of light, using all
the new love in Azure DevOps” (and yes that is a mouth full) I spend quite some
time on the “mono-package” approach. This blogpost what a mono-package is and
why it is (much) faster in terms of deployments as opposed to using multiple
web deployment packages.
Disclaimer 1: In this blogpost I talk (a bit) about
Sitecore, but it is applicable for any application that is being deployed using
msdeploy or the app service task in Azure DevOps. The blogpost “Sitecore challenges
on the mono-package approach” contains the specific challenges faced that had
to be solved.
Disclaimer 2: Some people might immediately be opinionated: “how could you ever end up with multiple packages, you have a bad architecture”. I understand your pain and in some cases you might be right. But there are cases where you have to deal with external factors, such as existing platforms and organizational challenges, where a layered approach is a not to weird solution.
Lately, I was preparing for a talk on Azure DevOps for the Sitecore community. For this talk I wanted to talk about scaling up and scaling out of build agents and compare the performance of different sized build agents on larger projects. Due to some limitations on the hosted Azure DevOps build agents, I had to create my own build agents. This blogpost will explain why I had to create my own agents and how I did this without too much effort. TLDR: just run a packer script to create your own private build agents
Microsoft recently released the Windows terminal in the windows store and I must say: I love it. Highly configurable, so I decided to create a small Sitecore theme for it. I hope you will love it! The code can be found here
Due to different laws (European as well as local legislation) companies have be very conversative in how they process data, while they have to take care on how they track people. People have to consent whether or not they will be tracked or not. Within Siecore, you might do both. This blogpost shares how to use your cookie consent strategy within Sitecore. In short: There are three level of cookies: Functional, analytic and tracking cookies. Without responding to the cookie consent, Only functional cookies are allowed, while analytics and tracking cookies is forbidden until a user gives approval for these kinds of functionality. Within Sitecore, this is hard to implement, due to the internal workings of Sitecore analytics and (from what I think) Sitecore bug. This blogpost explains why this is hard and how to solve this.PS: Different companies classify the Sitecore cookies under different levels. I have seen classifications of “Functional”, “Analytics” and “Tracking”. I won’t judge any choice, as I am not a person with a legal background and can’t judge on what all companies implement to prevent data from being collected. This is my personal view and the approach should be applicable to every level. This blogpost applies to Sitecore 9.X
I bet that a lot of people have this issue: Having a lot of (old) Sitecore installations that you don’t want to remove, as you aren’t sure whether or not there is still some valuable configuration in it. With a default installation, these installations grow over time, as they are running by default and are (thus) generating logs. I never change the logging settings to just generate logs for one day, which means they will eat up a lot of diskspace, especially the xConnect ones, as they might generate logs up to 1Gb per logfile in size!
The following powershell line can be used to delete all the logs which are older than 2 days:
Azure Search makes up for a significant amount of costs within a Sitecore on Azure setup; apart from these costs, there are often issues with Azure Search and clients tend to move away from Azure Search and spin up a new VM with Solr – But is this really mandatory?
this blogpost is part of a series of blogposts
In the Sitecore #azure slack channel
there are often discussions about pricing, scaling and performance. A common best practice which is shared in this channel is the use of Elastic Pools for your SQL databases. In this article I our findings, how you can compute the costs for elastic pools and how it will affect performance, as opposed to the default Sitecore ARM templates.
PS: the costs I share are all retrieved from the Azure pricing calculator
and are not actual prices from my company – I will never
This blogpost is a part of these blogpost series
In a previous blogpost
I showed a small overview of DTU consumptions of all Sitecore databases and how to use that overview to reduce your costs. This blogpost will explain step by step how to create that overview. An example of the file can be found here
After working for quite a while with a lot of Sitecore workloads on Azure, we have built up quite some experience with regards to scale and costs management. Although Sitecore has some predefined topologies
, there may be various reasons why they will work or won’t work for you. From what we have seem, those topologies are not the most costs effective ones and
having different requirements might lead to different choices in terms of what tier is right for you. This series of blogposts gives an overview of choices that could be made and a small indication of the costs estimation for two of the Sitecore of Azure workloads (the Single and Large setup). Please note that some choices might only be valuable for XP or only for XM, or even not be beneficial at all, as there is not cookie-cutter solution for everything.
although being a total JSS and
angular newbie, I wanted to create some nice forms, use an API and use some state in my application. The internet is full of solutions, but none of them fixed my issue. Read more after the break.