Microsoft Dynamics 2012 Environment Setup

Infrastructure The following diagram shows the infrastructure as it is to be deployed on customer sites implementing Dynamics AX 2012. The description for these systems follows below. Development Environment The development environment(s) is being used by developers to implement customizations and fix bugs. A development environment must have all components installed and functional that the targeted production system will have. In most cases, it is best to have these systems completely encapsulated to allow the developer using that system to quickly access all components and eventually modify, restore or remove them without the involvement of a system administrator. This allows for maximum flexibility during the actual development, but requires the developer to maintain it responsibly. Due to the integration with Team Foundation Server, a development system cannot be easily re-assigned to another developer. The development environments are the only source of any code that enters TFS. All other systems consume the code stored in TFS. QA Environment The QA environment(s) is being used by: Functional consultants to perform the pre-checkin test of customizations. Development Team Leads to perform code reviews. Solution Architects to perform code reviews. QA environments are usually re-built for the purpose of testing a single customization. The system's live-span is very short and should not be used for any other purpose but testing a single customization. TFS The Team Foundation Server (TFS) system hosts the source code control system that stores all customizations, scripts and eventually implementation data. Users do usually not have access to this system directly. Access to the system is being accomplished through the various front-end components of TFS (e.g. web access, Visual Studio, Dynamics AX). Build Environment This environment and system is used exlusively for generating builds out of the version control system and to run the initial test for these generated builds. The system is being controlled by TFS and only the technical lead would need access to this system for periodic maintenance tasks. Test Environment The test environment(s) is being used by users and/or functional consultants to test modifications undisturbed by ongoing development work. Under no circumstances should developers do development in the test environment. Debugging in a test environment can be very disruptive to other users and must only be done with prior approval from the project manager for a narrow time window and for issues that cannot be reproduced on the development environment despite multiple attempts to do so. Training Environment The training environment is used to train key and end users in preparation for the Dynamics AX 2012 introduction. The training environment is loaded with builds from the test system that are regarded stable enough to train users on them. The system must not be used to test customizations or other code changes. Sandbox Environment Sandbox environments are environments that users and/or developers can play with, modify and test new ideas on without any restrictions. Sandbox environments might be shared. In this case, the users of these systems should be considerate of others that might also be using the system. Sandbox systems should be periodically re-built. Users of these systems must not assume that changes will be kept or the systems resemble the current build status. Issues and code defects cannot be reported based on a reproduction on a Sandbox system. Configuration Environment The configuration system is optional for implementations that have a production systems set up at the beginning of the implementation. The configuration environment is being used to collect all configuration, parameter and reference data for the implementation. The test if certain data is suitable for the deployment to production must be done on other systems. Under no circumstance should any transactional data be added to this system. The system is accessible only to users that own data that is being collected on this system. Developers must not have access to this system. If code promotion is being done manually, the Technical Team Lead might require access to promote the latest builds to this system. Pre-Prod Environment The Pre-Prod system is used for the final User Acceptance Test and performance tests to be conducted on the system. Absolutely no code changes or debugging may occur on this system. Production Environment Developers should have no access to this system. Exceptions can be made to observe certain system behavior to ease the reproduction of reported issues. In these circumstances, the developer must not be able to change code artifacts of any kind, but might only observe system behavior. This system must be protected from un-authorized changes (code and data) by all possible means.