Is this project still alive?

Jul 12, 2013 at 7:24 AM
Hi,

I noticed the latest release is from June 2012 and that there are not further releases planned.
Has this project died or has it matured and is it thus stable to use in DTAP?

Regards,

Kris
Jul 12, 2013 at 12:53 PM
I don't know what DTAP is. I see little activity on this project but I will say that I've been using it for a few years now and recently upgraded to TFS 2012 and it still works fine.

I wish MS would take over this and make it's functionality officially supported because it's an important enterprise piece. Or better yet, have it taken over by a vendor that will develop it further and support it.
Jul 12, 2013 at 5:00 PM
I support tbeaulieu in his statements. Although the code base has not changed much, it has enough functionality in it to be very useful and designed well enough that changes are not necessary. I would recoment adding issues for features that you may need, or event take a stab at extending it for your purposes and sharing your work.

Thanks
Coordinator
Jul 15, 2013 at 12:09 AM
Hi all,

TFS Deployer was recently updated to support TFS 2012 on-premises instances and is being used reliably in a number of Production scenarios.

I personally do not intend to continue to support TFS Deployer any further unless critical bugs are discovered in the current version.

For many years TFS Deployer filled a niche that had very few alternatives. In recent months, automated deployment has received much more attention in the industry and we are seeing several new products enter the market that I believe can provide a better experience than TFS Deployer could, even if I had more time to develop it.

Alternatives to consider moving to:
If you're looking to move to TFS 2013 or the Microsoft-hosted Team Foundation Service, plan to move away from TFS Deployer.

However, TFS Deployer is open source, others are welcome to continue supporting it.

Regards,

Jason
Feb 14, 2014 at 4:02 PM
Hi Jason,

Does it mean that TFSDeployer doesn't support TFS2013 at all? We've moved to TFS2013 and TFSDeployer is throwing this following exceptions on the web server where TfsDeployer was installed:

Microsoft.TeamFoundation.VersionControl.Client.ItemNotMappedException: There is no working folder mapping for C:\Windows\system32#\1\BuildProcessTemplates\TfvcTemplate\Deployment\DeploymentMappings.xml.
at Microsoft.TeamFoundation.VersionControl.Client.Client.GetLocalWorkspace(String localPath, Boolean throwIfNotFound)
at Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer.DetermineWorkspaceNameAndOwner(ItemSpec[] itemSpecs, String& workspaceName, String& workspaceOwner)
at Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer.GetItems(ItemSpec[] itemSpecs, VersionSpec version, DeletedState deletedState, ItemType itemType, GetItemsOptions options)
at Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer.GetItems(ItemSpec itemSpec, VersionSpec version, DeletedState deletedState, ItemType itemType, GetItemsOptions options)
at TfsDeployer.VersionControlDeploymentFileSource.DownloadDeploymentFile(BuildDetail buildDetail)
at TfsDeployer.Configuration.ConfigurationReader.ReadMappings(BuildDetail buildDetail)
at TfsDeployer.Deployer.ExecuteDeploymentProcess(BuildStatusChangeEvent statusChanged)

We don't know in which file of TfsDeployer the workspace path has been defined? Is there any way to trace this issue out at Deployer's end?

I'd be really thankful to you if you can provide any assistance.


Thanks.
Aamee.
Feb 14, 2014 at 4:27 PM
Hi Jason,

Does it mean that TFSDeployer doesn't support TFS2013 at all? We've moved to TFS2013 and TFSDeployer is throwing this following exceptions on the web server where TfsDeployer was installed:

Microsoft.TeamFoundation.VersionControl.Client.ItemNotMappedException: There is no working folder mapping for C:\Windows\system32#\1\BuildProcessTemplates\TfvcTemplate\Deployment\DeploymentMappings.xml.
at Microsoft.TeamFoundation.VersionControl.Client.Client.GetLocalWorkspace(String localPath, Boolean throwIfNotFound)
at Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer.DetermineWorkspaceNameAndOwner(ItemSpec[] itemSpecs, String& workspaceName, String& workspaceOwner)
at Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer.GetItems(ItemSpec[] itemSpecs, VersionSpec version, DeletedState deletedState, ItemType itemType, GetItemsOptions options)
at Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer.GetItems(ItemSpec itemSpec, VersionSpec version, DeletedState deletedState, ItemType itemType, GetItemsOptions options)
at TfsDeployer.VersionControlDeploymentFileSource.DownloadDeploymentFile(BuildDetail buildDetail)
at TfsDeployer.Configuration.ConfigurationReader.ReadMappings(BuildDetail buildDetail)
at TfsDeployer.Deployer.ExecuteDeploymentProcess(BuildStatusChangeEvent statusChanged)

We don't know in which file of TfsDeployer the workspace path has been defined? Is there any way to trace this issue out at Deployer's end?

I'd be really thankful to you if you can provide any assistance.


Thanks.
Aamee.
Coordinator
Feb 18, 2014 at 3:56 AM
Hi Aamee,

No testing has been done with TFS Deployer and TFS 2013. However, based on your exception message, specifically the bit that says "There is no working folder mapping for C:\Windows\system32#\1...", I believe the problem is that your build definition is configured to store the drop inside TFS instead of on a UNC share. This is due to Team Build 2013 using drop locations beginning with "#\" and the Build ID to represent drops stored in TFS.

TFS Deployer only has UNC-based drop share support so this feature won't work without changes to Deployer. If you change your build definition to use a UNC drop share like TFS 2010 it should resolve your current exception.

Regards,

Jason
Feb 19, 2014 at 5:10 PM
Thanks Jason. Actually, the deployer worked when I had to download 'DefaultTemplate.xaml' which by default in TFS2013 gets stored in the TFS Database so had to check it in under this path "$/Team Project/TeamBuildProcessTemplates . So after that had to modify the build definition to use that newly added defaulttemplate file from that location, queued the build and then automated deployment worked successfully by changin the build quality. Besides that, I didn't have to change anything in the build def. like any UNC path or anything cuz it's dropping the build files using the build server UNC share without any issues. Anyways, this is how the current TfsDeployer ver 1.4 works with TFS2013 Team build architecture.

Thanks once again!
Aamee