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.
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
At the Root we have two workflows, one monitoring time (fires off every night) and one controlling the overall execution of the workflow.
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
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
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.
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.
Now that Team Explorer is setup we need to configure a workspace.
You can now manipulate the variables and connection settings used by this workflow to reflect your environment
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
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.
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