For anyone doing extensive CRM Customizations or product development there will undoubtedly come a point when you will want to implement continuous integration as a best practice. Continuous Integration (as defined by Wikipedia) is: “the practice, in software engineering, of merging all developer workspaces with a shared mainline several times a day.” It also typically includes the running of automated unit and regression tests. What I hope to explain in this article are the pros and cons of the initial approach Rockton Software www.rocktonsoftware.com took in automating this process.
Head in the Clouds
We decided early on that we would need a simple and easy way to set up an infrastructure for our build automation and deployment that was both cost effective and gave us complete control. Knowing that long term we would be leveraging both Amazon Web Services and Windows Azure we chose AWS as our entry point since it had a slightly lower learning curve to address. Since our development is based on Visual Studio and we have our source code readily available in a hosted TFS environment we decided that Team Foundation Build would meet our needs and we began our work breakdown structure (WBS) of the individual components we would need to build.
Time to Build
We, here at Rockton Software, first created our Build Server by launching an AWS instance and installing the Team Foundation Build Service (this process is fairly well documented elsewhere so I won’t go into detail here). We provisioned additional AWS Instances for CRM, SSAS and a standalone IIS Web Server. Using the cloud for this involved nothing more than launching a vanilla machine instance and installing the various software components required on each machine (the same as you would do if you owned the hardware).
Once our server setups were complete, we added a new Console Application Project to each of our existing solutions. For consistency, each of these applications were named BuildProject and they contained our Build Process Templates (see below), any CRM solution exports, as well as sample data. The key thing to understand when using TFBuild is how to create your own custom Build Activities since that is where the true extensibility lies. Having our WBS in hand we were able to determine what custom activities we would need to develop. We created a solution containing the 4 class library projects:
The purpose of each solution is as follows:
AWSActivityLibrary – Provides functionality for interacting with Amazon Web Services. Our nightly build will destroy the running EC2 instance that is our CRM Server, launch a new instance and when the build is complete create a new Base AMI image for the developers to leverage as their development environment.
CRMActivityLibrary – Provides functionality for interacting with CRM. For this initial approach we had static CRM Solution Exports that we would import, activate our plugin steps (since they come in as disabled by default) and publish our changes. Once everything was published we would then import our sample data which in turn would fire any plugins we had developed to that point.
EmailActivityLibrary – Provides ability to send emails when the build completes successfully or an exception occurs.
SQLActivityLibrary – Provides ability to execute SQL Scripts and Stored Procedures. We leverage this functionality for configuring our SSAS Server.
A simple custom BuildActivity
A custom build activity is nothing more than a decorated class file. These activities can be thought of as the internal “HOW” a build will work. After adding a reference to Microsoft.TeamFoundation.Build.Client you can create a class that inherits from CodeActivity and is decorated with the BuildActivity attribute. Here is an extremely simple example that will Publish CRM Changes:
**Every activity will include your input parameters and a main Execute method.
Build Process Templates
Team Foundation Build uses a Build Process Template to control logic flow and the “WHAT” the build will do. If you are familiar with using workflows or creating xaml files you will be comfortable with these templates. Your custom activities that you create will show up in the toolbox alongside the out of the box activities and you just drag and drop them onto the workflow surface. Also, any properties that you define in the activity will display in the properties window. Below are the properties from our PublishChanges example:
Putting It All Together
From Team Explorer you can now right click the Builds node in your solution you would like to deploy and select New Build Definition. This will allow you to setup the “WHEN” of your build. You have the ability with TFBuild to trigger your build on a schedule as well as each time code is checked in. You will most likely define two builds for each solution: one that runs nightly and does a full deploy and one that runs on each checkin and only does a compile to ensure nothing is checked in that will break the build. It is also in this build definition that you will specify your folder paths in TFS for code checkout and also the Build Process Template that you would like to use.
Pluses
We found that leveraging Amazon Web Services with Team Foundation Build was not extremely difficult to get in place however it can be time consuming. Reliability was solid and our builds fired consistently every night at their specified times. The compile on check-in was also helpful in pointing out things such as missing references immediately rather than discovering it days later. The ability to have a complete environment to deploy to without any hardware expenditure was beneficial and we could completely recreate this environment every night and have a fully functional CRM deployment with customizations and sample data each morning that our QA and Product Owners could evaluate.
and Deltas
This initial approach got us a good start towards our ultimate goal of continuous integration and being able to deploy on a regular schedule without any effort. However, we still found some shortcomings in this approach. The use of static CRM Solution exports was not very effective since it required each developer to checkout and replace the zip file with their changes and so it was never completely current with the source in TFS. We created a new Base AMI Amazon image when the build process was complete, so our developers could launch their own instance at the start of an iteration and have a fully configured environment to use for development. However, using AWS Instances for development was not very cost effective (since you are paying for each running instance), and the performance time for the build/deploy/test cycle was increasingly becoming a problem.
Coming Soon
In Part II of this topic, we will discuss our most recent approach of leveraging PowerShell scripting, Windows Azure and Hyper-V to remove some of the drawbacks we encountered above.
Written By Shawn Strayer, Web Developer at Rockton Software, Microsoft Dynamics Add-On Partner.
Deploying CRM Customizations Part 1: Team Foundation Build with Static Solution Exports is a post from: CRM Software Blog
Related posts:
The Microsoft Platform – A Solid Foundation For CRM
Why CRM is a Great Platform to Build On
Microsoft Dynamics CRM’s ABCs: Activities Build Cash