So I finally got home last night at 1 am here in South Florida from New Orleans, the location of Sitecore Symposium 2016. This years event was great, though I might be biased because this was my first Symposium, but I’m hoping I’m lucky enough to attend more Symposium’s in the future. Either way I thought after having a chance to reflect on the event and how it went, what takeaways I had. Since I’m a developer, these are more focused towards that end, but development within Sitecore impacts all other practice areas of Sitecore including Content entry and Marketing. So let’s get started:
This one word represents a pretty large shift for Sitecore. It represents a new recommendation for how you should architect websites in Sitecore. I think it was important for Sitecore to do this, because without a recommendation, every site I’ve come across has been developed fundamentally different than how I’ve developed sites, because although Sitecore has showcased sites that they show how you can build a Sitecore site, they have come out and laid down a specific blue print of how they should be architected.
So what exactly is Helix, many of you may be asking. Like I said it’s just a recommended best practice by Sitecore of how you should architect Sitecore sites/tenants and the modules that make up those sites. This guideline is not a technical recommendation of the architecture used to support Helix, that is still left up to the organization. Which I’m really glad they did that, because not every organization is the same.
Some have probably heard of Helix used when discussing Habitat. Habitat is not a starter kit, which is one of the biggest confusions I’ve seen when hearing people discuss these two terms. Instead of a starter kit, it’s an example of a site using the Helix pattern. Now having said that, if you wanted to use the Framework and maybe some of the patterns from a technological standpoint in your next Sitecore project that’s based on the Helix principal, that would probably be a good idea.
Testability of Sitecore 8.2
This was an eye opening discovery. I hadn’t heard about everything about 8.2 and what features it was introducing, but they introduced the ability to test (either via Mocking or Substituting methods or properties that are overridable) Sitecore’s core API. I’ve had this discussion a lot with other Sitecore developers about how you can easily test (unit test) Sitecore. There are ORM’s that can help do this, but you can easily do this out of the box.
DevOps for Sitecore
So DevOps itself isn’t a new topic for Sitecore, and it’s been a challenge with some of the things related to Sitecore installations for DevOps to occur correctly. But the biggest change I saw during Symposium which was mentioned in several courses was the introduction of specific environment variation ARM Templates. These specific ARM templates could of course be taken from what’s provided and then adjusted to fit organization specific needs. If you’ve never heard of ARM, it stands for Azure Resource Manager, so you can build custom ARM templates, which define the environment to create when release a project. Example, you could have a Stage Deployment ARM template. So you could have part of your release management the process or spinning up a new environment with the build that you are releasing, based on this ARM template. Once it was complete, you could be sure that everything had been setup exactly as it was in the previous environment.
I’m actually quite passionate about DevOps now, and see so many reasons why you should start automating the process of setting up environments for clients and internally. It allows you to take out the human element of setting up an environment. We’ve all been there when configuring an environment manually, something always seems to get forgotten. Automating the process removes that possibility.
Other topics that could’ve made my list was the shift to using Accelerators, such as the introduction to Sitecore Experience Accelerator. However as great as some of the accelerators seem, I still have issues with them. If you are starting out on a new site and want to use them, they probably are a good option. But they still are limited on exactly what you can do with them. If your goal is to build a simple content based landing page, they they are perfect for that. However they (both SxA and Score) has problems because they don’t work with custom generated content. So if you wanted to have a blog or some other type of custom content, you would still need a developer. This solution will not solve that scenario. So it’s great if you want to throw together a landing page for ad campaign or some other basic page functionality.
There is a slight difference in SxA, it’s been promoted as being a wire framing tool as well. It will allow the UX department to wireframe (without having a design of the page) or even allow business users to creating wire framed versions of their landing page. For example, if you want to create a basic page, with a navigation, content on the left with a form on the right, you could create this in the wireframe mode, and then that wireframed code could be sent to a design and/or front end dev team to create the theme for this wire framed page.
This featured sounds amazing on paper, but it actually isn’t as good as it sounds. So lets say you were going to wireframe an entire site in SxA. This feature would be great for all the basic pages for the site, but how would you handle pages that are a little more complex such as a Blog or Events. Generally a development team needs wireframes to create such components, but they can’t do that within SxA because they need to exist in order to do this. And they can’t be wire framed without having the component developed. So really this wouldn’t work for most development companies.
Also I see a lot of developer trends from the topics discussed at Symposium. Some of these trends include the fact that Unicorn is being used by alot of Sitecore developers, and alot of frameworks or example projects (even those pushed by Sitecore themselves such as Habitat) use Unicorn. I’ve always used TDS, but I’m going to start exploring the implications of using Unicorn, maybe we will never shift to using it at an organizational level, but I think using Unicorn for Open Source projects that will have community involvement makes complete sense. Another popular shift is that no one is using TFS version control anymore. It’s all about Git now, which is something I only have limited experience with.
Overall as you can see, I have a lot of takeaways that I can use to build better processes from this conference. For those that attended, what takeaways did you have from the event?