I happen to participate in an agile workshop where some automated build tools were discussed ,visual build was one of them. I liked the idea of visually constructing the project build instead of using batch files or VS IDE build actions that are hard to execute or to maintain. In "visual build" you simply visually drag and drop activity blocks from a tool box to construct the build process. I wanted have my own "Visual Build Designer" , and it was very obvious that I can utilize Windows Workflow to do that.
My basic required activity blocks were:
Another requirement was that the process builder (the actual person that drags and drops the activity blocks) would not have to write a single line of code. He would have to set in the activity blocks properties of course , but he wouldn't actually need to add additional c#/vb.net to support the basic functionality.
So the first step was to read about writing customized activities . This was a good resource to start.
The second step was to read about extracting code from VSTF source control. Here is a good place to start.
Next step was to write the customized activities.
I wrote three customized activities
here is how (in short) the GetCode.cs imports the source control
String tfsName = TFSServer;
TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(tfsName);
VersionControlServer versionControl = (VersionControlServer)tfs.GetService(typeof(VersionControlServer));
Workspace workspace = null;
workspace = versionControl.CreateWorkspace(WORKSPACENAME, versionControl.AuthenticatedUser);
WorkingFolder myworkingfolder = new WorkingFolder(TFSArea, SCPath);
The TFSServer,tfsName and SCPath are activity properties which are defined as so in the code
public static DependencyProperty SCPathProperty = DependencyProperty.Register
("SCPath", typeof(string), typeof(GetCode));
[Description("The local folder to get the code")]
public string SCPath
and that makes them visible in the designer like so
So here are the properties of all of the components
- GetCode - VSTF Server, Source Control area path, and the path to dump the files into
- MSBuilder - MSBuilde exe path, Project path and Project file name
- Mailer - To, Subject, Body , SMTPHost
Now all that's left is to open a new workflow project, add these activities to the tool box , drag them into the designer window and finally bind the properties of the activities.
The binding are as follows:
- The msbuilder ProjectPath property is binded to the getCode SCPath property, which means that the msbuilder looks at the same directory where the source controller brought the code to.
- The Mailer branch is binded to the the MSbuilder BuildResult property , if the build succeeded than the BuildResult Property would be set to true and the successful branch would be taken and vice versa.
- The mailer Body Property is binded to the MSBuild BuildOutput property which means that the emails body contents would actually be the output of the MSBuild process.
All of the other properties (such as TO, SMTPHost , subject , etc) would be have to be set by the process builder (the person using it)
That's basically it, all that's left to do is to run the process and wait for the result email.
Build Failed Email
Build Success Email
Next steps would be to to add more build related activities such as publish(some kind of xcopy), ftp , package, etc.
Which I hope to accomplish soon.
Any Feedbacks ? Can you think of other build related activities that would be valuable ?