teamdeploy Forum Rss Feed

New Post: End to End Team Deploy Configuration Screencast

ianceicys — Wed, 16 Sep 2009 12:42:06 GMT

I've gone ahead and recorded a 1.5 hour screencast going through and demonstrating how to build out a virtual environment with Wix and Team Deploy deploying onto 2 target virtual machines.

This screencast includes all of the details that you could need for setting up team deploy including:

Setup of a domain controller & domain accounts
Installing Team Foundation Server 2008
Setting up Team Build
Setting up 2 target machines
Setting up a new team project
WIX 3.0 setup
Team Build Setup
Configuration of Team Build
Configuration of Team Build TFSBuild.Proj with Team Deploy.

This video is very thorough and a bit long but has everything you need to get started.

Check it out over at: http://www.noblegroupinternational.com/content/alm/teamdeploy/TeamDeploy.html

Don't forget to use the table of contents button (to the left of the sound button) in the controls at the bottom of the player.

Quick note the last 5 minutes of the video are the most exciting (step 120: Check-in changes to kick off CI-Build) because I demonstrate everything working together and doing multiple deploys on Continuous Integration builds.

Feedback is welcome.

New Post: RemoteExecute Task Issue

mikedouglas — Thu, 02 Jul 2009 13:53:55 GMT

This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.

New Post: RemoteExecute Task Issue

mikedouglas — Thu, 02 Jul 2009 13:53:29 GMT

Hi,

Thanks for letting me know about this. I didn't notice I did this. I tested it with my unit tests but it is spelled wrong there too. I'll get this updated and a create a sample for each for each of the tasks.

Thanks,

Mike

New Post: RemoteExecute Task Issue

Triggerwave — Thu, 02 Jul 2009 09:22:53 GMT

Just noticed the RemoteExecute task is actulally called RemoveExecute in both the source code and the published assembly.

Interestingly in the TeamDeploy.Tasks xml it is spelt correctly which makes me wonder how it ever worked.

Hopefully you'll be able to add an example of it working in the next release.

Thanx,

Michael McD.

New Post: SampleDeployScript.xml?

mikedouglas — Thu, 30 Apr 2009 17:01:06 GMT

Hi,

Thanks for bringing this to my attention. This is the correct file to use. I will add this to the binaries only download. If you have any questions or problems with it, please let me know.

Thanks,
Mike

New Post: SampleDeployScript.xml?

mikedouglas — Thu, 30 Apr 2009 16:58:07 GMT

This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.

New Post: SampleDeployScript.xml?

ianceicys — Thu, 30 Apr 2009 15:42:47 GMT

The installation doc mentions modifyig the SampleDeployScript.xml. I can't seem to find this file or figure out how to get an initial Build working using Team Deploy.

I found the file in the source code. Here it is below:

<?xml version="1.0" encoding="UTF-8"?>
<DeploymentScript>
	<DeploymentSteps>
		<KillProcess name="MyApp1.exe" />
		<KillProcess name="MyApp2.exe" />
		<MSI>			       
			<UninstallProductCode>{11111111-1111-1111-1111-111111111111}</UninstallProductCode>
			<MSIPathFile>\\myserver\Deployments\MyApp\MyApp 1.0.0\MyApp 1.0.0.msi</MSIPathFile>
			<OverrideDefaultArgs></OverrideDefaultArgs>
			<ExtraArgs>SETUPENV=SystemTest NGEN=True</ExtraArgs>
		</MSI>	
		<MSI>			       
			<UninstallProductCode>{22222222-2222-2222-2222-222222222222}</UninstallProductCode>
			<MSIPathFile>\\myserver\Deployments\MyApp\AnotherApp 1.0.0\AnotherApp 1.0.0.msi</MSIPathFile>
			<OverrideDefaultArgs></OverrideDefaultArgs>
			<ExtraArgs>SETUPENV=SystemTest NGEN=True</ExtraArgs>
		</MSI>

	</DeploymentSteps>
	<TargetMachines>
		<TargetMachine name="TestPC1" />
		<TargetMachine name="TestPC2" />
		<TargetMachine name="TestPC3" />
		<TargetMachine name="TestPC4" />
	</TargetMachines>
</DeploymentScript>

New Post: Continue using PS Tools or Custom Agent?

mikedouglas — Tue, 20 Jan 2009 05:24:31 GMT

I have been thinking about the pros and cons to using using PS tools with Team Deploy and whether Team Deploy should continue using PS Tools or if I should create a custom agent for Team Deploy to call.

The advantages of PS Tools are:

convenience
proven and accepted technology
No agents or other services to install on target machines

The disadvantages are:

Command line interface, not best for out of process communication.
Requires TFS Build user to be local admin on target machines
Not all companies want PS Tools being used in their environment.

If we create a custom agent, it would run as a service on target machines. This service would expose a WCF endpoint. Team Deploy would call each target via the endpoint. The agent would have the ability to kill processes and execute MSIs like PS tools would. The service would only need local system rights. The main disadvantage is that this service would need to be installed on the target machine before deploying.

I could go either way on this. I would like to hear from you as users of Team Deploy to help me determine which path to take. I could also do a combined option and have different tasks for PS tools and custom agents. This would allow the maximum flexibility.

Thanks,
Mike

NEW POST: Does this work with TFS 2005

jjgionta — Thu, 21 Feb 2008 05:44:20 GMT

Well I'm going to finally close out this discussion. I tried using your source to do remote installs and I continuously hit permission and network access problems when trying to install an MSI on a share.

The problem occurs when not providing a username and password with the psexec command. This in turn uses Implicit authentication which doesn't allow for access to network resources. There are ways around this such as passing the username and password (not acceptable especially because the password is in clear text) and setting the Active Directory to allow for delegation of the TFS Build Service account on the test servers (quite out of hand in a large scale organization or where users don't have access to AD).

I did end up finding a suitable workaround for my situation. It involves copying the MSI to the target machine and running the psexec on the local copy of the MSI and then copying any log files back to the share.

I don't know how your setup is getting around Implicit authentication and network access, but its hard to believe that other people using Team Deploy over a Kerberos enforced domain won't encounter problems using your current implementation of Team Deploy. I look forward to hearing other Team Deploy users input and experiences. Thanks for all of your help and consideration.

Jason

NEW POST: Does this work with TFS 2005

mikedouglas — Thu, 21 Feb 2008 04:13:57 GMT

I use this to deploy to test workstations. All of my clients are either virtual or physical pcs running Windows XP. We do have another team that is using this to deploy windows services to a Windows 2003 server.
Thanks,
Mike

jjgionta wrote:
Is your target machine a Windows 2000 Server?

mikedouglas wrote:
Jason,
No. I have used this where the share is on the build server and a different server. It didn't seem to matter.
Thanks,
Mike

jjgionta wrote:
Yup everyone has read and write permissions on my share. Quick question, is your share located on your target machine?

NEW POST: Does this work with TFS 2005

jjgionta — Wed, 20 Feb 2008 15:12:34 GMT

Is your target machine a Windows 2000 Server?

mikedouglas wrote:
Jason,
No. I have used this where the share is on the build server and a different server. It didn't seem to matter.
Thanks,
Mike

jjgionta wrote:
Yup everyone has read and write permissions on my share. Quick question, is your share located on your target machine?

NEW POST: Does this work with TFS 2005

mikedouglas — Wed, 13 Feb 2008 20:47:04 GMT

Jason,
No. I have used this where the share is on the build server and a different server. It didn't seem to matter.
Thanks,
Mike

jjgionta wrote:
Yup everyone has read and write permissions on my share. Quick question, is your share located on your target machine?

NEW POST: Does this work with TFS 2005

jjgionta — Wed, 13 Feb 2008 19:37:49 GMT

Yup everyone has read and write permissions on my share. Quick question, is your share located on your target machine?

NEW POST: Does this work with TFS 2005

mikedouglas — Wed, 13 Feb 2008 18:18:25 GMT

Jason,

It does work for me to use a share however, I don't have any restrictive permission on the share. It has "Everyone" with "Read" permissions. Have you tried a share with these permissions? I would think it would acceptable to have domain users with read only access. I'm not sure if would work or not if I change everyone to domain users. I'll try this too. We use advertised shortcuts where the MSI would try to repair itself if a file was missing. I haven't had to do anything else. My TFS build user is admin on the target machines but that is it. I'll review the install instructions and clean it up and add some more detail. I probably made some assumptions that everyone's environments are just like mine :)

Thanks,
Mike

jjgionta wrote:
Hi Mike,

So I guess my problem had to do with implicit logon versus explicit logon. As it turns out, if you don't specify a user and password through the option -u -p you don't have access to network resources. As a result, the psexec command had no access to the share. I also had to take the -s out because it was giving me access denied errors even though I was a system admin.

I didn't test TeamDeploy but I imagine that these type of problems would be presented if I did because essentially I'm running the same commands and environment (implicit). Were you able to install an MSI from a shared network location without specifying the options -u and -p? Also, other than making the TFS build service account admin on the targetmachine, is there any other settings that need to be set to get the -s option working? (Sorry your manual is a little hard to follow)

Thanks,

Jason

NEW POST: Does this work with TFS 2005

jjgionta — Wed, 13 Feb 2008 17:55:26 GMT

Hi Mike,

So I guess my problem had to do with implicit logon versus explicit logon. As it turns out, if you don't specify a user and password through the option -u -p you don't have access to network resources. As a result, the psexec command had no access to the share. I also had to take the -s out because it was giving me access denied errors even though I was a system admin.

I didn't test TeamDeploy but I imagine that these type of problems would be presented if I did because essentially I'm running the same commands and environment (implicit). Were you able to install an MSI from a shared network location without specifying the options -u and -p? Also, other than making the TFS build service account admin on the targetmachine, is there any other settings that need to be set to get the -s option working? (Sorry your manual is a little hard to follow)

Thanks,

Jason

NEW POST: Does this work with TFS 2005

mikedouglas — Wed, 13 Feb 2008 06:13:20 GMT

Jason,

I think this error is more to do with MSIExec then PSExec. If there are any spaces in the share path or msi filename, try removing those. Also try removing the PSExec from the command line and create a batch file to install it on the local machine. Also you could try removing the share and try to use a local path to a local machine. I fought a long time trying to get the sytax of the process.start + psexec + msiexec + args right, there could easily be some flaws in it.
Thanks,
Mike

jjgionta wrote:
In the end, the service account didn't have admin access. However, I'm on to a bigger problem that I believe is on the psexec side where the msiexec command cannot open the MSI on the share and get an error 1619. I tried the command from a prompt and I get the same error. I'm really stumped on this one. If you had any experience with this I would appreciate some advice. I'm going to post something over in the Pstools forum. Thanks again for your help.

NEW POST: Does this work with TFS 2005

jjgionta — Tue, 12 Feb 2008 16:38:01 GMT

In the end, the service account didn't have admin access. However, I'm on to a bigger problem that I believe is on the psexec side where the msiexec command cannot open the MSI on the share and get an error 1619. I tried the command from a prompt and I get the same error. I'm really stumped on this one. If you had any experience with this I would appreciate some advice. I'm going to post something over in the Pstools forum. Thanks again for your help.

NEW POST: Does this work with TFS 2005

mikedouglas — Mon, 11 Feb 2008 19:40:52 GMT

Jason,

Would you check to verify that the user you are logged in the server with running the command manually is the same as the user that is doing the build? The Service is either called "Visual Studio Team Foundation Build" or "Team Build Service"? Also just to make sure, you are running the command manually from the same machine with TFS installed? Sorry these are not much of an answer. I'll keeping checking a few things to see if I can find a better answer.

Thanks for the option for accepting the eula. I'll get this incorporated into the next build.

Thanks,
Mike

jjgionta wrote:
Hi Mike,

This helped things a little bit. I actually didn't some searching and founded an option for the pstools commands that allows users to acccept the EULA when calling the command. This might be something to look into for team delpoy. The option is -accepteula. I am still having access denied issues. Strange thing is that I run it from a command prompt and the command works fine. When I run the same command in team build I get an access denied error. I am running both commands witht he same account. Any ideas?

Thanks,

Jason

NEW POST: Does this work with TFS 2005

jjgionta — Mon, 11 Feb 2008 16:01:16 GMT

Hi Mike,

This helped things a little bit. I actually didn't some searching and founded an option for the pstools commands that allows users to acccept the EULA when calling the command. This might be something to look into for team delpoy. The option is -accepteula. I am still having access denied issues. Strange thing is that I run it from a command prompt and the command works fine. When I run the same command in team build I get an access denied error. I am running both commands witht he same account. Any ideas?

Thanks,

Jason

NEW POST: Does this work with TFS 2005

mikedouglas — Fri, 08 Feb 2008 03:33:57 GMT

Hi,
Yes it does work with both TFS 2005 and 2008. I actually developed it against TFS 2005 and then tested it with TFS 2008. I think what might be happening is that the PS Tools require you to accept an EULA the first time you use it. Try calling the the PSEXEC and PSKILL manually in a command window. This should then allow you to use it from the build. I forgot I had to do this the first time.

Let me know if this fixes it.

Thanks,
Mike

jjgionta wrote:
I have tried to adapt the procedure into TFS Build 2005 and everytime I execute a build, it hangs. Does Team Deploy only word with TFS 2008?