I've been spending some of my Holiday vacation working on upgrading Sitecore Foundation to work with Sitecore 9. While it builds and deploys properly with the gulp script, I have not fully tested everything. That being said, you can find the Sitecore 9 version of the framework in the new "Sitecore9" branch of Sitecore Foundation on Github. Once things are nice and stable, I plan to move this to the master branch and keep a Sitecore 8.2 branch for whoever needs it.
So as this was my first real shake at upgrading a solution to Sitecore 9, I'd thought I'd share some of my experiences.
Installation was Tricky
Installing Sitecore 9 was way more painful than I expected. There are a lot of blog posts, tools, Powershell scripts https://gist.github.com/jermdavis/8d8a79f680505f1074153f02f70b9105 and work arounds (ended up needing to edit my registry, yuck!), and I still have trouble running SOLR as a windows service, but I did end up getting it working on my local machine.
As a lead/architect on many projects, definitely want to spend time streamlining and documenting the setup, and even creating a few VM's to avoid having folks spend too many cycles just on a clean build. At least until SIM supports Sitecore 9 installs.
A couple notes on the install:
The Directory Structure has changed: Gone is the split Data and Website directories. The Data Folder now exists under App_Data in the Web Root. I'm not sure how I feel about that yet, as I liked having the separate paths. As Foundation followed the Habitat Approach of putting the instance in the "C:\Websites\" folder, I updated the base config files to "C:\Websites\Sitecore\sf9.dev.local" to follow a similar but not same pattern.
The "Websites \ Sitecore" path may be a bit redundant, but it was easy to update in the "Site.PhysicalPath" parameter in the sitecore-XP0 config file. For the xConnect service you can do the same, but as we don't currently deploy anything to the xconnect service, I left it in the default location. Thinking to eventually try to standardize on c:\Websites\ProjectName\Website for Sitecore and c:\WebSites\ProjectName\Xconnect for xConnect, but will probably wait until the install process is a little cleaner, or I spend time making it so.
The Upgrade Process
Here is a basic list of the drudgery that is involved in the upgrade:
- Git Branching Setup
Was pretty easy to do, my main branch is actually in a private TFS Online and I push to github which is configured a remote. Was afraid this would be complex since I wanted to make sure the Sitecore 9 branch was created in both places, but it worked easily. - Updating to .Net 4.7
Before I could even start this, I needed to actually install it. I also used this as an excuse to get Visual Studio 2017 running. One of the pains with Helix, was it's pretty tedious to change each project to target the proper version of .Net, but it needs to get done. - Updating Nuget
This wasn't terribly hard either, as by managing nuget at the Solution level, it was easy to upgrade all the Sitecore 8.2 references to Sitecore 9. This also made it clear where I had dependencies on dll's that didn't have a 9 equivalent (more on that in the issues section). I did need to ensure that all references to the Microsoft Dependency Injection was pointed to 1.0 and that Newtonson references were to 9.0.0.0, but only ironed that out trying to get my local build to work. I also took the additional step to ensure these updated references were not set to copy local as I try to avoid overwriting Sitecore dll's as part of the build. - Updating Gulp Config
Once I got the solution building in Visual Studio, I jumped to run the gulp script, which immediately failed. Now that we're in Visual Studio 2017, I needed to update the gulp-config.js to set buildToolsVersion to 15 (just like the habitat comment said to do). Besides that, I needed to update the rest of the config paths to deal with the new website deployment location.
Upgrade Issues
Like any upgrade, not everything went smoothly. The biggest headache, was due to the large number of changes in the data exchange framework. While everything now compiles against the new versions, and the tenant is partially there, I still have a lot of work basically rebuilding the tenants to test out the pipeline steps. I also plan on spending time trying to take advantage of some of the newer features of DEF, but that may take even more time to work through. Here's some notes on that process, which probably warrants it's own blog post once everything is working properly again.
- The Pipeline Interface Changed. Some of the method names changed, and many of the method signatures were modified to pass the logger instance around.
- The Plugin Methods were changed. Instead of Plugins.Add, it was changed to a Generic AddPlugin<Type> method.
Part of moving things over, I ended up having to rewrite a few steps, and ended up removing the async iterator and Language Steps, as the OOB framework supports those scenarios better than I did.
Two areas of code that needed to change were where we manually enrolled contacts in engagement plans. The Analytics.Automation assembly was actually no longer part of Sitecore 9.0, but luckily I found some decent documentation of the enrollment Request which actually makes a web request to the xConnect service to enroll the contact.
The other place that changed was code that identified a contact based on their unique identifier. The old Session Identify method was depreciated, replaced with a similar method "Identify" as which also required a source parameter. I updated it to use the current Site Name:
Sitecore.Analytics.Tracker.Current.Session.IdentifyAs(Sitecore.Context.Site.Name, domainUser);
Lastly, I removed the custom implementation of dynamic placeholders, which was pretty easy since the HtmlHelper syntax for the OOB Sitecore 9.0 Dynamic Placeholder was the same as my previous implementation.
Dynamic Placeholder Issues
Once I got my build going and the gulp script working, I was able to log into Sitecore, see all the content was imported properly and was starting to get happy until I tried bringing up the site in chrome. I was greeted with empty pages. Turns out the new Sitecore 9.0 Dynamic Placeholder implementation has a completely different placeholder key format.
Lucky for me I found a post about the same issue encountered for Fortis, and with a few adjustments to the powershell scripts was able to update all the content items to get the page content to show again. I even updated my friendly layout details feature to work with the new format, so you can easily see the paths to where all the components are in presentation details.
Sitecore Foundation is working with Sitecore 9, though I have a bit more testing and commits to do before I replace the master branch. You can get the latest bits on github, by cloning the Sitecore 9 branch.