Setting up your Dynamics CRM Development & Source Control Environment

Every time I meet people trying to get CRM projects going, I get plenty of questions about how to setup environments and source control properly. Unfortunately, there is no easy answer. However I thought I would share a model that I’ve used on many occasions and that works well with a combination of a defined methodology, appropriate tools, training, commitment and discipline from the project team members. It is mostly relevant for large projects with multiple developers.

The proposed setup is based on the flowchart below, and it is inspired by fellow MVP Gonzalo Ruiz’s article on the same topic.

 

Development machines (CRM DEV)

The development machines can be a developer’s laptop or work station with CRM development tools + a dedicated CRM organization for the developer (CRM Online or on premise). It can also be a full server (or VM) with CRM installed and dedicated to a single developer. These organizations are setup with a master configuration solution (more on this later) and smaller transport solutions to bring required components for development.

Developers use the various development tools to write code and to debug (attach to CRM services, attach to IIS, using Profiler, browsers debugging tools or using tracing).

When development items are completed, developers build temporary “transport solutions” containing the components they worked on and they push them to the Master Configuration organization. Developers must be careful and not make schema changes on their own development organizations. As the code is deployed to the master configuration, it should also be archived in the source control.

Master Configuration CRM Organization

There is only one Master Configuration environment. It contains the schema configuration and all schema changes should be made there. There is usually one or multiple “Master” solutions sitting in this organization based on how you decide to structure your deployments. You may want to have multiple solutions for various types of customizations (e.g. one for schema, one for plugins, one for web resources etc.), or based on functionality grouping.

When developers set up their organizations, they can pull the entire master solutions from the master configuration organization as unmanaged and install them in their development. They can also create temporary “transport solutions” to pull only the customizations they need.

A process (manual or automated) should be put in place to archive the master solutions on a regular basis (daily is recommended). Archiving could be saving the CRM solution files in source control, or even creating snapshots of the server and keep them around for a reasonable period of time.

Integration / Test CRM Organization

This organization receives the master solutions and is used to perform tests. It can be combined with the master configuration environment. The choice to go with a managed or unmanaged solution when going from master configuration to integration/UAT/Prod environment is a business and technical decision. It is a separate discussion that we could write an entire blog post about J.

UAT / PRE PROD / PROD

These environments receive the master solution(s) after they have been tested and validated on the Integration/Test CRM organization.

Wrap Up

Putting this type of environment in place is not easy to do. It takes a lot of process implementation, tools and automation build and more important, training and discipline from the project team members. When working on small project (small number of developer, low amount of customizations and code), going with this approach is overkill. It applies best for big projects when you have multiple developers and heavy customization requirements.

 

This was fun. Hope it helps!

Common CRM Solution Package Components

As a CRM Solution Architect, one thing that I often try to do is keep the complete solution package with a minimal amount of components in order to simplify the deployment process. In an ideal world, we want to limit a deployment to a solution deployment. In reality, this never happens on complex implementations. The purpose of this article is to point out some of common elements that are typically deployed as part of a CRM solution deployment.

• CRM Solution: This is the .ZIP file extracted from your development CRM server that contains the system configuration and customizations. As part of a deployment, you typically always have one or multiple CRM solutions to apply to the target environment
  • Steps: Import CRM solution(s) in your target environment
  • Can be automated: Yes, use CRM SDK

• CSV Files for data import: There is often a need to load master data on the system. For example, if you have entities for “Country” and “State”, you may want to populate them with data before people start using the system. This is easily done with a CRM data import wizard.
  • Steps: Import CSV or XML files in your target environment
  • Can be automated: Yes, use CRM SDK

• Run Workflow(s) against a specific set of record: This is a technique that is often used to fix data issues. Examples of use: change record ownership, populate new fields created as part of the current release, delete records (data clean-up).
  • Steps: Define the query that will return the records you need to run your workflow against, find them (Advanced find or FetchXml) and execute the workflow against all records
  • Can be automated: Yes, use CRM SDK

• Perform data load from external source: Loading data is usually done by external system (SSIS, Scribe, custom integration etc.) that have connectors to CRM. As part of a CRM deployment, you’ll often have to run data load/update tasks after configuring your integration service to point to your production server. This is used to do data migration or to enable on-going integration between multiple information systems.
  • Steps:
    • Deploy integration components and/or configure them to execute on your target environment (e.g. install SSIS packages, configure Scribe etc.);
    • Turn on integration jobs
  • Can be automated: Depends on the integration tools used

• Deploy custom web services and/or web sites: To provide extended integration with CRM, we often need to create our own web services that expose custom operations involving CRM data. We also frequently see the need to build custom web applications outside of CRM to display complex and/or integrated data within CRM screens or to create external portals. These web services and web apps become part of the release cycle of your CRM solution.
  • Steps: Package web services and web sites; deploy them on target IIS server(s) and configure CRM endpoint(s) in Configuration files as needed
  • Can be automated: Yes, depending on how web apps is built and packaged

When delivering enterprise solution deployment packages, one best practice is to always plan to automate the deployment of all components that be can be automated. It shortens the solution package deployment process, limits the possibilities of human errors and helps make deployment administrators happier which results in them having a better relationship with the solution and product (I speak from experience J).

CRM 2011 Solutions Manager Update

I recently made changes to the CRM Solutions manager. One of the most requested feature was the ability to import solutions from a computer directory as opposed to having a “source” organization from which the solutions had to be exported. The list of features is available below and the tool and source code are available on the CodePlex project. Enjoy!

CRM 2011 Solutions Manager features

• Export CRM Solutions as managed and/or unmanaged from Source Organization
• Import unmanaged and managed Solutions from source organization to target organization
• Import unmanaged and managed Solutions from local folder (.ZIP solution files) to target organization
• Publish all Customizations in target environment after each solution import or after all solutions are imported
• Supported installation types
  • CRM Online (tested)
  • On Premise (tested)
  • ADFS (not tested)

Always, for background on the tool, you can always check out the article I wrote a while back that provides more details on why the tool the built in the first place.

CRM Solutions Import/Export Tools

Using the development methodology defined in the picture below (for more details, see Gonzalo Ruiz’s blog post here), our team spends a lot of time exporting unmanaged solutions from the Integration Development / Configuration environment (B) to our development environments (A), exporting and importing our “transport solutions”.

With the master solution growing in size, it takes more and more time to export, import and publish it every time. My colleague Jean-Francois Fortin and I worked on a very simple console application that automates the process of exporting and importing CRM solutions from one organization to another. Since then, it’s been transformed into a nice looking tool with a GUI (yes, we are that nice!). You can download the executable and the source code on the CodePlex project. The UI version of the application is the recommended and default download. Configuration is straight forward.

If you are using the Console version (older release), make sure you read the user guidelines below. All you have to do if you are not a developer is download the executable and edit the configuration file to point to your environments and solutions.

Application Guidelines

Usage

The menu is self-explanatory:

It should be noted that currently only unmanaged solutions are supported for import. If a timeout occurs during a solution import, the program polls the server every 10 seconds to see if it has finished the import task. To avoid a timeout during publish all customizations or other operation, set the ServiceTimeout, configuration parameter to a reasonable time (default is 2 minutes).

During import, the file matching your solution name which has the most recent time stamp and not containing managed.zip in its filename is imported.

During export, the version number of the solution is appended, as per the CRM default export filenames.

For now, this only work for Microsoft Dynamics CRM on Premise.

Configuration

Once compiled, you can modify the Crm.Utilities.SolutionsDeploymentTool.exe.config file in the bin directory to change the values for the source and destination organizations or App.config before compilation.

CrmOriginOrganizationName

The name of the organization to export from. There can be several organizations on a server, so with this parameter you can select which one to export from.

CrmOriginServer

The URL of the server to export from. Include the http:// prefix and the port number if necessary.

CrmTargetOrganizationName

The name of the organization to import to. There can be several organizations on a server, so with this parameter you can select which one to import to.

CrmTargetServer

The URL of the server to import to. Include the http:// prefix and the port number if necessary.

ServiceTimeout

The value of the default CRM organization service timeout value in minute. If left blank, timeout will be set to 2 minutes.

SolutionNames

These are the solution(s) to export and later import. They are semi-colon separated.

ExportFolder

This is the folder the solutions will be exported to and imported from. There should be a trailing slash.

CrmDomain

This parameter is optional (it can left blank). It can be the active directory domain on which your username is valid.

CrmUsername

This parameter is optional (it can left blank). This is the active directory user name used to log on to the server.

CrmPassword

This parameter is optional (it can left blank). It is not encrypted (saved in plain-text). This is the password matching the username in the previous parameter.