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?

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

↑ Back to top