Had a couple of DTAP related conversations this week and remembered that I’d once put together some notes about DTAP that I’d emailed to a former colleague. Figured I’d give a bit of a polishing up and share it.

First some terminology:

Release – A bundle of code, assets, scripts, steps and documentation for a given piece of work. Roll-back steps may also be included in this bundle.
Deploy – The act of taking the release and installing it.
Migrate – Taking a copy of something and moving the copy from one place to another
Owner – The people that paid Consultants to do the work
Consultants – The people paid to do the work

DTAP and Environments.

When you write websites you typically don’t build them ‘live’ (unless you’re the Dos Equis guy), normally they’re hidden at a secret URL, which is only shared with those in the project. These are ‘environments’ one is the ‘hidden environment’, the other is the ‘live environment’.

DTAP is similar to this, but rather than ‘hidden’ and ‘live’ there’s (usually) four environments:

• Development
• Test
• Acceptance (commonly known as U.A.T)
• Production

It’s always a good practice to keep these environments as architecturally close as possible and to keep them maintained with the latest content and configuration, where possible.

Why have so many environments?

Each environment has it’s own purpose, here’s a brief overview of what their purposes are:

Development

This environment is typically used by the development team to build and update existing project work such as:

Template building blocks, GUI extensions, Core Service related tools that are used within the Content Manager, Custom Dreamweaver functions, event and workflow code.
Deployer and storage extensions that take place during publishing.
Content Delivery and application code used by the published application.

It’s pretty common that developers make mistakes, imagine if they made a mistake in a live environment and brought the entire application down, business and end users would be pretty angry.

It’s also here that system administrators will install and test SDL Tridion / SDL Web hot-fixes, patches or newer versions of software.

Once development of the work is completed in this environment, it is migrated to the test environment; this is typically referred to as a ‘release’.

The development team celebrates by agreeing to go for ‘maximum two’ beers. The following day no one shows up for work till lunchtime, no one really remembers the time they got home, but agree that it was a awesome night.

Test

This environment is used to test that the release is:

• Free of bugs.
• Migrates to another environment without issue.
• Does not cause any unexpected issues from content creation, publishing and content delivery etc.

Test may also be used to perform a whole load of other types of testing for example concurrency and load.

If the release is success, the very same package that was exported from development is then migrated to acceptance.

If it fails, the package is thrown away and the results / issues are given back to the development team.

Acceptance

The acceptance environment is used to demonstrate the release to the owner(s) of the work to gain ‘acceptance’ that is correct.

• Reviewed against the functional requirements.
• Tested by the owner(s) to ensure they’re happy with what has been built.

The owner decides that the work is either great.  If approved release is then deployed to the Production environment, if not changes and requests are given back to the development team.

Production

This is the live environment, if you’ve made it here well done, the code that you wrote made it all the way though testing, acceptance and is now live!

Who has access to what?

Now that it’s a little clearer what these environments are, it’s worth mentioning littte about access.   In some instances (and depending on clients, imagine you’re working for a bank) access to other environments other than development will be forbidden to developers.  In other cases the development team can also be responsible for managing and deploying the work across all environments.   This really depends on the client, but the most common is that developers work in development and infrastructure teams have access to other environments within DTAP.