Obviously, any serious software developer uses a development environment to build and test any programming changes before updating the production system. When setting up your Microsoft Dynamics CRM development environment, you should consider the following factors:
Considering each organization has different needs based on these criteria, there is no “right way” to set up your development environment. The best option for your organization might not be appropriate for a different company.
The actual requirements of your production system dictate the environment you need to have in place for development (and testing). You should consider the following questions when beginning development on any Microsoft Dynamics CRM 4.0 project.
Next we will review different alternatives regarding how you might want to set up your server and Outlook client development environments.
Because Microsoft Dynamics CRM requires several infrastructure components such as Active Directory, Windows Server and SQL Server, it’s not convenient to set up different physical server environments for developing and testing. In addition to requiring more servers (either physical or virtual), it can be time consuming just to set up these required components. Therefore, if you plan on having a team of developers working on Microsoft Dynamics CRM, you have a few other alternatives regarding how you set up your development server environment. The following sections explore four common development environment approaches:
-
Using an isolated development environment
-
Sharing a common Microsoft Dynamics CRM organization
-
Using a hybrid environment
-
Using different organizations in a single Microsoft Dynamics CRM deployment
Isolated Development Environment
An isolated development environment requires each developer to work from his or her individual (or isolated) copy of the Microsoft Dynamics CRM 4.0 application and database. This is most commonly done with a virtual image of Microsoft Dynamics CRM or when the base operating system of the developer's computer is Windows 2003 or Windows 2008 and Microsoft Dynamics CRM is installed directly on it.
This approach has the following advantages:
-
Complete isolation of the development experience, allowing for the developer to maintain his or her environment as appropriate
-
Simplified debugging of individual code
-
Easier to develop custom Web pages with Microsoft Dynamics CRM since you can reference and debug the pages directly on the server
The isolated development environment does have a few disadvantages, including:
-
You need to synchronize environment changes (customization changes) between multiple developers.
-
Managing backups of the environment is more challenging because each developer has a full copy of the Microsoft Dynamics CRM system.
-
Overall performance of the development computer may not be optimal because the developer's computer will be sharing resources with either the virtualization software or the Microsoft Dynamics CRM application.
-
Since you are installing the Microsoft Dynamics CRM software to each developer's computer or using multiple Microsoft Dynamics CRM virtual images, additional software licenses, such as SQL Server or the operating system software, may be required.
-
Properly testing Web farm scenarios is more challenging.
-
Large databases will take up more disk space and take longer to transfer between developer machines.
Figure 2-1 shows each developer's computer as a stand-alone Microsoft Dynamics CRM installation. You can (and should) share Active Directory and a development Exchange setup. The diagram also shows a build server used to aggregate Microsoft Dynamics CRM customizations and custom code from the development computers for deployment to a quality-assurance environment.
.png)
Figure 2-1 An example of an isolated Microsoft Dynamics CRM development environment
Although you should consider each of the disadvantages of the isolated approach, the most critical drawback that you should take into account is the merging of customization files. With multiple developers making schema and Microsoft Dynamics CRM customization changes on their discrete systems, you might have difficulty getting to a baseline set of final changes. It is possible to manually merge individual customizations changes between environments, but that process is tricky and often would negatively impact the efficiency of your developers or quality assurance team. If you plan to use this development environment approach, you should plan on including a programmatic approach to synchronize the environments between developers. For more information on manipulating system customizations with code, buy the book and read Chapter 8 “Developing with the Metadata Service”.
A hybrid environment approach, discussed later in this excerpt, offers a possible solution to the problem of merging customizations. But let's first look at a different development environment option, sharing a common Microsoft Dynamics CRM deployment.
Sharing a Common Microsoft Dynamics CRM Deployment
The shared approach requires all of your developers to work from a common shared Microsoft Dynamics CRM deployment. They still develop their code on their individual computers, but they reference the customizations (that is, schema) from a common installation.
This approach uses a common Web server or set of Web servers against a single database instance, so that each developer is always working on the most up-to-date schema and Microsoft Dynamics CRM customizations. You can also extend this approach by bringing up additional virtual servers pointed at the same Microsoft Dynamics CRM database, allowing you to use different server setups when developing and testing.
This approach has the following advantages:
-
Schema and Microsoft Dynamics CRM customizations are accessed from a single location.
-
Environment management is centralized for backups, storage space, and so on.
-
No additional server software licensing is required.
-
The load and specifications of each developer computer are reduced.
-
Accommodating environment permutations (32 or 64-bit servers, Web farms, IFD, and so on) is easier.
The shared development environment also has the following disadvantages:
-
The environment shares the asynchronous processing service and file system. This makes deploying and debugging changes more challenging for multiple developers working on any asynchronous logic (such as async plug-ins and workflow assemblies).
-
Remote debugging must be used.
-
Environment issues affect all developers.
Figure 2-2 shows a Microsoft Dynamics CRM installation shared by multiple developers. Each developer develops locally on his or her computer, but uses the schema and database from the shared Microsoft Dynamics CRM setup. The build server in this example merely compiles the custom code and extracts the customizations before applying them to a quality-assurance environment.
.png)
Figure 2-2 An example of using a shared Microsoft Dynamics CRM development environment
The key downside to the shared approach involves the Async service. Unfortunately, the Async service scans and executes against all organizations in the mscrm_config database. As you scale organizations to a centralized SQL Server computer, all of your developers are forced to use and debug against a single instance of the Async service.
.gif) Important |
|---|
|
Microsoft Dynamics CRM does not include an automated build server; you must set up your own if you want to leverage this functionality.
|
Using a Hybrid Environment - Option 1
Now another variation of the third alternative combines different facets of the first two environments. We start by assuming you provide isolated Microsoft Dynamics CRM environments for each developer. That means each developer's computer requires a separate version of SQL Server 2005 or SQL Server 2008 and Microsoft Dynamics CRM 4.0 and the developer programs his or her changes against the separate instance of Microsoft Dynamics CRM. Just as with the other approaches, you use the existing Active Directory infrastructure and a development Exchange environment. This provides all of the benefits described in the earlier section “Isolated Development Environment.”
To help mitigate the main challenge of synchronizing Microsoft Dynamics CRM customizations between each development computer, you can create a shared customizations environment and force your team to make all Microsoft Dynamics CRM–related customization changes (such as schema updates) through that environment. Then you can automate a database backup/restore back to the individual developer environments either on a schedule or manually kicked off as needed. You need to be sure to backup/restore the common mscrm_config as well, since Microsoft Dynamics CRM has some identifiers stored in there.
A few disadvantages also exist with this approach. The main disadvantage of this approach is that you will need to develop your own code and process to set up the automatic synchronizations of the database and customization changes. Further, your staff needs to remember to make all customization-based changes to the centralized environment and synchronize back down to their environment. Finally, if you have a very large CRM database, then the time it takes to copy the backup file may be a concern.
Figure 2-3 demonstrates a possible example of the hybrid development environment approach.
.png)
Figure 2-3 An example of a hybrid Dynamics CRM development environment
The next section discusses another variation of the hybrid environment that provides some level of isolation, while still maintaining a centralized environment for customization changes.
Using a Hybrid Environment - Option 2
In this approach, we provide a partially isolated environment, but one that is much easier to maintain than the previous hybrid environment option discussed. Start by providing Microsoft Dynamics CRM environments for each developer, but instead of pointing the installation to a local instance of SQL Server, point it to the centralized environment's SQL Server. Now, the developer can access CRM and any local web files and services directly from the development server. Just as before, all of the CRM customization changes are managed through the centralized server. However, since the local development Web server points to that centralized database, no changes need to be synchronized.
This approach also allows you to avoid having to install and manage another SQL Server instance. The main negative is the developer will have to share an Async service with the centralized CRM server as described with the Sharing a Common Microsoft Dynamics CRM Organization approach, discussed previously.
Using different organizations in a single Microsoft Dynamics CRM deployment
While the first three options provide the most flexibility for developers, another potential and simplified development environment option exists. By taking advantage of the multi-tenant functionality within the enterprise edition of Microsoft Dynamics CRM, you can simply create additional separate organizations for each environment (development, testing, and so on).
This approach has the following advantages:
-
Provides development and testing environments that share a common set of hardware with no additional cost.
-
You can be confident that the development system hardware specifications match the production system.
The multiple organization development environment has the following disadvantages:
-
Server problems caused during development and testing will negatively impact production (or the other organizations on the server).
-
Common development tasks such as resetting services or debugging code will affect production.
-
Any custom Web page or Web service development becomes more challenging since you are sharing Web servers with production.
-
Requires the enterprise edition of Microsoft Dynamics CRM.
Since the multi-tenant option reuses the same hardware as your production system, it works best when the configuration of Microsoft Dynamics CRM focuses mostly on native customizations and workflow. Native customization and workflow changes are contained within the Microsoft Dynamics CRM application and are easily developed and deployed between organizations.
When possible, we recommend separating your development environment on its own set of hardware. However, if you are unable to use separate hardware for the development environment, then consider the multi-tenant option over making programming or customization changes directly on the production organization.
In addition to setting up your Microsoft Dynamics CRM development server, you should also think about how you will test your programming customizations within Microsoft Dynamics CRM for Outlook. In general, most of your customizations should execute equivalently from the Outlook interface, but if you have offline use as a requirement, you need to ensure that your logic works properly when disconnected from the server.
Microsoft Dynamics CRM for Outlook allows you to target only one Microsoft Dynamics CRM organization at a time. We recommend that you install the Outlook client on a separate desktop computer for testing and development. If you need to change your Outlook client from one organization to another, you can do so using the Outlook CRM client's Change Organization menu option. Virtualization offers an excellent option for Outlook client environments.
Because Microsoft Dynamics CRM for Outlook synchronizes contacts, activities, e-mail, and appointments into Outlook, you probably don’t want to install this software on your normal Outlook profile. Therefore, it’s a good idea to setup a separate test user and use that profile for testing, avoiding accidentally contaminating your Outlook file with data from the test and development environments.
.gif) Tip |
|---|
|
You can only install Microsoft Dynamics CRM for Outlook with Offline Access for a single user on a computer. However if you’re using the non-offline version, you can login to a computer with multiple users to access the software. Therefore, you could set up a single machine for testing the non-offline version, and log on to the computer using different users (one for each organization).
|
For more information, buy the book and read Chapter 10, "Developing Offline Solutions," which discusses developing with the Outlook client in greater detail.