This is post 3 in an ongoing series titled
Using NuGet for Sitecore dev instances
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.
How might you use a package?
url copied!
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.
So what's good about this approach?
url copied!
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.
And what's not so good?
url copied!
There are a few challenges with this approach:
-
Time:
While you don't need any specific skills or knowledge to install Sitecore via this route, you do need some patience. On the VM-on-a-laptop I was testing on it would take about 6 minutes to install the package. While that's a bit of a wait, it doesn't need interaction, so you can wander off and do something useful while you wait.
Also you need to factor in the time required for packaging itself. I think there are some good opportunities to add automation to that process as well – but it still requires time each time you need to create or update a package.
-
Disk space:
Downloading and installing a package like this does end up occupying quite a bit of disk space. NuGet is downloading a copy to the package cache, a copy to the "packages" folder in your solution, and then the files end up in your project directory too. The packages weigh in at about 150MB so that's quite a lot of disk space in total. Admittedly disk space is pretty cheap these days, but this may be an issue to some people.
-
Security:
One of the side-effects of installing and running Sitecore via this route is that you're pretty much ignoring any disk and SQL permissions. Everything's running as "you" when you click play, and you'll have rights to everything. For most development scenarios this isn't much of an issue, but if you were building code which relies on specific permissions this is probably not a good development route.
-
Supportability:
The biggest issue to my mind is that of the supportability of the Sitecore instance you've created. As far as I know Sitecore don't test against LocalDB and IIS Express, so it's quite possible that there are bits of the software which won't work when set up like this.
So, swings and roundabouts...
In conclusion
url copied!
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.
↑ Back to top
