This post 3 of 3 in a series titled Using NuGet for Sitecore dev instances
- Using NuGet for Sitecore dev instances: Background and beginnings
- Using NuGet for Sitecore dev instances: Further files
- Using NuGet for Sitecore dev instances: Uses and conclusions
In my last two posts [first part, second part] I've outlined the results of some research into an approach for how you can package Sitecore with NuGet. I presented this at a recent Sitecore Technical User Group, and am documenting it here with a bit of detail that didn't fit into the presentation. This week I'll finish off the set of posts with a few conclusions from this experiment.
Once Sitecore is packaged up as described, it's easy to use. You need to point Visual Studio at your private package feed. That can be done via the
Tools / NuGet Package Manager / Package Manager Settings
menu option. Then fire up a new "ASP.Net Web Application" project. Then just add your NuGet package for Sitecore to the project. Visual Studio will churn away for a while while it downloads and un-zips the files:
When it's finished, you can click "play" to run your project, and Visual Studio will fire up Sitecore for you, ready for whatever development you need to do.
The key benefit of this approach is that a developer can add Sitecore to a project without any need to understand how to install Sitecore. And they can't get the install wrong as it has no manual steps. It's possible to pre-configure the instance of Sitecore to include project-specific configuration as well, so a developer can get stuck into project work without any need to install other Sitecore packages or apply project-specific content or config.
It also makes the "upgrade Sitecore Version" scenario pretty easy in your projects. You can use the NuGet package window to remove the current version of Sitecore, tidy up any left-over files, and then install a package of the new version. From a developer's perspective, very simple. And the process can probably be made simpler with a bit more scripting – NuGet allows an "uninstall" script to be run when it takes a package away from a project, so tidying up left-over files could be automated in the same way that the installation is.
The approach seems to work very well for disposable prototyping instances. You can create a project, add Sitecore, write some code and config, test whether it works well or not, and then dispose of the instance just by deleting the solution. No need to detach databases, or tidy up IIS settings etc.
There are a few challenges with this approach:
So, swings and roundabouts...
This has been an interesting experiment, and I think there are some good use cases for this approach. Hat tip to Simon Lewis for raising the suggestion in the first place. But having worked through the experiments and done some testing, it's not something I plan to use for most of my day-to-day development. My guess at this point is that the setup automation for my future projects will be done through "Config as Code" tools such as PowerShell DSC or Chef – mainly due to their ability to be used for development, QA, and production instances.
However, just because it doesn't mesh with most of my plans doesn't mean it can't suit yours. If you've looked at this and thought that it might fit with your approach for development, then you may be interested in looking at other developers' approaches to the same concept. If so, check out the work that Andy Davies was doing around the same time as this which is available on GitHub.