Jeremy Davis
Sitecore, C# and web development
It seems everyone is suddenly an expert in this exciting new tech. And if you weren't paying attention, you may have missed the joke behind all of this – that it's an entirely made-up technology. Funny as the twitter shenangans were, I think there's a point hiding here for us as developers. What is it? Well...
My previous post talked about the interesting technical changes that Sitecore is achieving through acquisitions. While talking about that with assorted developers, one worry I've heard a few times is "how does all that technical change affect my career?". There seems to be a common thread of worry about how this change might devalue people's experience.
So does it?
If you're paying any attention, you can't have helped noticing that Sitecore have been on a bit of a spending spree recently. They've acquired three new companies, and hence there's a lot of talk in the community about what this might mean for the future of "being a Sitecore developer". This topic came up on the US Sitecore Lunch recently, and that prompted me to think about it a bit more...
Deploying Sitecore (or anything else) in containers has been a big learning curve for me. Every so often I come across a new aspect of the whole business that I've not seen before. This week, another agency's work showed me a new thing which might help with making changes to Kubernetes config. The approaches I'd seen to deployments involved pushing all of the Kubernetes config each time you want to release, but it turns out you may not need to do that...
I've been slowly improving the release process for the container-based project I'm working on. There's a lot to learn about the ways to configure the Azure Devops pipelines for this work, because targeting Kubernetes is quite different from the old IaaS and PaaS approaches I was used to.
One of the interesting things that's arrived with Sitecore v10.1 is a new approach to how items get updated when you change versions. This change is aimed at containerised deployments, and I'm in the middle of a containerised project. So I figured I should take a look...
An issue I've bumped into a number of times over the years, is that sometimes developers want to be able to look at the query that got generated when they did something with Sitecore's ContentSearch APIs. The traditional answer of "go look in the logs" is one way to deal with this, but some recent project work got me wondering if there were alternatives...
Ever had a tool that works reliably suddenly not work? I had a problem like that recently, and it lead to some experimentation that I think I may need to come back to later. So this is mostly so I can remember what I was doing when I get back to this. But as we move toward a more "platform agnostic" with more use of .Net Core on Linux, maybe there's something here that might help you too...
Last time out I was thinking about some choices around setting up Sitecore in Kubernetes. Since then, I've moved onto the more practical task of trying to get the setup to work. And I doubt you'll be surprised to hear that I've met a few new issues... Maybe they'll help you save yourself a bit of time and frustration?
I'm in the middle of trying to plan out the transition of a Sitecore 10 development project from PaaS deployments, over to the Azure Kubernetes Service. There's some great info out there, but there have also been some interesting things I've wondered about that seem less documented right now. So here are some things I've learned this week:
