Deployment Plans

[Guest]

I am currently using the Enterprise trial and from the looks of it, we are going to purchase this as it allows all the functionality we need. There were some sticky points, and this question is the prime: We followed the online excercise for generating a TFS build and, unlike the article, it was not as automated as I expected. This was no problem; I simply created the steps for:

• Create TFS Build
• Create Artifact from TFS Build Output
• Stop Application Pool
• Deploy <Build-name> Artifact
• Start Application Pool

This works, and is deployed to the Dev IIS because the Dev IIS was configured to follow the conventions of the Build Artifact and deploy location /_PublishedWebsites/ - In TFS we have a Team Project which has multiple solutions under it, and there is a builder for each of the solutions independently.

Now, normally I can manage the deployment output on my own through TFS in various manners (CopyDirectory step, modifying the build process itself, etc.) but I don't want to do this, I want to leverage BuildMaster to do this, but I was confused as to the best practice for this. On the web application Server we have:

(generalized)
\WebRoot\<projectgroup>\<websolution>\

For each project, so the _PublishedWebsites is usually avoided by a manual or build step to copy the subdirectory to the Projectgroup folder. What is the most automated (least input) way to create a deployment plan step for this. So far it looks like "Transfer/Synchronize Files" is the only solution. So from a simplified view:

• Stop Application Pool
• Transfer/Synchronize Files
• Deploy Configuration File
• Start Application Pool

Is this the best way? If so, are there variables that can be used to ease the copy and prevent continuous type-itis?

Product: BuildMaster
Version: 4.8.3

[Guest]

The easiest way is to ensure that the "Create Artifact from TFS Build Output" action group captures the website output from the /<projectName>/_PublishedWebsites directory into an artifact named Website (or whatever you want it to be named), then in any future step, you can use the Deploy Build Artifact action to deploy the Website artifact to any directory/share you choose on any server connected with BuildMaster. This way, for your dev plan, you can set the target directory to /_PublishedWebsites/ directly, and for your later environments the actual path, i.e. E:\WebRoot\<projectName>\.... Note that the Deploy Build Artifact action will automatically determine which files need to be copied from the source and removed from the target similar to rsync or robocopy, minimizing deployment time. If you use the Deploy Configuration File action, you'll have to add one of those just after the Deploy Build Artifact action as well to ensure those servers have the correct configuration files deployed, since those will obviously not be stored within the artifacts as they are environment dependent.

Once you're comfortable with hardcoding the target path, you can start to generalize, i.e. change <projectName> in the example to use the $ApplicationName or $DeployableName variables from BuildMaster, then you could share the deployment plans among common applications when you come up with application name or deployable name conventions.

[Guest]

Please pardon my ignorance. I know that there are probably multiple ways to handle this, and I'm not sure what is the right way or best way to accomplish this.

So, I'm following what you are putting down to some extent, the only point that is fuzzy is your comment:

"Create Artifact from TFS Build Output" action group captures the website output from the /<projectName>/_PublishedWebsites directory into an artifact named Website

I was a bit confused about your statement as "Create Artifact from TFS Build Output" is a specific Action, not Action Group. I assume you are saying that the Action Group which includes the "Create Artifact from TFS Build" should also have additional Actions to create a website artifact?

I think based on my reading of your message, I should create a second website artifact after Deploy (when I know the path, since I don't know the TFS drop path). So is this more in line with what you are saying?

<snip pre-steps>

Create Initial Build

1. Create TFS Build
2. Create Artifact from TFS Build Output

Deploy Initial

1. Shutdown Application Pool
2. Deploy <tfs artifact> Build Artifact (to e:\path\here)
3. Create Website Artifact (from e:\path\here_publishedwebsites$ApplicationName
   <todo:deploy config>
4. Start Application Pool

<snip post-steps>

I think that should work, and if I wanted DEV layout (configs for IIS) to match the TEST and PROD I should simply add an additional initial step to the above to push the Website Artifact to "E:\Webroot...etc." on Dev, and then the Test and Prod Deployment plans should all interact on that Website artifact instead of the original TFS artifact. Yes?

[Guest]

Yes, you've got it... apparently better than I do :)

I forgot the part where you have to deploy the artifact to some directory (i.e. a blank target directory which defaults to $CurrentDirectory) then capture just the /<projectName>/_PublishedWebsites part in another artifact via the Create Build Artifact action since that's what would be deployed in future environments.

The best solution of course would be to modify the "Create Artifact from TFS Build Output" action to capture from a subdirectory or from some form of mask input, but that particular feature isn't part of that extension right now (scheduled as a general item for v5.0) and it's simple enough now to just perform the intermediate capturing.

[Guest]

For all lookers, answer chain above resolves the question

Awesome, thanks for the great support. I'll look forward to the Extension, in the meantime I think I have enough going now to generalize for the rest of our environment. Thanks for the assistance, and as I mentioned -- the product so far is excellent and we will definitely be purchasing the Enterprise as soon as I get quotes back! ;-)

Cheers!