Sitecore is a powerful CMS. No doubt about it. The amount of features packed in this one package is definitely impressive.

Its one downside seems to be documentation. That is the biggest complaint I've heard from most sources. Particularly in the area of deployment and configuration for Production environments.

Now, it's not that the documentation is not there – it does exist. But that it is hard to read and hard to follow and often spread about piece here, piece there – and it can be a steep gradient for a novice to grasp what to do right from the get go.

This article summarizes my own experience with the product and what I perceive as a best practices model, for most scenarios, based on both Sitecore's and ASP.Net's own guides and advice. I hope to guide the reader to navigate these treacherous waters and hopefully come out the other end, still alive and sane.

This first part will not delve into the technical details, but start with an Architectural overview of the solution. Implementation details will follow in a subsequent article.

While the approach I am proposing is not applicable for all situations out there, it may provide you a good starting point with which to adapt your own individual needs into a model that works for you.

There are several factors we are trying to balance. Security, performance, usability, user-friendliness…

And several audiences we are trying to please – system administrators, programmers, content editors, content administrators…

Programmers are a case apart and we will not focus on them on this article. We are primarily focused on setting up a Sitecore installation such that Internet users can access the company's website content, and content editors and administrators can work the back-end without it interfering with the user experience. All without compromising the system administrators well-justified need to maintain a secure system that is as hard as possible to be compromised by the malicious hacker or virus out there.

As such, we start off with the basic time-tested principles.

We have a "Production" web server (or server farm) out on the DMZ, with one Firewall to protect it from the Internet and another to keep it away from the Intranet. We open basic ports on the Intranet firewall – the SQL port to access the database, maybe an FTP port to transfer files to the box, STMP if it needs to send mail.

Then inside the Intranet we have everything else: the Production Database Server and the Staging Web and Database Servers.

Keeping Staging and Production environments separate minimizes risk and optimizes performance. While you can go on the cheap and keep the Production and Staging database servers on one box, it still helps to keep them logically separate, using different credentials, so that a hacker compromising the production data will not cause your Staging data from being compromised as well. Since the push is from Staging to Production, any malicious or accidental defacement is easily erased via a Sitecore Publish operation. Let's take a look at how that looks like so far.

The Production database server will contain the Production content database, the Analytics database (if you have a license for the OMS module), the Web Forms for Marketers database and a Security database (which is an extract of the Sitecore Core database – see "Configuring Production Environments" manual from Sitecore for details on that.)

As per Sitecore's best practices recommendation, the Production Web Server should not have a Sitecore back-end CMS admin shell in operation. The "Configuring Production Environments" manual also shows how to deactivate that.

The Staging Web Server then becomes the vehicle whereby the Production Sitecore content gets updated. The Content Administrators "Publish" the content to the Production database. More on this later.

Before we go there, let's discuss what's on the Staging database server. It contains the Sitecore Core database, the Master database and a Staging Content database (web). The Core and the Master are the main databases you want to protect. The Security database is another, but that one unfortunately MUST live on the Production web server – or none of your visitors would be able to log in – if you have no part of your website that is "private" (if all content is anonymous access only) then this is not an issue.

So the Staging web server, which contains both the Sitecore CMS admin shell and the Staging web content (you can separate this into two servers, but for the most part there is no need) must have access to both the Staging and Production database servers. From the Production database server it needs access to the WebForms and Analytics databases – if you have those modules – but most importantly it needs access to the Security database – so all your content editors and administrators can log in.

Now, what you call these databases is your own business – Sitecore really does not care, so long as your connection strings look good. But I find it helpful to label them with suffixes _STG and _PRD to keep the staging side easily identifiable and separated from the production side. So my production content would be Sitecore_Web_PRD and my staging content would be Sitecore_Web_STG, for example. Databases that are either shared or only exist on one side, need not have this distinction.

So, now that we have the concept, what are the specifics for setting up this type of environment?

It's mostly configuration magic. We look in the web.config and connectionstrings.config files in the Sitecore installation to set this all up.

But that, to quote Conan the Barbarian, is another story…