Benefits of Setting up Sitecore Developer Box Loosely-coupled

Hi Friends,

In the previous post we saw how to setup a Developer instance in less than 5 minutes. In case you missed it, do have a look at it here.

Traditionally, in Sitecore setups, we used to have a tightly-coupled webproject-sitecore instance relationship, wherein the Project and Sitecore instance used to exist in the same folder — with Sitecore folder inside the website folder.

But, when loosely coupled, it helps us get various benefits, but 4 main which are worth discussing:

• Multiple website projects can point to the same Sitecore Instance.

Suppose, we have a multi-site instance, with a few websites on it, a main website, an intranet site a blog and a few country websites. If tightly-coupled, all of this would obviously be under the same webproject. But, in loosely-coupled architecture, all of these can exist as different webprojects altogether, if the need be. Also, if we have a new website to be added, we can create a new webproject instead of adding complexity to the existing projects. In this way, not only our code can remain decoupled, but we can also take advantage of multiple development projects running in parallel at the same time quite easily. And yes you are right, if one of the webproject has a build failure or some issue due to which it is down, it does not affect other webprojects or the Sitecore instance on the whole. Useful right?

Oh you want to know how can we do it? Simply create a publish profile, in each project that points to the Sitecore Solution URL as we saw in the previous post

• No change in debugging a Web project

Debugging the Web project/s remains the same whether we use a tightly-coupled architecture or a looseely-coupled architecture. Yes, you are right, we first make the Sitecore instance up and running, and then attach the Visual Studio Web Project to the W3WP process and start debugging.

•  Sitecore Upgrades become easy

Whenever we want to upgrade a currently running Sitecore instance, lets see how easy it is. We already discussed above, that in a loosely-coupled architecture, its good to create a new website for each webproject. So going by that, we would already have a Home item, which was added during installation of the Sitecore instance. So we would use the URL that we used to setup the Sitecore Instance instead of any webproject specific URL and upgrade the Sitecore instance.

Once the Sitecore upgrade is successful, we have two steps to perform for each of the webprojects we have configured for a given Sitecore Instance.

1. Replace the Sitecore specific DLLs in the Libraries folder of each of the Web Project
2. Rebuild the project.

The best thing here is, if say we have used a method/function in a project which has deprecated or discontinued, we can make changes only to that without affecting other projects.

• Easy to debug and solve in case of an issue

Lets consider 3 cases here:

1. The Sitecore Instance is down

So we have some configuration changes to our Sitecore instance, its unable to startup and do not remember what they were?

Do not waste time in finding and reverting them. Simply, Install a new Sitecore Instance(with the required version) and create a new Publish profile, pointing to this instance. We can also uninstall the currently failing Sitecore Instance and install the new one with the same name, to avoid creating a new Publish Profile.

Oh yes, good question, what about the items that we created?

Two options: Either we use the same Databases, or use TDS (Team Development for Sitecore) to sync our items between Sitecore and our SVN Repository, get them out from there and sync them to the new instance.

2. The WebProject is down

If say, one out of five webprojects is giving an error on accessing we can identify that its an issue with that particular Webproject. Ideally, Visual Studio would give us the necessary information if the build fails for the project.
If build succeeds but still the Sitecore instance is not up with that URL, then there might be some config change which might be conflicting. To get details about the error, lets make sure that we enable Debug mode in Web.Config of the Sitecore instance (to get detailed error) and put the latest .pdb file of the webproject (i.e. click publish again, and it along with other files would be available) into the Sitecore instance bin folder and start debugging.

3. We don’t know where the issue is – Sitecore Instance or Webproject.

This is a bit tricky, but we can find a solution with minimal efforts. If say, you have five websites configured in a given Sitecore Instance, then we would try out all the URLs for our local Sitecore Instance of these 5 websites.

If none of them works, that probably means, that our Sitecore Instance is down. So, lets follow case 1 and check again.
If atleast one of them works, means for all those projects the URL gives error, has an issue and we need to check building them again, or their configuration to find out the issue.

What? You came across yet another benefit that’s worth mentioning here? Well, please do that in comments, I will add that here mentioning you.

Happy Sitecoring! 🙂