Sitecore 7.5 and MongoDB through different environments

Jan Löwgren, another Sitecore Consultant, in response to my post “Sitecore Environments for Dev, QA, UAT and Production” said It would be interesting to elaborate on how to handle MongoDB though different environments. In the project I am currently working the team was about to upgrade from Sitecore 7.2 to 7.5, so the opportunity to engage into a MongoDB experience was the excuse I wanted to volunteer myself to the upgrade task.

Trusting your instincts

My first thought before getting my hands on the issue was trying to handle mongo databases as we do with Sql server dbs: each Developer would need to install a MongoDB server at their machines.

Setup before Sitecore 7.5

For the context of the project, our environment’s setup was pretty similar to what is described in my first article:

  1. Developers and front-end devs works at their local machines, with local copies of solution and databases – everyone has their set of “master”, “core” and “web” databases. TDS is used to syncronize Sitecore data with the team;
  2. We have an integration server Sitecore instance, periodically updated by TeamCity on every build change;
  3. We also have a QA Sitecore instance, updated by the trigger of the QA team;
  4. The last instance is the UAT server, also updated by TeamCity by the trigger of someone with this privilege (usually the Project Owner by request of the client);


The final setup ended up being pretty similar to my first thought. It makes sense if you think that MongoDB is not much different than a normal Database Server. At Sitecore 7.5 MongoDB serves DMS Analytics and access data, so we can safely have separated databases for each Sitecore instance (Dev, CI, QA and UAT).

MongoDB Installation

Since every developer needs a separated MongoDB server, everyone needs to install at their own machines and access using their “localhost”. This very easy operation can be made by following the steps of this article (Sitecore and xDB – Setting up MongoDB on your developer machine).

Here is where the developer’s ConnectionStrings will end up:

<add name=”analytics” connectionString=”mongodb://localhost/dotz_analytics” />
<add name=”” connectionString=”mongodb://localhost/dotz_tracking_live” />
<add name=”tracking.history” connectionString=”mongodb://localhost/dotz_tracking_history” />

MongoDB server initializing

MongoDB is not a service you can install on Windows – you must run it manually – so it’s recommended to have a batch pinned up at your Windows start button before you launch your development instance.

Windows Start Menu with a link to the batch that starts MongoDB

Your batch can simply contain the following:

“C:\Program Files\MongoDB\Server\3.0\bin\mongod.exe” –dbpath “D:\MongoDB”

  • First path depends on where your MongoDB is installed
  • Second path is where MongoDB creates the files to manage databases

What about the CI, QA and UAT servers?

At the Continuous Integration servers the installation is pretty much the same, the only difference at our case is that we opted to have a centralized MongoDB server, with separated sets of databases for each Sitecore instance (CI, QA and UAT).

Posted in Continuous Integration, Environments, TDS, Team City

Leave a Reply

Your email address will not be published. Required fields are marked *


  Am Not Spammer

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>