I’ve been looking some time for a more streamlined development process when building Sitecore modules and share code between Sitecore projects. Separating code into modules is easy, but when you have dependencies on Sitecore items, things becomes a bit more complicated.
The package installation wizard in Sitecore is helpful, and it get’s better with update packages generated by Hedgehog TDS. But I think we can do better. With multiple developers, multiple installations (dev, test, QA, live environments etc), the update process becomes too time consuming and painful.
In addition, I want to be able to create generic modules that can be shared between different Sitecore projects, so I want the code to be built and tested on our build servers and deployed to our local NuGet server.
I’ve done a prototype of this, and I think it worked out quite nice, though there is still a lot of room for improvements.
When developing a module (or a group of modules is fine too), I start from a clean Sitecore installation and create my Visual Studio solution and project files as usual. I add a web project for testing etc. This project will also contain my module’s configuration files etc. The module is of course in one or multiple class library projects.
Then I add a TDS project and add everything to source control, so now everything is under control in my module development project. So far nothing fancy – just a regular setup. Now, let’s bring everything together.
I’ve created a simple console application (that’s packed as a NuGet app as well) that I run as a pre-build event of my module. It’ll take the .item-files from the TDS project and bundle them into a resource file stored in my project. That resource file is marked as an embedded resource. If I have multiple TDS projects (like master and core), I’ll embed multiple resource files.
Having the items as embedded resources, I can use WebActivator to automatically startup an install process. With the help from some utility classes, I can specify what items I want to install into a Sitecore instance, what items should be added if missing (but not touched if they are already there) etc, or run any other custom code to modify my setup as needed.
Using TeamCity, I have a build process that will compile all the code, run all the unit tests and, on success, pack the modules into NuGet files and publish them to our local NuGet server.
Now we can add those modules as any other module, using the NuGet package manager, and all developers in the team, all test, QA servers etc will have the latest version (or the version specified in packages.confg) automatically installed to their Sitecore environment. Since the Sitecore items are bundled as resources into the module DLL, they’ll get installed into Sitecore on application start. Isn’t that cool?
Auto-installing modules like this in a live environment could of course be a bit dangerous, so I have a setting to disable this.
In my prototype I also have to carry two .sln files since our build servers in our TeamCity farm didn’t want to open solution files with TDS projects. So the second .sln file is the same but the TDS project(s) are removed. A little pre-processing of the original .sln file on the build server could probably solve that as well.
As I mentioned, my code is still very much a prototype, but I hope I can publish the utility classes and the resource bundling application soon.
How do you streamline your development & building process?