This project is read-only.

Developer Toolkit and xRM CI Framework‏

Topics: Development Environment Setup
Sep 6, 2014 at 1:19 PM

A few questions:
  • What does your server setup look like? I normally have every dev use their on sandboxed environment (single VM) and have a integration server where we merge the code with nightly builds. Problem is adding fields (I have my teams adding them in the integration environment and exporting from there to their sandbox, saw you had some notes on overwriting customization in your blog). Still remains a pain and time delay, especially if you code early bound.
  • How do you know plugins are registered correctly before you do the deploy? All my builds to date have deployed everything in TFS first (using the developer toolkit targets file by passing parameters to msbuild) and then exported the solution.
  • Finally, saw you had some support for the above in the 2011 version, but can't seem to find any in the 2013. Is it there or would I need to do these steps by changing the process template? (i.e. deploy parameters and targets for msbuild, checkin or registerfile, generate early bound entities)

Peter Björkmarker
Sep 6, 2014 at 5:53 PM
Edited Sep 6, 2014 at 5:53 PM
  1. We are usually splitting our solutions. One solution just contains the "schema" with other words the customizations.
    There is one central instance where everyone makes the customizations. The customization solution is exported managed to the dev instances where the devs are working on plugins and javascripts. Another option is to solve it organizational so that only one dev should make changes to one entity at the same time.
    There is also a third solution: Use the SolutionPackager and act with the customizations like with code using the source control.
    I blogged about the third option. Its in german but may it will be helpful:
    Btw. there is another good thing about it. If you have any troubles with update e.g. your solution which contains the plug-ins you can just delete the plug-in solution and import the new one without losing any data.
  2. I assume if you don't extract the solution components there is no good alternative to that.
  3. Waelhamze can answer this question..
Sep 6, 2014 at 7:17 PM
Hello Peter/Marc,
  1. bellow are a few approaches you can do. There no one approach that works for everything and this will depend on your project and team setup.
a. everybody works in one org. when everyone is ready you export to another org. (difficult to work on plug-in, wf activities, js)
b. Sandbox for each developer with a common org dedicated to do customisations.
c. Sandbox for each developer and use the solution packager the merged code can be deployed using a CI build to central dev for integration testing. (problems with merging changes using the solution packager. - have a blog on this:
d. Sandbox for each developer and main dev. Developer can still work on customisations in their own dev but not on the same entities at the same time. For developer 1 customises entity a and b. Create a transport unmanaged solution and moves these changes to main dev so they are available to export by other developers. (Have to create many solutions and can override each other changes if not careful)

A good matrix for this with pros and cons for each approach would be nice right :)?
  1. The template assumes the environment you are exporting from is in the right state before exporting. That means developer have ensured it is before they queue the build. If using the Solution Packager as Marc suggested you can just have a CI build. Consider running integration tests after each build to ensure things are working as expected including deployment.
  2. MS didn't seem to be investing into the developer toolkit recently. There supposed to be new tools coming out which as you know not there yet. That was the main reason for taking this feature out. as you know many people are still using the developer toolkit including myself. If you would like this feature back, create/vote an issue for this and we can discuss and incorporate this into the next release.
Sep 6, 2014 at 7:49 PM
By the way for re-generating your early bound entities on each build.

All you need to do is write a powershell script that call the crmscvutil and invoke in the pre build extension event.

Check this blog as an example.

You will need to use call tf.exe to check out and check in the file during this process.

Check this file as an example:
Sep 6, 2014 at 8:59 PM
Thanks for all the input!

I haven't seen anyone come up with what I consider a really great solution to these problems so interesting to discuss. I understand it varies with team size and setup. However I spend most of my time helping clients where the dev teams consists of 2-5 people. Also, 1 single developer in the team is a simple problem to solve and I normally advise against bigger development teams than 5 CRM developers (for other reasons, but that's for another day...). so 2-5 team members doing a 6-12 month implementation is what I am referring to.
  • In your first scenario Marc, not fully clear how each developer get their new plugin steps into the main/integration environment? Manually using pluginregistration tool?
  • Organizational solutions works ok in my experience but I like devs doing an entire feature/user story. That often means they need to work on several central entities together with other developers at the same time. Doing that and allowing re-import into main almost always sets you up for those conversations that start "who just overwrote my changes?!?!"
  • So, if using the solution packager, each developer runs a "unpack" ps-script in the sandbox to get it into TFS and then does the merge as one would normally do with code? How long does that process take? I worry about making it too cumbersome to checkin which means developers will start checking is less often which means that quality degrades... The main reason though that I have been hesitant to go this way because of the solution xml and all it's quirks. Have you experienced many issues with conflicting/not matching GUIDs, duplicates of views, merging in VS not showing the correct places where things happened etc? I understand that I can run some integration tests here but I would not want the team spending time verifying customization components. So essentially, will solution import play nice throughout an entire project using this approach? Or have you ended up spending a lots of time manually fixing the xml because of obscure import errors? And the million dollar question, a dev decides a field has the wrong datatype but the name needs to stay the same. What does that process look like?
  • Yeah a matrix would be nice. MS should write it here: :)
  • Agree, the dev toolkit is getting old but none of the tools I have found to date is better at registering plugins and custom workflows. To some extent javascript though that is debatable (no publish, too slow...).
  • Thanks for the tips. I got my good old scripts and homemade console apps, was just hoping I didn't have to use them and the feature was hidden. :) Need to do this Monday so I will just go ahead and update the template.
Sep 6, 2014 at 9:07 PM
Sep 9, 2014 at 11:29 AM
There are different possibilities how this can be done but it depends an the scenario:
  1. The CRM Package Project is used:
    The steps are stored in the register xml file which is checked in in the source control.
    Assume you have one central organization where you merge all changes, in this case you can just click "deploy" and you get the newest bits and also steps.
  2. Unpackig the solution:
    Because you unpack the solution and check it in to the TFS you can use the TFS merge functionality.
    Its similar to scenario 1.
  3. Merge it manually:
    You have one central system with the unmanaged customizations.
    You export the solution as unmanaged and overhand them to the developer.
    The developer imports the solution to his system (managed of course). The developer creates a new "transfer" solution where he puts the changes in (so also the additional plug-in steps). Once a task is finished the developer can export his transfer solution unmanaged and import it to the central system with the unmanged customizations. The steps are merged. In this case its important that the dev does a get latest (to get the latest plug-in code) and updates the plug-in, so that also the newest bits are transfered. After that you can begin by exporting the umanaged custs. on the central system.
About your worries about the unpacked solution:
To be honest I've not very much experience with it. I only use it in one project where only two devs are working on it.
The solution packer splits the customizations.xml file very granular (Diagram). So you will get a good knowledge about how the whole solution stuff is working and you can effective deal with the XML files. Also you can verify the repacked customizations.xml before importing with the xsd file in the SDK.
About deleting a field: As you may know this is not only a problem with this approach :) On the system you are doing this, its no problem but you will have troubles importing the solution in a system which has the old field. So you either uninstall the whole solution (which should be not a problem if you are not in production) or you have to use a workaround (

Thanks for your tip with fiddler. I'll give it a try.