Automating the Export and TFS Check-In of Workflows

For disaster recovery reasons in Orchestrator it is beneficial to have backups of individual Workflows.  In order to facilitate this and not increase the amount of manual work that has to be done we have come up with a workflow that leverages the COM interface of the Orchestrator Management Service (wrapped up into an integration pack http://scorch.codeplex.com/releases/view/92063) and the excellent TFS integration pack from Yao (http://orchestrator.codeplex.com/releases/view/86333). 

The workflow points at a base folder (our Development folder) and will enumerate all of the child folders.  In our environment each child folder related to one self contained workflow (or conglomeration of Runbooks to accomplish a larger task).  The workflow then will do an export of each workflow individually and remove all un-referenced global settings (variables, computer groups and schedules) and all un-referenced global configurations.  The final export file is named the same thing as the folder was named.  We then take each exported workflow and check it into TFS.  Because export files are just XML files this allows us to use the compare functionality inside of TFS to understand what has changed between versions.  Because we now have this fully automated we are able to run these workflows on each of our development environments nightly.  This means that if a developer ever needs to ‘rollback’ a change on their development workflow we can now accommodate that request in a very timely manner.  So, lets take a look at how it works

The End State

At the end of the day what we want is a TFS project that contains all of our development environments and backups / daily check ins of the workflows being developed in the said development environment.

SNAGHTML1111a00

image

The Workflow

The backup workflow is actually a pretty simple and straight forward workflow.  It has two portions, one for the Export of workflows and one for the import of the exports into TFS

image

At the Root we have two workflows, one monitoring time (fires off every night) and one controlling the overall execution of the workflow.

image

image

The Export step is comprised of a main workflow and a control workflow.  The control workflow is used to allow us to do exports in parallel (and is pictured below).  The idea is that we start a counter off at 0 then increment it for each subfolder under our development folder.  We then export each subfolder by calling the main export workflow without wait for completed checked (this allows us to queue them all up and run in parallel).  The main export workflow will decrement the counter by 1 after it successfully exports a workflow.  The control workflow then waits for all of the export workflows to complete

image

image

image

The Main export workflow is configured to run up to 5 exports in parallel and simply exports the workflows (including removal of non-referenced global configurations / settings) and decrements the counter

image

image

On the TFS workflow we update the workspace (get any changes made in any other environments incase this environment got out of date), then check for all export files from the export workflow.  For each export file we then look in our workspace to see if this is a new export or if it is just a new version (our TFS actions are a bit different if it is new or just an update).  We then move the file to our workspace and check it into TFS.

image

Prerequisite configuration

The workflow requires two integration packs

Orchestrator Administration: http://scorch.codeplex.com/releases/view/92063

Team Foundation Server: http://orchestrator.codeplex.com/releases/view/86333

TFS IP Configuration / Setup

Currently (8/6/2012) the TFS integration pack at http://orchestrator.codeplex.com/releases/view/86333 has a bug that breaks check-in functionality.  Yao has been nice enough to supply a temporary hotfix to this.  After you have installed the integration pack onto your runbook server simply go to the C:\Program Files (x86)\Common Files\Microsoft System Center 2012\Orchestrator\Extensions\Support\Integration Toolkit\4e5fdf96-9cad-4233-8607-400288353bb6 folder and replace the two binaries there with the binaries available at TeamFoundationServerIntegrationPack.zip.  Once Yao is able to update the central TFS project this section will be removed.

Once the TFS integration pack is installed there is some post configuration that you will need to do, namely install Visual Studio Team Explorer 2010 or the binaries.

image

image

image

image

Now that Team Explorer is setup we need to configure a workspace.

image

image

image

SNAGHTML14df2ae4

SNAGHTML14e06a97

image

SNAGHTML14e3d960

SNAGHTML14e38063

 

SNAGHTML14e2a5a3

 

SNAGHTML14e53bee

SNAGHTMLd877f4

SNAGHTML10b15a8

Workflow Configuration

You can now manipulate the variables and connection settings used by this workflow to reflect your environment

Connection Settings

There are two connection settings you will need to configure for the workflow, one for TFS connection and one for the connection to your Orchestrator environment

 

image

SNAGHTMLdc76c8

image

SNAGHTMLdced01

 

Variables

There are a number of variables used by this workflow to control where export files are stored, what your TFS workspace root is ect, you can find all of these under the ‘Central – Nightly Development Backup’ Folder.

image

 

SNAGHTMLdf09b7

 

The Export Files

This workflow is available as a proof of concept / use at your own risk at http://scorch.codeplex.com/releases/view/92311

Advertisements
Tagged with: , , , , , ,
Posted in General Information, Infrastructure, Workflow
13 comments on “Automating the Export and TFS Check-In of Workflows
  1. […] Given these considerations we have internal policies that say we will turn on logging (Object Specific) in our central QA environment and turn it off in our Central Production environments to maximize performance. We do two things to make sure we have logging turned on in development environment exports and turned off from QA environments. We do this by changing the logging flags on our nightly backup jobs (discussed at https://opalis.wordpress.com/2012/08/06/automating-the-export-and-tfs-check-in-of-workflows/) […]

  2. luxspes says:

    How about the opposite? Being able to for example take a particular “labeled” version and import it to orchestrator from TFS in an automated way ¿can it be done?

  3. Mike says:

    We too are trying to find a tool that will help us take our export and propagate it through our different dev and test environments. Does anyone have anything that will from a command line perform a global import?

    • randorfer says:

      Hey Mike,

      This is something we spend a large amount of time trying to correctly impolement back when Robert Hearn was working for MS on the Orchestrator PG. The closest we came was a script that could import a single export into a fresh Orchestrator environment. There is some code to this effect on the scorch.codeplex.com project under orchestrator administration. If you’d like to resurect this project please feel free to do so, we are in a similar situation with 8 dev environments, 2 qa and 2 production. Change control is…interesting. If you’d like to chat let me know and we can set something up. Otherwise, my suggestion would be to wait and look at implementing Service Management Automation in October when R2 GA hits. This is a new automation engine built on PowerShell workflow from the Orchestrator team that is released with the Windows Azure Pack in the 2012 R2 wave. The Orchestrator team has taken most of our feedback about limitations with the Orchestrator product and solved them in this new endeavor (automated export / import, true load balancing, stable web service, checkpointing of workflows so we can do maintenance on workers etc.).

      -Ryan

  4. Mark M. says:

    I tried this project out and everything works except for the Check In New Export step in the Step 2: TFS Workflow Check-in runbook. I get the following error:
    The array must contain at least one element.
    Parameter name: checkinParameters.PendingChanges

    Exception: ArgumentException
    Target site: TFCommonUtil.CheckArrayForNullOrEmpty

    Stack trace:
    at Microsoft.TeamFoundation.Common.TFCommonUtil.CheckArrayForNullOrEmpty(Object[] array, String arrayName)
    at Microsoft.TeamFoundation.VersionControl.Client.WorkspaceCheckInParameters.Validate()
    at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckInInternal(WorkspaceCheckInParameters parameters)
    at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn(WorkspaceCheckInParameters checkinParameters)
    at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn(PendingChange[] changes, String comment)
    at TeamFoundationServerIntegrationPack.VersionControlHelper.Checkin(String workspacePath, String localFilePath, String recursion, String comment) in C:\CodePlex\orchestrator\IntegrationPacks\OITv7\TeamFoundationServerIntegrationPack\VersionControlHelper.cs:line 224
    at TeamFoundationServerIntegrationPack.CheckIn.Execute(IActivityRequest request, IActivityResponse response) in C:\CodePlex\orchestrator\IntegrationPacks\OITv7\TeamFoundationServerIntegrationPack\Activities\CheckIn.cs:line 60

    I ensured that I had the updated TFS IP, but still having problems with the add part of the runbook.

  5. chris temple says:

    Does anyone have some more documentation or information on how the global variables map to each piece of the puzzle? For example, What is Environment Name? Development Folder? Why are there two path variables? Is the source code for the OIP’s available on CodePlex?

  6. Phil says:

    Few questions and please excuse my frustration from spending days scouring the internet and diverting my developers to try and decipher the IP code. We’ve thrown RedGate at the Orchestrator DB to see if we can find some parallels there too. This is such a key workflow and there isn’t much documentation anywhere that Google can find that explains the values needed to get SCORCH Admin IP to work.

    1. Installing the most recent Admin IP, it says v2.3 in the Deployment Manager, but 2.3 isn’t listed in the rel notes. Does this version include the separate/patched .dll files?

    2. What are the values are that are in the “Development Folder” variable (Policies\Development) or the “Target Folder Path” in the Get Subfolders Activity (Policies\FolderName\SubFolder)? We have no idea what structure these values are referring to or what values will get the “Get Subfolders” activity to work. A practical example would be worth it’s weight in gold.

    Error:
    Object reference not set to an instance of an object.

    Exception: NullReferenceException
    Target site: GetSubFolders.Execute

    Stack trace:
    at Orchestrator.Administration.IntegrationPack.Activities.GetSubFolders.Execute(IActivityRequest request, IActivityResponse response) in c:\Projects\TFS\scorch\Orchestrator.Administration\Orchestrator.Administration.IntegrationPack\Activities\GetSubFolders.cs:line 40

    3. We use VS 2013 and our screens are very different than the ones above. What value is supposed to go in the “Environment Name” variable? Is that the Workspace?

    Thank you to anyone who can help get over this hump.

    • Phil says:

      Ok, got it to work. Here’s all the English you’ll need. This stuff may be known to the Guru’s, but the noobs will be totally lost.

      1. Import the Admin IP (2.3) and sample runbook just as they are. Don’t touch a thing until you get the export working. Change variables, runbook names… to your standards after you get it running and figure out all the nuances of what’s been built.

      2. The big secret. The Development Folder variable that references Policies\BlahBlahBlah is the alias (or proper SCORCH name) for the root folder that we see as the word “Runbooks” under your server in the Runbook Designer. The following post mentions that the IP can’t work off the root folder (Policies), so you need to apply some best practices and make a layer between the root and your runbooks. I used Development, Test, Main to parallel how we track in TFS. Now you have Policies\Development, Policies\Test, Policies\Main to work with.

      Other variables:
      Environment Name = the local VS Workspace you created for this.
      Export Folder = create a folder to allow the IP to simply dump the .ois_export files before moving them into your local workspace. I was able to use UNC paths to reference the drive so drive mapping doesn’t bite elsewhere.
      TFS Workspace Root = The root folder for the local workspace for this project. The pictures/instructions above are spot on.
      TFS Workspace Relative Workflow Path = The folder you were directed to create in the above instructions.

      3. NEXT personal problem. We’re using VS 2013 / TFS 2013 and the TFS IP is looking for VS 2010. I’m gonna have my engineers look and see if they can quickly update the TFS IP to point to the VS 2013 versions and rebuild the IP.

      Could not load file or assembly ‘Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.

      Exception: FileNotFoundException
      Target site: VersionControlHelper..ctor

      Stack trace:
      at TeamFoundationServerIntegrationPack.VersionControlHelper..ctor(String url, String domain, String userName, String password, Boolean handleEvents)
      at TeamFoundationServerIntegrationPack.UpdateWorkspace.Execute(IActivityRequest request, IActivityResponse response) in C:\CodePlex\orchestrator\IntegrationPacks\OITv7\TeamFoundationServerIntegrationPack\Activities\UpdateWorkspace.cs:line 47

      • Phil says:

        After a night of sleep, the simple solution hit me. I uninstalled VS 2013 and put in VS Team Explorer 2010 on the SCORCH app server – just as it says above… Duh. Now the runbooks work and I’m figuring out where things break or don’t. We still use TFS 2013, but VS 2010 seems to be happy with it at first glance.

      • Phil says:

        Duh – Here’s the documentation on the TFS IP. My lord pulling this knowledge together has been a ride. THANK YOU to those that built this stuff.

        https://orchestrator.codeplex.com/wikipage?title=Integration%20Pack%20for%20Microsoft%20Team%20Foundation%20Server%202010&referringTitle=Documentation

      • Phil says:

        Having trouble with new .ois_export files (folders). Once I manually checked in a file, the IP handled updates to TFS no problem. It just won’t check in a new file on its own. Still digging.

        The array must contain at least one element.
        Parameter name: checkinParameters.PendingChanges

        Exception: ArgumentException
        Target site: TFCommonUtil.CheckArrayForNullOrEmpty

        Stack trace:
        at Microsoft.TeamFoundation.Common.TFCommonUtil.CheckArrayForNullOrEmpty(Object[] array, String arrayName)
        at Microsoft.TeamFoundation.VersionControl.Client.WorkspaceCheckInParameters.Validate()
        at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckInInternal(WorkspaceCheckInParameters parameters)
        at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn(WorkspaceCheckInParameters checkinParameters)
        at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn(PendingChange[] changes, String comment)
        at TeamFoundationServerIntegrationPack.VersionControlHelper.Checkin(String workspacePath, String localFilePath, String recursion, String comment) in C:\CodePlex\orchestrator\IntegrationPacks\OITv7\TeamFoundationServerIntegrationPack\VersionControlHelper.cs:line 224
        at TeamFoundationServerIntegrationPack.CheckIn.Execute(IActivityRequest request, IActivityResponse response) in C:\CodePlex\orchestrator\IntegrationPacks\OITv7\TeamFoundationServerIntegrationPack\Activities\CheckIn.cs:line 60

      • Phil says:

        Hit a wall for the day. I can get the Step 2 runbook to check in new files in the Runbook Tester, but it won’t do it in the full process. First thought is the old runbook runs as logged in user thing. So I logged into the app server with the SCORCH service account so the runbook is using the same user as the service. The runbook tester still checks in new files fine but the full job won’t. Same error as previous post.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: