XM Cloud (SaaS) is here! Part 2 - Setting up a project

Part 1: Provisioning an instance

Part 2: Setting up a project (this post)

Last post showed how to create an instance when a project were already set up. Now let us look at how we can add a project in the portal and associate it with a Git Repo.

But first, what does "project" mean in the XM Cloud portal?

A project in XM Cloud is referring to a single Sitecore instance. That one project might have multiple sites in the content tree just as we are used to with "on prem" Sitecore versions. The XM Cloud project typically will have one production instance and a number of non production instances. So basically what we are used to when working with a Sitecore project in the old fashioned way ;).

So let us create a project:

Go to "Manage my projects" and click on "Create new project". A prompt will ask if the new project should be created based on an existing XM Cloud code base (maybe you have already done some work offline before connecting with XM Cloud portal) or if you want to use a starter template. There will be more choices in the future. 

I am going to choose the starter template as I have no existing XM Cloud repo in my GitHub

This template gives me a very simple sample site with a few components built in Next.JS. It is highly likely that the options to choose from has changed the next time I do this as the product team is working on more starter templates.

When clicking next, step 2 is to choose the project name. This would typically refer to the actual site(s) being build in the project. So if it is the company main site the project is for, using the name of the company would be obvious like "mycompany-website" or similar.

Step 3 is choosing the repo the project should connect with. For now GitHub is available, but more. like Azure Devops, is on the roadmap. You can use any repo with XM Cloud, but that would require manual configuration for now.

In step 4 it is possible to choose from already connected GitHub accounts or set up a new connection. 

When setting up a new connection, the guide will ask you to authenticate that the Sitecore deploy app gets installed in your GitHub account. 

After connecting to a Github account, step 5 is to choose a name for your Repo in GitHub

Last step is to choose the environment name, like "test", "qa", "production", etc. and then choose if it is a production environment or not and if an automatic deploy should happen when committing to the chosen branch the environment points to.

That is all to get a new instance live in XM Cloud and a code repo created as well. Now the full repo is available in GitHub and developers can clone and work with the project locally by enabling the docker container that the repo contains by default. This will be the focus of the next post in this series ;)

XM Cloud (SaaS) is here! Part 1 - Provisioning an instance

Part 1: Provisioning an instance (this post)

Part 2: Setting up a project

Intro

If you have not heard about the hype, here is the short explanation: 

XM Cloud is a new offering from Sitecore based on the existing Content Management product called XM.

BUT there are differences. Major ones are:

• It is a full SaaS solution hosted and managed by Sitecore
• XM Cloud will have baked in personalization and analytics (based on Sitecore Personalize and Sitecore CDP)
• It will include Experience Edge, a CDN layer where content is published to as JSON data (truly headless)
• It will NOT have any support for CDs (Content delivery instances). So NO support for MVC based sites
• A brand new portal where new instances can be provisioned with a few clicks (which will be the topic of this first post)
• Brand new UIs for the editors called Explorer, Pages and Components (which will be the topic for upcoming posts)
• The frontend is build in any modern Jamstack framework like Next.js, Vue, Angular, etc. using GraphQL and/or the Framework SDKs

For a high level intro, also see https://www.sitecore.com/products/xm-cloud

Deploying an XM Cloud instance

So before taking advantage of XM Cloud we obviously need to deploy an instance. 

An instance or environment as it is called in the portal, can be created when a project has been created. I will cover project creation in part 2.

Creating a new environment is done through the new portal (screenshot below) when clicking on an existing project.

Within the portal, multiple projects can be managed. A project is typically equal to a website or multiple websites with same content tree. Within each project there will be a number of instances, one being the production instance and then one to x number of non-production instances like QA, Test, Staging or whatever the organization needs.

Provisioning a new instance is done by just clicking the "Create new environment" within the project and then follow the guide:

When connected with a Github account the environment can be associated with a branch automatically and trigger deployments whenever there is a new commit to that branch. 

For now Github is supported out of the box, but there are more on the roadmap like Azure DevOps. Using the CLI any code repository can be used with XM Cloud

When clicking "Create" the provisioning starts and you can follow the progress and see output from the different steps:

At the moment it takes about 3-10 minutes to provision a full XM Cloud setup which includes a CM server, adding the new UIs, connecting and provisioning the CDN layer (Experience Edge) for publishing the content as JSON data and setting up GraphQL endpoints.

The goal is to bring this time down to maximum 5 minutes. 

When provisioning is done, the full environment is available and you can log in to the back end as it was any other Sitecore instance (Dashboard UI updated a bit). 

The big difference is that Sitecore hosts and updates the instances for you and new features will be added over time. There are a few new apps in the UI and the UI has also had an overhall. Pages is one of those new apps which I will cover in a coming blog post. 

That is all for provisioning a new XM Cloud instance, all it takes is about 5 minutes!

Next part in this series will be a step back and looking at how to set up that first project (needed for deploying instances), hook it up to Github and get the local development environment up and running.

After that there will be a sneak peak of the new Pages UI, followed by more details on how to work in this new setup as a developer (both backend and frontend).

Please let me know in the comments if there is anything you specifically would like to hear more about.

And do reach out on mlj@sitecore.net if you want to learn more about XM Cloud or any other Sitecore products 😀

 

View a Sitecore license file in a browser

Previously, I used to review a Sitecore license file (if needed 😏) in Internet explorer by just opening the local XML license file directly in IE, and the license information would show in a nice formatted way, and not just the raw XML, you get if you open the file in an editor.

That stopped working at some point, where the browser would just show unformatted text. I never really took the time to investigate, but today I found the reason!

While Sitecore has changed their web presence from .net to .com, they forgot to update the xsl stylesheet reference in the generated license files!

If you open the license file, you will see this line: http://www.sitecore.net/licenseviewer/license.xsl

Change that to https://www.sitecore.com/licenseviewer/license.xsl, and open the licence file in i.e. Edge, and you will have a much more readable license file 😉

Certificate for local dev, demos, etc.

Recently, I played around with the Habitat Home demo, from Sitecore that has replaced the good old legal demo. It can be found here by the way: https://github.com/Sitecore/Sitecore.HabitatHome.Platform.

It requires a blank Sitecore 9.1 with SXA installed. How to install that, is covered in so many blogs, so I don't want to repeat that ;).

It also requires running the site in https mode. No problem, you can just add a self signed certificate in IIS, and use that. But it has always annoyed me that the browser of course do not trust this certificate, and especially in demo scenarios, it is not cool with the "Untrusted connection" shown in the browser.

So creating a locally trusted certificate that you can use for all your local sites is a better way forward in my opinion. And instead of trawling the interweb for a guide, let me just share it here with you ;):

(This way I also have my own guide when I have forgotten the process next time I need to do it!).

Create a certificate

Easiest way I found was to run a Powershell command in Powershell ICE.

1. Open Powershell ICE in admin mode!

2. Run the following command: New-SelfSignedCertificate -DnsName *.dev.local, localhost -CertStoreLocation cert:\LocalMachine\My

Change "*.dev.local, local" to whatever makes sense for your environment. your sites bindings needs to match the domains. the * in front of dev.local means that you can use this certificate for any sites that has a url/binding that ends with dev.local, i.e. https://habitathome.dev.local/ and https://test.dev.local/

Now export the certificate

1. Open mmc.exe

2. If you have not manually messed around with certificates on your PC before, you need to add "certificates" in mmc

2.1. In mmc, click "File" -> "Add/Remove Snap-in.."

2.2. Click on "certificates" and ""Add" and choose "Computer account" -> "Local computer". Then click OK

3. Expand "Certificates (Local Computer)", "Personal", "Certificates"

4. Right click on the certificate you have created (if you used the exact command from above, it will be "*.dev.local") and choose "All tasks" -> "Export.." And follow the export wizard:

4.1. In the export wizard, choose "Yes, export the private key"

4.2. In the next screen choose "Personal Information Exchange" so the certificate will have the .pfx extension. (I do not know if this is important, but it works ;)). Leave all the check boxes as-is.

4.3. check the "Password" checkbox and give it a password you remember (obviously). The encryption does not matter (I think), so I chose the first option 

4.4. Give the exported certificate a name and choose location

4.5. Finish the wizard and you should now have a .pfx file in the chosen location

Import certificate to the trusted root store

1. Still in mmc go to "Console Root" -> "Certificates" -> "Trusted Root Certification Authorities" and right click on "Certificates"

2. Choose "All tasks" -> "Import"

3. Browse for the just created .pfx certificate and follow the guide for importing the certificate, leaving all default choices as-is

That is it! now you can use your newly created, locally trusted, certificate in IIS when setting up https bindings.

remember the binding needs to match the domain you used when creating the certificate. in my case that would be something.dev.local.

 
BIG DISCLAIMER:
I do not know much about certificates, so if any of the above is stupid, does not make sense, or should be done differently, do write a comment about it!

//If you find this post informational/misleading/educational/whatever, please provide a comment.

//Also it would be nice with just a HI, so I know real people are actually seeing my posts ;)

Blank Sitecore with MVC renderings instead of Webforms

Sitecore has now supported and promoted the use of MVC as the rendering mechanism over Webforms for more than 3 years (probably a lot longer).

I think everyone agrees, that this is a good thing, although I loved creating sites using XSLT back in the days ;) (I might be very alone with this statement though?)

BUT why is the sample layout and renderings, which are part of a blank installation, still using Webforms??

Probably because it is not a big deal and those samples should not be used anyway. But I often use a blank site for a small test or to prove something to a customer/fellow partner or colleague. And it is annoying, that I need to create a new layout to be able to show the new Sitecore Forms in the workings for example.

So I recreated the sample renderings in MVC (only view renderings, so no compilation is needed) and you can download the package here so you don't have to do the same ;)

Download package

//If you find this post informational/misleading/educational/whatever, please provide a comment.

//Also it would be nice with just a HI, so I know real people are actually seeing my posts ;)

My blog moved back ;)

After many years, my blog has now moved back to this platform!

My (limited) contribution since moving the blog to sitecore.net can still be found here: https://community.sitecore.net/technical_blogs/b/sitecore_what39s_new, although the newest is from 2015, so probably a bit out of date.

I will start blogging about Sitecore again here (especially targeted at the not-so-experienced and new-to-the-platform audience), and first up, is about my new mantra and start of a movement #SimplifySitecoreDevelopment.

For a long while now, I have seen Sitecore solutions becoming over-engineered (in my opinion), resulting in a steep learning curve especially for new team members and developers new to Sitecore.

Also, unnecessary time is spent on developing the "perfect" code that (in theory) is easy to extend and adjust over time. What I have experienced is, that the time saved in the long term, rarely justifies the time spent building that perfect dependency-injection enabled, MVVM, service layered, etc. component as the requirement often change so much over time, that the component needs to be completely rebuild anyway. Or even more so the case, the platform is changed to another platform or upgraded to a newer version, where the whole site is redesigned and re-coded anyway! 

Sitecore is an advanced platform, allowing any imaginable customization and you have probably heard the sentence "what you can do in .Net, you can do in Sitecore" many times if you move around the Sitecore community circles! That does not mean it is a complex platform for developers, unless they make it their mission to make it complicated!

And just to make sure I don't get everyone on my neck already, #SimplifySitecoreDevelopment does not mean abandoning the great intentions in the Helix guidelines (https://helix.sitecore.net/). On the contrary, I will make sure to follow those guidelines in the coming blog posts.

Mark Cassidy @cassidydotdk delivered a great talk on this years Sitecore Symposium (a blog post about that event is also in the making ;) on the same topic, so I am not alone in my little movement ;)

First up is a rant about ORM/strongly typed field access vs native Sitecore API:

1. Why not use the Sitecore native API (not online yet)

My blog has moved

This will be my last blog post on this adress as my blog has moved to the new Community area on Sitecore.net: http://www.sitecore.net/en/Community

You will find my blog on this url: http://www.sitecore.net/en/Community/Technical-Blogs/Morten-Ljungberg-Sitecore-Whats-New.aspx

I will be porting all my previous posts too.