Obviously, serious software developers use a development environment to build and test their programming changes before updating the production system. When setting up your Microsoft Dynamics CRM development environment, you should consider the following factors:
The number of discrete projects or Microsoft Dynamics CRM organizations required
The number of developers
The types of customizations required
Deployment configurations
Available hardware
Iteration frequency and deployment schedule
Considering that 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.
Do you use the Windows 2003 or Windows 2008 operating system?
Is your operating system 32-bit or 64-bit?
Will your application be accessed via the Outlook client?
Do your customizations require offline capability?
Do your customizations need to be SSL-compliant?
Will your application be accessed with Internet Facing Deployment (IFD) or online deployments?
Do your customizations need to be Web farm–compliant?
Which version of Internet Explorer do your clients use?
Will your customizations be accessed in multiple languages?
What version of SQL Server is used, SQL Server 2005 or SQL Server 2008?
Will your solution need to be accessed via a mobile client?
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
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 because 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 for 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.
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 customization 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. Please refer to Chapter 8, for more information on manipulating system customizations with code.
A hybrid environment approach, discussed later in the chapter, 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 environment.
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 (i.e., 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-bit 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 to a quality-assurance 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.
Now let’s consider a third alternative that combines different facets of the first two environments. We start by assuming that you provide isolated Microsoft Dynamics CRM environments for each developer. That means each developer’s computer requires a separate version of SQL Server 2005 and Microsoft Dynamics CRM 4.0 and that developers program their changes against their 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 section titled "Isolated Development Environment" earlier in this chapter.
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. A 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, but that should be much easier than merging individual Microsoft Dynamics CRM customizations.
Figure 2-3 demonstrates a possible example of the hybrid development environment approach.
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 separate organizations for each environment (development, testing, etc.).
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 because you are sharing Web servers with production.
Requires the enterprise edition of Microsoft Dynamics CRM.
Because 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 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, 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.
Because Microsoft Dynamics CRM for Outlook client 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 set up a separate test user and use that profile for testing. This way, you won’t run the risk of accidentally contaminating your Outlook file with data from the test and development environments.
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 nonoffline version, you can log on to a computer with multiple users to access the software. Therefore, you could set up a single machine for testing the nonoffline version, and log on to the computer using different users (one for each organization).
Chapter 10, discusses developing with the Outlook client in greater detail.