Sitecore, Hedgehog TDS, TeamCity and NuGet == true

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?

9 thoughts on “Sitecore, Hedgehog TDS, TeamCity and NuGet == true

  1. When running a search you will see a dropdown that is shown from the textbox where you enter your text. If you would like to add your own, firstly you will need to implement this interface. Secondly, you will need to add an item into the content tree (/sitecore/system/Modules/Item Buckets/Settings/Search Box Dropdown) to register this class so that it will show up in the drop down menu.

  2. 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.

  3. This was a little overdue; my Sitecore code generation module, CompiledDomainModel, has been used in many projects and the code has matured enough to justify a 1.0.0.0 version number. A very important addition was made in this release.

  4. It requires effort to put Sitecore modules into NuGet packages, but there is already demand for these . My hope is that Sitecore NuGet packages will ease the lives of developers who must install, update, and manage Sitecore modules in any given Sitecore project.

  5. It requires effort to put Sitecore modules into NuGet packages, but there is already demand for these . My hope is that Sitecore NuGet packages will ease the lives of developers who must install, update, and manage Sitecore modules in any given Sitecore project.

  6. Source Web Project – Here you can set the web project of the solution. We chose <none> because after setting it, we found that TDS will copy your web source project to your build directory. This was bad for us, as we had MSBuild doing that, and a lot of other custom things for us already. We found that with it set, our changes were overwritten. Maybe this setting is best set up for a new project, instead of an old one which you’re adding TDS into.

  7. This will be a project to store environment specific setting and we will be using TDS to deploy these setting to any environment we want. Even though we’re not going to use TDS to deploy to production environment, we might want to keep production configurations in the source control so that at least we have a copy of production configurations in case we need them.

Comments are closed.