So I’ve finally got a bit of time to blog again. This isn’t the post that I intended to write, that’s still coming – instead I thought I’d blog about my experiences while developing a large solution based on Dynamics CRM 2011.
The solution we are creating uses custom MVC 4 pages to steam-line data entry into a number of underlying CRM entities. Additionally, it contains scanning, fuzzy-matching and SharePoint integration functionality. Here’s my top 10 things you can do to improve your processes and approaches when working with Dynamics CRM 2011.
Empower your developers – My team each has their own development VM image hosted centrally and each image has MSDN licensed VS2012, CRM 2011, SQL + whatever other tools they need. In fact, these VM’s are based off a master template VM that has a number of required applications pre-installed, along with a central tools folder where any additional installation files are available (rollups etc).
What this means is that it’s relatively easy to get a new VM up and running. Clone the master, and update a few settings to get CRM running. This typically means creating a new Organisation, but there’s a shortcut for that which I talk about later.
The main benefit of this approach however is that developers can get on with their work without stepping on each others toes or wrecking each others work. I’ve heard nightmare stories of a single CRM development server. Don’t do it. Development VM’s per developer is a no-brainer. We allocate around ~6GB per development machine for a full CRM Server Install with VS2012.
Automate everything – Use build scripts as much as possible in conjunction with a continuous integration server (TeamCity) for unit testing/style cop checks & building / deploying the solution. This removes errors introduced by doing things manually(*). For example, there’s no reason why you can’t create the CRM organisation, users, teams and load base data automatically from a couple of scripts. Here’s some useful links:
I’d mentioned about that we’re using an MVC website in the solution. In this case we have 2 additional scripts that are baked into our process. The first downloads the changed CRM Solution from the developers CRM server, the second generates the CRM classes to access the solution. Typically these two scripts are run as an atomic action (not all the time though – simple ribbon changes don’t require it).
The reason for this is that when we commit, we can do so knowing that the solution, matches the classes generated to access the solution. I.e. no funny side effects.
* Note that CRM installs in US-English mode with US Date formats as a default. You should set the regional settings on the server before users get added as they adopt the server’s settings. This can be a pain when your data imports fail because the dates are incorrect. Ideally this will be done automatically too via your build script.
Use Source Control for your CRM Solution – And I don’t mean stick the zip in source control either. There’s a tool that you should be using, and it’s called the Solution Packager, found in the tools directory post rollup 10. Here’s some blurb from Microsoft –
“A Microsoft Dynamics CRM solution is a compressed (.zip) file that contains multiple customized components that have been exported from a Microsoft Dynamics CRM server so that they may be transported and imported into another server. However, a solution file is a single binary file that does not lend itself to source code control or team development. There is no way for multiple developers to work on the custom components in the solution.
The SolutionPackager tool, available in the Microsoft Dynamics CRM 2011 Update Rollup 10 version of the Microsoft Dynamics CRM SDK download, resolves the problem of source code control and team development of solution files. The tool identifies individual components in the compressed solution file and extracts them out to individual files. The tool can also re-create a solution file by packing the files that had been previously extracted. This enables multiple people to work independently on a single solution and extract their changes into a common location. Because each component in the solution file is broken into multiple files, it becomes possible to merge customizations without overwriting prior changes. A secondary use of the SolutionPackager tool is that it can be invoked from an automated build process to generate a compressed solution file from previously extracted component files without needing an active Microsoft Dynamics CRM server.”
Sounds good doesn’t it? Well it’s not perfect. The extracted files are difficult to understand until you get used to them. The other thing is that it’s quite easy to completely break the solution for another developer. Some of the things that can do this are changing the type of a field or an option sets definition. When you try to import again, you typically get a cryptic FaultException.
In the case of these breaking changes, we get the dev responsible to make the changes, create a new organisation, load the data again (via the automate process) and then take a backup of the organisation and store it centrally.
Take a backup of the organisation – Once you have your solution in a good state, and potentially have base/test data loaded, take a backup of the solution from SQL Server and store it centrally. This is as simple as following the steps below:
A) Access SQL Server and take a backup of the database.
C) Use the Deployment manager to import the organisation. It will automatically scan the databases available and display the recently added DB. Simply follow the onscreen instructions to import it, plus ALL data into a brand new organisation.
Note, that this is much simpler for development machines on the same AD, as the user mapping element will have no issues. This process greatly expedites setting up a new machine, or bringing in new solution changes. A data import can take 30-40 minutes to do – a CRM DB import using the deployment manager can take ~3-4 minutes.
Embrace Multi-Tenancy – CRM is multi-tenant, meaning that you can have more than one organisation running at the same time. We use this for testing as it means that a tester and developer can compare one or more previous working releases against the current release (if needed).
To achieve this, it’s simply a case of making sure that your automated build and deployment process successfully parameterises specific variables such as the CRM organisation name, port, database etc. Then when a new deployment occurs, you simply increment, i.e. http://project/release-1, http://project/release-2, http://project/release-3 etc. Note that it’s better to take these parameters via a prompt on the cmd line at the start of your deployment, rather than editing script files each time.
Explicitly Control CRM Changes – Ok, so you have 10 developers working on the project, and they all want to update the solution? Nightmare. The way we’ve dealt with this is to use a Trello board to build up or task list of changes and the next person in line to make a change, adds a card to the ‘Making a change’ list. Skype and Lync are also heavily used.
Only one person at a time should do this. They can then update the solution, load data and take a backup (if needed – i.e. the crm solution change is a breaking one). Controlling updates to the CRM solution is probably the most important tip in this list, as it’s so easy to remove someone’s changes from another solution. Using winmerge on CRM Solution file artefacts is no fun either.
There’s a ton of CRM 2011 Tools, use them – This is a fantastic list for CRM tools. Ones that deserve a particular mention are the View Layout Replicator which allows you to set one view and have the rest adopt it, Toggle Visibility which allows you to see the underlying CRM field names from IE, Linqpad Plugin for running linq queries against CRM and the RunAs GUI for testing different user/security settings.
Beware of Rollups – Firstly, ensure that every member of the team is on the same version of CRM, including rollups. Turn off automatic updating of Internet Explorer, and when CRM asks you if you’d like to get updates, say just say no.
The reason being is that Microsoft add new functionality with each new rollup that’s released for Dynamics CRM. This can be a pain to manage, so my suggestion is to agree on a specific roll-up with your customer and build to it. This can cause issues when new features are desired by the customer, but these new features need to be traded off against the breaking changes they may introduce (for example, the new form layouts in Rollup 12 – Polaris) Better to control it and regression test the changes on an isolated environment before bringing them into the mix.
Beware of dates – CRM stores dates in UTC format and applies the local regional settings when you retrieve any date values. Be are that you need to take account of this in any service layer code that you write (i.e. in standalone MVC apps). Also, if you’re querying the database, use the filtered views provided, as these apply the correct date translations and security permissions
Workflow ownership blues – Be aware that if you use a tool, such as the ribbon workbench, to make modifications to the base solution, and then try to publish, you’ll get failures due to workflows existing in the solution that you potentially don’t own. In this scenario, we’ve assigned the workflow ownership to the administration user and then make solution modifications using the same account.
I’ll be sure to update this list with any more CRM tips that are useful. In the meantime, have a look at the Dynamics CRM 2011 Solution Lifecycle Management Whitepaper that Microsoft have released. Have a great weekend!