When writing code for Sitecore, this code should someday be deployed to an existing Sitecore environment. Preferably, this should happen “the first time right”. One of our guidelines to achieve this is: Don’t overwrite Sitecore files. Don’t update existing files of other packages. Don’t upgrade assembly versions. Don’t break your site. It might cause a lot of trouble without knowing where to look. When we were still working with SharePoint, there was an internal mechanism to create and remove deployment packages. Developers had to do their best to overwrite out of the box files, as packaging mechanisms were introduced which explicitly required to select the files that you wanted to deploy. I was (and I am) wondered that Sitecore doesn’t offer this feature (well, not as I expected it), and thus I decided to write a blogpost on what shortcomings we see, how to solve them and how to verify that things will good right.
Source code for the Sitecore Validate Webdeploy packages is provided on github.
At Achmea, we made the strategic decision to use Sitecore as platform for all of our websites, we’ve got hundreds of them. To do this at enterprise level, on such a scale, it’s important that we have guidance on infrastructure, development, deployment, security, content, DMS, just to be sure that the stable environment that we deliver, will stay stable. We all know that it’s important to work with the right Sitecore assemblies (correct version) and not to overwrite them. But Sitecore doesn’t only deliver Sitecore assemblies, but 3rd party assemblies as well, for example: Microsoft assemblies, TweetSharp, Facebook API, Google API’s, et cetera. This blogpost tells us what 3rd party components Sitecore ships with, what license is tied to it and what version is delivered. It currently only includes Sitecore 8.0 update 5 and Sitecore 8.1 update 1.
And please try to guess the answer to now: “What is the year of the eldest component that ships with Sitecore?”. You will be surprised 😉