Pausing a build to delay sign on a standalone machine

Question

For security reasons we are required to store the private keys that we use for our customer release builds on an isolated machine with no network access.  We have been using TFS Build to run our integration and daily builds successfully using a different public / private key pair, but have to find another approach for our customer builds.

All of our projects are delay signed, and what we would like to do is to pause the build so that we can copy the assemblies to be signed to CD.  They can be copied onto the standalone machine to be signed and copied back to the TFS build machine, before building our installers and running our Regression tests.

Being relatively new to TFS / MSBuild I do not know what the best approach should be.

If there was a way to get the build to pause when it is ready for the assemblies to be signed and then resumed afterwoods this would be ideal.  Otherwise I am happy that we create two seperate TFS builds ("Customer Release Part 1", and "Customer Release Part 2").

When trying the approach of having two seperate builds I have struggled with many issues, mostly source code control related.  For example I thought that it would be a good idea to share a local folder when getting the latest version of code.  However when I ty this the part 2 build complains that the local directory is already mapped to a workspace (even if I cloak part 2 folders in the part 1 build).

If anyone has tried to do anything similar, or has any suggestions I would love to know about them.  I am not necesarily trying to fix my current method, so if a better solution is out there I am more than willing to try it.  The only restriction is that the private release build keys cannot be placed on a network.

Answer 1

Hi

This is an interesting scenario.

Some initial random thoughts...

1. I don't recommend it, but you could implement a loooong sleep task that give you time to switch the assemblies.
2. I was going to suggest two builds, but you are spot on with the workspace issue.
3. Your installers will need to package assemblies, rather than 'Primary output', otherwise your signed assemblies will be overwritten.
4. I'm thinking that you can accomplish this with one build, run twice.
4a. On the second build you pass through a parameter say 'PackageBuild=true'.
4b You need to set SkipClean and SkipGet = true with a condition where 'PackageBuild=true'.
4c. You also need to override all the compilation etc in your build in a similar manor and only call targets where 'PackageBuild=true'.

The idea in 4, is that you do a build, sign your assemblies, then you Package the 'same' build.

I will try think of some other options.

Mike

Answer 2

Thank you for your response, I am trying out some of the ideas now (unfortunately with limitted success).

I agree that putting a long sleep in is a very bad idea.  As an alternative, one of my original ideas was to write some code that did some directory watching and continued when files had been replaced.  I felt this was only marginally better than a long sleep.

A varient of Idea 4 was the route we have taken for the last couple of months.  Our original idea was to customise they whole build process and override the <TeamBuildDependsOn> block to only build the installer.  This worked but is not very satisfactory with our implementation; it does not copy the binaries anywhere and always reports a failed build.

I like your idea of setting SkipClean and SkipGet.  I can't remember if I tried this previously so I have tired again this afternoon.  The first problem was that it broke the labelling as it could not find any source to label. This was fixed by setting <SkipLabel>.  My current problem now is that I get a similar error on the WorkspaceItemConverterTask (what ever this is [I have not yet had time to google for it]).

It complians with "There is no working folder mapping for $/.........".

I am beginning to wonder if I am going to stumble accross this issue for every TFS task.

To clarify I currently have two Team Build definitions:

Main - Customer Release Part 1
Main - Customer Release Part 2

They both have the same Source Control Folder and both point to "$(SourceDir)".
They are both using the same TFSBuild.proj file, using the condition " '$(BuildDefinition)' == 'Main - Customer Release Part 1' "

I have just come accross the following link which may or may not be what I require:

http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx

I particular it mentions how you can unmap the workspace - which was my original problem.

<Exec Command="&quot;$(TfCommand)&quot; workfold /unmap /workspace:$(WorkSpaceName) &quot;$(SolutionRoot)&quot;" WorkingDirectory="$(SolutionRoot)"/>

I will update with any progress.  Please let me know if you have any other ideas.

Answer 3

kmcmanus said:

For security reasons we are required to store the private keys that we use for our customer release builds on an isolated machine with no network access.  We have been using TFS Build to run our integration and daily builds successfully using a different public / private key pair, but have to find another approach for our customer builds.

Based on the above statement I was wondering if there wasn't some other way for you to secure your private keys that would be compatible with the build while meeting security requirements. 

I have worked with clients in a similar situation.  For them we put the private key into version control but secured it so that only Administrators and the Build Service account could do a Get on it.  That way the Team Build could pull it down and sign the assemblies but the developers couldn't.  We also deleted the key from the build machine in the AfterCompile target so that it wasn't hanging around.  Build Machines and Build scripts were also locked down to a small group of individuals.

Would that make sense in your situation?

- Steve

---

Development Process Consultant - Notion Solutions - http://sstjean.blogspot.com

Answer 4

Unfortuantely our security requirements are very clear.  There has to be an air gap between our keys and any networked system.  Our keys our not allowed onto a networked system even on a temporary basis, or placed on a CD that is left in the drive.

I have been called away on other work towards the end of last week.  I am hoping that I will find some time to continue this in the next 5 days.