Custom Workflow Activities v.s. PowerShell Cmdlets for Build Templates

Topics: Build Template
Sep 4, 2014 at 6:50 PM
What do you think is a better approach.

1- Create a library of custom workflow activities and use these to create a build template
2- Create only PowerShell Cmdlets that can be composed to create a PowerShell script that then can be invoked from a Build definition?
3- Any other combinations or options?
Sep 4, 2014 at 7:01 PM
My main design principals for build templates.
  1. Should be re-usable across different Dynamics CRM projects (i.e. I don't want a build template for each project or scenario)
  2. Should be extensible to meet specific project needs
  3. Should be easy to maintain and debug.
At some point the custom build template for Dynamics CRM CI Framework was purely created using custom workflow activities. This ended up in a very long workflow that was difficult to keep track off and maintain. It was also difficult to debug. It was a good idea at the time as PowerShell extensions were not provided out of the box with the default TFS template.

Looking at the recent default TFS templates provided with TFS > 2012. They seem to be providing extensions via executing PowerShell scripts. Also PowerShell scripts are much easier to put together, debug, test and maintain that a workflow built using windows workflow foundation.

Also this way I don't have to maintain both custom activities and cmdlets.

Each dynamics CRM project has unique requirements which I think can be met can easily extending the build with PowerShell.

Having these features in PowerShell as well allows you to take advantage of these in other Builds systems like Team City and Sake.

Appreciate any thoughts on this.
Sep 4, 2014 at 7:54 PM
Edited Sep 4, 2014 at 8:30 PM
Activities which are based on the WF can be reused in any workflow.
For example, I can include them in my XAML workflow which is executed in my console host or I can also host them in CRM. A less exotic sample: it’s also possible to use them VS Release and TFS Build Job Definition Template.

Build job definition template:
For using the activities as a part of the build job we need to host them in a Build Job Definition Template.
Once I've one definition template I can configure it (The resulting build job definition) without a check-in and over an UI. That’s a great feature.
Build job templates can also be customized and I think we just should provide a very generic one.

Pendent to the activities.
Cmdlets are really powerful. Also none programmers can use them and write scripts.
I can run them on every system by just providing a small set of assemblies and the script.
That’s really cool because sometimes I just want to build up an org with all solutions for development - there will be no build definition for that and consequently, no build job which can do this for me. But if I've a Script I can just run it locally.
If you think out of the (CI) box: I can easily scripting recurring actions e.g. in testing.

PowerShell Script:
Pendent to build job definition template.
In my view we should just provide very basic scripts for CI but a lot of samples.

At the End, from my point of view we should consider that all functionality (which makes sense of course) is provided by activities and also Cmdlets.
If they share the logic it should be not too much work.
Sep 6, 2014 at 6:44 PM

Glad to see some discussion going on this.

Some comments on the above:

Even though activities are activities, CRM and TFS runs their own workflow runtimes which require activities to be tagged with different attributes and the context for is very different. So sharing activities between TFS and CRM is not very practical. Also there will be a very small set of activities that can be useful in both.

By the way Release Management templates might looks like a windows workflow foundation workflows that you can add activities to them! I though the same. But you can only drag components into the workflow which wrap powershell scripts and exe files but not workflow activities.

Build Templates
Yes activity are very useful in Build Templates when you want to customise. However having experience in writing build templates for some time you really have to build a complex workflow for very simple things that is difficult to debug and maintain. This can be useful in scenario where the workflow activity encapsulates and abstracts a lot of functionality. For example you can just drop one activity to run stylecop. Even MS moved to write these type of activities. If you like at the different between TFS 2010 and 2013 templates. The 2013 template is much simpler. MS are encouraging people to write extensions using powershell scripts that can be ran during the build. But if you have a complex workflow for example that requires parallel executions and workflow type build, the customization the build template with activities and powershell will be the way to go.

Agreed. A good example is an import script that you can run locally to import a solution to your sandbox. You can fire the same script from your build definition to deploy to stage and you can use the same to fire it off using release management.

I would not think of PowerShell scripts as build templates. PowerShell scripts can be invoked from build definitions in TFS or other build systems such as Team City.
I completely agree that having a lot of sample will be great and users can then use their where they want.
Marked as answer by msallin on 9/11/2014 at 1:33 AM
Sep 9, 2014 at 10:12 AM
Hello Wael,

Thanks for your replay.
"[...] MS are encouraging people to write extensions using powershell scripts that can be ran during the build. [...]"
This is argument enough to decide to use PowerShell.

Do you agree to close the (my) issues about creating activities and go forward with the cmdlets?
Sep 9, 2014 at 7:18 PM
Hi Marc,

One scenario where activity are helpful if if you want to return any outputs that can later be consumed by further activities. You are not able to do so in PowerShell easily. But so far I got away with it by just using PowerShell and OOB activities.

Anyway the activity project is there. If we find a scenario that really needs an activity in the future we can add it in there. For now I would close all the activity user stories.

Thanks for the interesting discussion on this :)