DTAP is an acronym for Development, Test, Acceptance, Production, which is an industry standard change control method that guarantees the highest possible quality of changes in production environments and reduces the chance of unwanted behavior. The idea behind it is quite simple:

1. Develop one (or more) change(s) in a single or multiple development environments, which are derived from the production environment to resemble the desired end result.
2. Test the change(s) by migrating the change(s) to a testing environment. This is to make sure that the change doesn't cause conflicts. When migrating multiple changes, the testing environment can also be used to test whether the changes do not cause conflicts among themselves.
3. Accepting the change by passing the applications functional requirements. After successfully (technically) testing the change(s), the change(s) are ready to be moved to an acceptance environment, where key end-users can be given access to the applications, to verify the change complies with the day-to-day business and fulfills the functionality required.
4. Production environment only contains applications which meet the requirements of the acceptance criteria. Thus after the Acceptance test(s), the change can be moved to the production environment and granted to the end user community.

Changes are required to follow the DTAP chain, in other words applications can only be moved in one direction and from D to T, from T to A, From A to P and thus not directly from D to P.

Also the environments need to have the same Login AM version number to make sure that the changes are consequently behaving in each environment within the DTAP chain.

DTAP Chains

A DTAP chain is a logical chain of Development, Test, Acceptance and Production environments. Each DTAP chain contains only a single production and acceptance environment, but may contain one or more test and development environments. To create a new DTAP chain, click the New DTAP chain button in the environment manager.

To create a new DTAP chain, click the New DTAP chain button in the environment manager.

Give your new DTAP chain a logical name which represents your situation, in this case LAB.

Now you can add environments to the DTAP chain by clicking on New environment.

The environment requires the following specifications:

• Environment Name: Choose your unique name for the environment, please note that the environment name can not be the same in multiple DTAP chains.
• Environment Type: Drop down in the menu to select the DTAP type.
• Prefix: The prefix can be used as a variable in order to create groups, etc.
• Select Environment Template: Here you can either select the template environment of a previously created environment as a base, or create a new environment template.
• Service Account Credentials: This account will be used to perform the AM tasks on the machines.
• Description: Enter a description for your environment.

In the example depicted above, you may notice multiple DTAP chains. When creating an environment in another DTAP, it has to have a unique name throughout all the DTAP chains.

In this example the Service Account Credentials are configured to lab\administrator with a given password, anonymized with ********. This default is based on the availability of the 'lab' domain. Of course this can be different in your particular environment

You can set the service account to any account which you like, as long as it is member of the local machines Administrators group. This account can be member of the Domain Admins group or, in case of a tight security policy, it can also be member of the local Administrators group, see this Microsoft Article: How to Make a Domain User the Local Administrator for all PCs.

Send to wizards

Once the DTAP chain is in place and the environments are created, we can start working in the development environment. In this chapter, we discuss the Send To... functionality which needs to have a package, layer or collection in place. The Send to... wizards can be used to move items from one environment to the next. This can be done for Collections, Layers and Packages.

A Send To... operation can only go in one direction through the DTAP chain (so from Development to Test, or from Test to Acceptance or from Acceptance to Production), never in reverse. To send items the other way around you need to use the environment compare dialog in the Environment Manager.

Start the desired environment, Development in our case, by selecting it in the environment manager and click on the AM User interface button.

In this development environment, we have already imported a blueprint (from the Login AM Template Store) which contains packages, layers and collections for the use of the Send To... functionality.

Select the collection in the user interface, and select Send to... This collection will be send from the Development to the Test environment.

Select the environment to send the collection to, in this case named as Test. Only eligible collections will appear in the list, so you can't send from dev to production. However, it is possible to have multiple test environments which can act as a destination of the Send to...

Click Next.

As a layer can consist of multiple subsets and applications you have the possibility to drill down your selection.

Select the layers and packages to include in the send to operation and click Next.

This screen shows the package settings. AM is flexible by nature and therefore offers you the possibility to provide new values for package settings in the new environment. If the package already exists in the new environment, the values from that environment are loaded by default. For example, it might well be that, in this case, the Connection Broker FQDN differs in the Test environment and here you can easily alter those settings.

Click Next.

The Collection overrides can enforce settings, which can be set on a package level. So this way you can shape the package on the collection level.

In order to do so, you can provide new values for collection overrides in the new environment. If the collection already exists in the new environment, the values from that environment are loaded by default.

Click Next.

Verify the operation in the review page and click Finish.

When using Send To... for layers and packages, only a subset of the wizard pages are displayed.

Environment compare

As the DTAP chain is in a field of constant change, the differences between the various environments are are the focal point for the DTAP manager. In order to get an overview on which collections, layers and applications are different from one environment to the next you can use the Environment Manager, while exploring the DTAP chain, click the Compare button.

For this example the Development environment has some changes that Test environment doesn't contain yet

To compare two environments, select an environment, in our case Development, and click the Compare button.

Now select the environment, in our case Test, which you like to compare against the previously selected environment, in our case Development.

Please be patient as this can take a moment, depending on the size of the environments.

After evaluating the changes between the chosen environments a summary of the changes are displayed. As you can see, the changes are visually ordered in red, blue or grey status. You can use the Legend button to learn about the discrepancy.

Red - Item exists in both environments, but is not identical.

Blue - Item exists in this environment only

Grey - Item does not exist in this environment

While using the arrows, depicted inbetween the two selected environments you can move the change from left to right or even vice versa.

This will open the "Send To..." dialog for the selected item.

Click the corresponding button to move the package from one environment to the other, in our case it will send the "Connection Brokers" layer from Development to Test.

For more details on the Send to... functionality please see: Send to wizards.

After finalizing the Send to... functionality the DTAP compare dialog will refresh again. In our example the collection has been sent from Development to Test but you can also send layers or packages from one environment to the other using this approach.