A question for the community: Development patterns

A bit of a change of tack this week. Rather than writing about something I’ve been doing, I’d like to ask for your ideas on something I’ve been thinking about. This issue is way to complex to compress into a tweet to ask on Twitter, and it seems too opinion based to be asked on Stack Overflow. So I’ll ask it here, in the hope that some of you clever people might offer your opinions. Comment below, tweet me, write blog posts in response, send carrier pigeons or whatever. All thoughts appreciated…

So here’s what I’m thinking about: How do you set up your projects for development?

Hey reader!
After many years, I’ve finally decided to start moving off WordPress and onto a blog I host myself. This post is now available at “https://blog.jermdavis.dev/posts/2014/a-question-for-the-community-development-patterns“. Eventually this version will be retired so please update links on any sites you control, to avoid 404s in the future.

For all the time I’ve been working with Sitecore I’ve followed roughly the same pattern:

  • Install a development instance of Sitecore and configure it. Usually via the .exe installer or SIM.
  • In a separate location, create a Visual Studio solution with a web project, plus optional TDS and class library projects.
  • Add project references and dependencies via NuGet.
  • Configure the VS build process to copy the output of the solution into Sitecore’s website folder. Either via MSBuild commands, Visual Studio Publish Wizard or Hedgehog TDS.

The Sitecore databases go into a local instance of SQL Server, and when I need the .Net debugger I attach to the IIS process using the shortcut in Sitecore Rocks.

And then I’ll sit and write code, hit build and test until my project is working.

But the other day a colleague of mine made an alternative suggestion to this approach that was different enough to make me stop and think. He’s experimenting with Sitecore itself as a NuGet package, and used a different approach to setup and the development process:

  • Create a Visual Studio solution with an empty web project and appropriate TDS and class library projects.
  • Use NuGet to add Sitecore itself into the web project folder.
  • Use NuGet to install other references.

And then develop away, without the need for a post-build step to deploy your work. You can hit F5 to compile and debug against IIS Express. And the databases can be attached to LocalDB using the AttachDBFilename style of connection string. All of which means theoretically your entire development setup for a new team member on a project could be “get-latest” from source control. Or alternatively development instances of Sitecore can be copied about between machines and developers via XCopy.

(There’s a background issue here that I don’t think Sitecore officially supports IIS Express and LocalDB – but as far as I can see, it does seem to work)

Now historically I’ve been on the “never put your VS Solution into your Sitecore website folder” side of the development process debate. I argued this when I first did Sitecore training many years back (when their trainer was teaching the other way) and I’ve stuck with this position. It seemed to have numerous benefits to me:

  • Your web project folder (and hence source control) contains only the stuff you’ve changed. Hence it’s smaller, and eaiser to see what has been modified and needs deploying.
  • You can safely run things like “clean solution” without worrying that VS will delete un-referenced or “don’t copy local” DLLs files from Sitecore itself.
  • Your development process matches you QA process – if you forget to copy stuff out of the solution in development you spot the issue before you get to the “forgetting to package it for QA” stage.

But at the same time, I can see that there are disadvantages to my approach too:

  • It takes longer to set up, as there are more things to do. While you can automate setup, it can’t work with just a simple “get latest” from source control
  • The “copy after build” operation has a habit of unloading your Sitecore app when you’ve only changed text files. And you have to remember to do the build/deploy step even if you didn’t change code files. All those “waiting for IIS to start Sitecore up again” pauses in development mount up over the course of a project.
  • You can’t just hit “play” to debug. You have to attach the debugger to the external IIS process – either via Sitecore Rocks or manually picking the appropriate process

All this has got me thinking. So I’m spending a bit of time considering the implications of all this, and how it might be sensible to adjust my ideas about development processes.

But what do you think Sitecore Community? Where do you all stand on the “right” way to set up a Sitecore development instance? What do you think are the best ways to achieve this setup? Do you have advice would you offer? Any favourite blog posts on the subject of “best ways” to set up your projects?

I’m all ears…

8 thoughts on “A question for the community: Development patterns

  1. Jeremy, interesting question. Wouldn’t it be nice to open Sitecore Instance Manager. Install Sitecore. Choose you version of Visual Studio project. Then fire up NuGet and add the packages you need. Be good if the correct version of MVC etc. is already added based on the version of Sitecore you’ve started with. Are we that far away from that?

    • You mean integrating NuGet for general packages (like ASP.Net stuff) into SIM? That’s another interesting potential approach – kind of the reverse of what I’ve been thinking about over the last few days? In terms of possibility, I’d have to say I’m not sure. I’ve used NuGet to add extra things to a pre-existing website project, but I’ve never considered it for creating the overall project in the first place. I shall add that to my list of things to think about. Interesting idea!

  2. I am on to installing Sitecore using nuget-packages. I have created some scripts that can take the Sitecore zipfile of a version and create a nuger-packet out of it.
    Some custom scripts handles the content of the Sitecore website so we prevent the need of comitting Sitecore stuff.
    I am planning to write a blog about soon. I will post a link here when it has bern written.

  3. Rather late to this one, but I’m still heavily in the first camp (understandable considering our common background ;)) – Sitecore shouldn’t really be in the solution. We also had a bit of a debate about it during the 7 upgrade training – the key arguments for were mostly as you laid out, along with the argument of “you aren’t including the NuGet packages in source control – they aren’t your code”

    In terms of “Time to start developing”, I wouldn’t say it’s all that much longer – having bashed through it on a few projects recently, I’d say it took me about an hour to go from “Clean Developer Machine Install” (Windows, VS, IIS correctly configured) to a running instance of a Sitecore site, integrated with TDS deployments, etc. and on top of that, if the developer does it themselves/with you they should have a better understanding of what’s going on.

    That said, I fully agree that the “having to deploy to see your changes” is a pain – this was more of an issue for our Front End devs – we had quite a nice (I think) solution for that, where they worked out of the local IIS project so they could just update the code, build, and then get out of VS as quick as possible and into Sublime – I should probably write that one up on my blog…

    Personally I’ve found that the pain of attaching a debugger is usually outweighed by the fact that you are going through a deployment process and so can ensure that you haven’t forgotten to add something to the solution.

    In fact, the biggest pain point we had was someone creating a “shared source” project that started with the word “Sitecore” and then wondering why TDS didn’t deploy it…

    • Thanks for the input Ben. I’ve made the “Sitecore in the namespace” mistake myself in the past – one of those “thank goodness for global namespaces” moments…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.