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
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
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.
We found that leveraging
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.
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,