Proper DTAP setup for Content Delivery

8
votes

I've had this setup, but it didn't seem quite right.

How would you improve Content Delivery (CD) development across multiple .NET (customer) development teams?

CMS Server -> Presentation Server Environments

  • CMS Production -> Live and Preview websites
  • CMS Combined Test + Acceptance (internally called "Staging") -> Live ("Staging")
  • CMS Development (DEV) -> Live (Dev website) and sometimes Developer local machines (laptops)

Expectations and restrictions:

  • Multiple teams and multiple websites
  • Single DEV CMS license (typical for customers, I believe?)
  • Enough CD licenses for each developer
  • Preferably developer could program and run changes locally--was this a reasonable expectation?

Worked

We developed ASP.NET pages using the Content Delivery API against the same broker database for local machines and CD DEV. Local machines had CD dlls, their own license files, and ran/debug fine with queries and component presentation calls.

Bad

We occasionally published to both the Dev presentation server and Developer machines which doesn't seem right now, but I think it was to get schema files on our local machines. But yes, we didn't trust the Dev broker database.

Problematic:

Local machines sometimes needed Tridion-published pages but we couldn't reliably publish to local machines:

  • Setting multiple publication destinations for a single "Local Machine" publication target wouldn't work--we'd often take these "servers" home.
  • VPN blocked access to laptops offsite (used "incoming" folder at the time).

Managing publication targets for each developer and setting up CD for each new laptop was good practice (as in exercise, not necessarily as a good idea) but just a little tedious.

Would these hindsight approaches apply?

  • Synchronize physical files from Dev to local machines on our own?
  • Don't run presentation sites locally (localhost) but rather build, upload dll, and test from Dev?
  • We were simply missing a fourth CMS environment? As much as we liked our Sales Guy, we weren't interested in purchasing another CM license.

How could you better setup .NET CD for several developers in an organization?

Edit: @DominicCronin pointed out this is only a subset of a proper DTAP setup. I updated my terms and created a separate question to clarify DTAP with Tridion.

2
tridion
I still find that the easiest is to follow the "Fifth Environment" principle, as Chris outlines here urbancherry.net/blogengine/post/2010/02/06/… - Nuno Linhares
Great topic Alvin. I have seen and experienced the same with some implementations and this is one of the main reason that CWA or MVC models work better or chosen by some. - Ram G
You used the term DTAP (for Dev-Test-Acceptance-Production) and then went on to describe a three-tier system with the middle one called staging. It's fairly well established terminology in the Tridion world (at least the European part of it) that Staging (not Preview) refers to the web site where content is checked before going to Live. So each environment needs a Staging and a Live site. Is Preview an Americanism? - Dominic Cronin
That specific group already had a Staging site meant for development testing and content review before Tridion. So Preview would be Acceptance in this case. Although one group also had "Pre Production." Not sure who else uses "Preview." I'll adjust the answer. - Alvin Reyes

2 Answers

3
votes

The answer to this one is heavily depending on the publish model you choose.

When using a dynamic model with a framework like DD4T you will suffice with just a single dev environment. There is one CMS, and one CD server in that environment and everything is published to a broker database. The CD environment could be used as an auto build system, the developers purely work locally on a localhost website (which gets the data from the dev broker database), and their changes are checked in an VCS (based on which the auto build could be done).
This solution can do with only a single CMS because there is hardly any code developed on the CMS side (templates are standardized and all work is done on the CD side).

It gets more complex if you are using a static or broker publishing model. Then I think the solution is to split Dev up in Unit-Dev and Dev indeed as indicated by Nuno and Chris. This solution requires coding on both the CMS and CD side, so every developer has a huge benefit in having its own local CMS and CD env.

1
votes

Talk to your Tridion account manager and agree a license package that suits the development model you want to have. Of course, they want to maximise their income, but the various things that get counted are all really meant to ensure that big customers pay accordingly, and smaller customers get something they can afford at a price that reflects the benefits they get. In fact, setting up a well-thought-out development street with a focus on quality is the very thing that will ensure good customer satisfaction and a long-running engagement.

OK - so the account managers still have internal rules to follow, but they also have a fair amount of autonomy in coming to a sensible deal with a customer. I'm not saying this will always work, but its way better than blindly assuming that they are going to insist on counting every server the same way.

On the technical side - sure, try to have local developer setups and a common master dev server a-la Chris's 5th. These days, your common dev environment should probably be seen as a build/integration server: the first place where the team guarantees all the tests will run.

Requirements for CM and CD development aren't very different, although you may be able to publish to multiple developer targets from one CM if there's not much CM development going on. (This is somewhat true of MVC-ish approaches, but it's no silver bullet.)