I am using TFS 2018. I successfully created a "Hello World" MVC and SQL Server project. I was able to build and release the project to the target server.
To make sure I had the method down correctly, I created a second "Hello World" MVC project. I was able to build it successfully. The only problem was that when I went to the "Deployment Groups", I didn't see anything there, even though the target server already has a Deployment Machine running.
I figured the problem is that I need to share the Deployment Machine. So I read the instructions for Deployment Groups here:
Add a deployment pool and group to another project
To manage a deployment pool, or to add an existing deployment pool and
the groups it contains to another project, choose the Manage link in
the Agent Pool section of the Deployment Group page. In the Deployment
Pools page, select the projects for which you want the deployment
group to be available, then save the changes.
When you navigate to the Deployment Groups page in the target
project(s), you will see the deployment group you added and you can
assign project-specific machine tags as required.
The problem is that while I have a "Deployment Group" page, I do not see any "Agent Pool", "Manage", or Deployment Group". (See screenshots immediately below).
Am I missing something obvious? Is this a case of the instructions really being meant for VSTS and/or Azure, but not TFS?
I selected the deployment group and see the machine that I registered on my target server.
Even when expanding the machine, I don't see any options to share.
In summary, what I do have to do in order to share this Deployment Machine, so that I can release different projects to the same server?
At the collection level, we do have a "Deployment Pool (similar to Agent Pools)". However, it is only available in VSTS for now.
Can you tell me if this feature will be integrated in the TFS 2018's next update ? and when this update should be available ?
We are hoping to get it in the next update in TFS. Tentatively in
TFS 2018 Update 2.
This feature seems will come up on TFS 2018 update2, details please refer this link: Why are deployment groups project specific?
Sharing of deployment group targets feature will be available with TFS 2018 Update 2. On earlier version, you have an option of installing multiple agents. Please note, multiple agents can run the deployments in parallel and can overstep on each other for shared resources.
If upgrading to update 2 is not a possibility, you can modify your registration script to make the computer name dynamic:
modify this:
--deploymentgroup --agent $env:COMPUTERNAME --runasservice
with this:
--deploymentgroup --agent $env:COMPUTERNAME-$destFolder --runasservice
$destFolder basically makes the agent name unique, allowing you to register the same machine in multiple deployment groups.
If you get a message saying
The request was aborted: Could not create SSL/TLS secure channel
run the following command before provisioning.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Related
Long time user of Release Management, though only up until TFS 2015 previously. I used to achieve role based deployments by creating "machine groups" for each environment, listing the server FQDNs, ports and tags (roles) along with some credentials. I could then leverage these details in release definitions by specifying the machine name as the name of the machine group and then use the tags filter criteria to pin down which server roles the action would run against/on.
I'm now working on TFS 2017 and stated in the "machine groups" section is that the functionality is deprecated, rendering it unusable. Documentation online talks of its replacement: "deployment groups" but this only arrived in TFS 2018! So is TFS 2017 without any form of environment level role based deployment solution?! The machine groups tag suggests "use a comma delimited list of machine IP addresses or FQDNs together with ports in all your build and release definitions" - that seems like an unworkable solution to me! Please someone tell me I'm missing something!
Unfortunately TFS 2017 doesn't support Deployment groups.
Deployment group targets feature only available with TFS 2018 and later version including Azure DevOps. Please see Deployment groups for details.
So, to use the Deployment group you could upgrade to TFS 2018 or migrate to Azure DevOps.
In tfs 2017 you could list the machines use a comma delimited list of machine IP addresses or FQDNs together with ports... You can also create Task Group and set deployment settings in the task group, thus you can directly use that Task Group in your build definitions... Please see Task groups for builds and releases for details.
Developer A is member of group - 'Contributors' and 'Project Valid Users' for team project T1. He is required to perform all development activities like check-in, check-out, merge etc.
There are 3 builds configured for this team project T1. One each to build and copy artifacts to Dev, QA and Production servers.
Currently 'A' is not able to modify the build but he can execute (queue build) the builds.
We need to control this build executions. We want only few members (project owner) to execute the build (& deployment) of QA and Prod.
Please advise how to provide the authority to control the same.
This can be achieved by permissions. You can add all the project owner to the group - Project collection build Administrators. Setting the premissions to make sure only this group can queue the related build. More info about detail permissions for your reference: MSDN Link
To setting the permission, you can do this in the web portal( click the security just as below) or using tf permission command
Note: My screenshot is for TFS 15, not for TFS2015, there maybe something difference.
So, I tried to upgrade my TFS 2015 to allow project with .NET 4.6.1.
I downloaded the Targeting Pack for .NET 4.6.1, ran it, restarted the server, ran my build configuration for the build agent by overwriting the old settings, and started my builds.
Now non of them will build :(
I think I miss setting a parameter somewhere.
This is my agent, which is registered, but never requested (for some odd reason):
Am I missing something?
According to your agent.version 1.95.3, seems you are using TFS2015 update3 which should definitely support .Net 4.6.1. And the system capabilities of your agent looks okay except the Number_OF_PROCESSOR. Your value is 1, but usually the default is 8. Did you manually change the value during the configure?
Recommend you follow below way to narrow down this issue:
First check in that if the build server is available and enabled in
TFS at https://YOURCOMPANYNAME:8080/tfs/_admin/_AgentQueue, and
your build agent should be “Green”.
Make sure the agent is in interactive mode.
Try to change a domain account which is a member of the Build
Agent Service Accounts group and belongs to "Agent Pool Service
Account" role, to see whether the agent would work or not.
Double check whether there are some Firewall interface block the
build, try to disable all related settings.
If it's still not work, delete that agent and re-deploy a new one following the detail steps in this article. You can also go through below similar questions to check if there is some useful info :
TFS 2015 On-premise issues
TFS 2015 build vNext - hangs with "Waiting for console output from
an agent..."
TFS 2015 Build agent won't start
I recently installed TFS 2015 on a new machine. I want to configure the same machine as our build server but i have massive trouble doing this. I neither can configure the new vNext-system nor can i configure an "old-style" xaml build server. As the build account i want to use the NT AUTHORITY\Network Service. For the xaml configuration i set "Execute service as" to NT AUTHORITY\Network Service and use the same account for the connection to the team foundation server.
But when i add a new controller and want to browse to custom assemblies, i get a "service unavailable" error. So i decided to test without the custom assemblies, added an build agent and created a new build-definition for a simple test project. I added a build to the queue and wait. Nothing happenend (in the build window) until after about 50 seconds an error was shown in the build window: Service Unavailable (Typ VssServiceResponseException).
Same for the new vNext builds. I downloaded the agent.zip from the web-frontend, opened the powershell and started configuring the build-agent. After waiting some minutes, the configuration aborted with.... service unavailable.
So i decided to test something different : instead of using the FQHN, i used localhost and - tataaa - it starts the agent, which is also shown green in the web-frontends agent-tab. So i created a new vNext-Build-Definition and added it to the queue, but it does not start, but shows the message : "waiting for console output from an agent".
So i decided to test it on a different pc : i downloaded the agent to my laptop and installed it, configuring the agent with it's FQHN. Without any problems the agent was started and i was able to start and run a build.
So the question is : Why am i'm not able to configure the build service on the tfs. I guess it has something to do with permissions, but i don't now, what permissions the network service account should have. I also tried it with a local account, but with the same result.
Any hints are very appreciated. Thanks in advance.
BTW: I can ping the FQHN from the command-line.
This is the output, after trying to add a vNext-agent via the powershell.
UPDATE:
I used the the servers IP-address instead of its name and it suddenly worked.
Take XAML build for example, to configure a Team Foundation Build Service, you must be a member of both the Windows Administrators security group on the server on which you are configuring Team Foundation Build Service and the Project Collection Administrators group on TFS.
According to the second paragraph, you can configure build controller and add build agent. Before queuing a build, you need to make sure the build controller and agent are in Ready status, sometimes relevant services are not yet fully available when you newly configure them or restart them.
Also, you may try to remove build service feature, and reconfigure it, to see whether you can solve the issue.
I'm setting up TFS 2015 for my team to try out, and I'm having trouble getting it off the ground. It sounded straightforward, but things don't work and I can't find any diagnostics, and tutorials don't match what I'm seeing. Some highlights:
When I go to download a Build Agent from the server, I don't get a PowerShell file (ConfigureAgent.ps1), I get ConfigureAgent.cmd.
The images and description of setting up the build controller show me a nice picture of the TFS Admin Console with a Build Controller and Build Agent and their statuses underneath 'Build' (see Team Foundation Server 2015 Builds will not start or https://msdn.microsoft.com/en-us/library/ms181712.aspx.) On my system, I see this display under XAML Build Config (the old way,) but the Build item in the console doesn't have anything like that. It has a link to download an agent, but installing an agent doesn't change this.
Installing the agent appears to work. I get a service that's running, and the web portal agrees that I have an agent in the default queue and pool.
But, queuing a build just sits there. I've found the _diag folder for the agent, which has logs with a bunch of "Message received, no message retrieved" lines. I can't find anywhere else to check if the server knows about this build.
The service account is Network Service, and I've tried putting it in every TFS group mentioned online regarding permissions.
My setup is TFS and VS 2015 installed on our build machine, with it also hosting the build agent. I'm on port 8079, because port 8080 is taken. It's got to be something silly I missed, because everything looks like it's working. Has anyone gotten this beast off the ground without coming from a pre-existing install?
The configureagent.cmd is the correct file (it does pretty much what he ps script did)
Make sure the account that the agent is run under is in the "Agent Pool Service Account" role. It is better to use a domain/machine account not a local service account.
Make sure the queue is provisioned in the collection ( https://your-tfs-server:8080/tfs/your-collection/_admin/_AgentQueue ). If not - select "New queue.." and select the existing queue.
Make sure that when setting up the build through web access, the demands (on the general tab) is met by the capabilities of the agent.
If all this is in place, I have found that it facilitates testing by running the agent in interactive mode (not as a service). This gives you a bit better insight into what is happening. When it is working you can configure it as a service again.
Use an actual service account, not NETWORK SERVICE, and make sure that service account is a member of the Build Service Accounts group in your Team Project.
For me the issue was that the IIS's Team Foundation Server site setting's Authentication, "Windows Authentication" had to be enabled.
I was using a windows user as the log in credentials for the Build Agent running as a service.
Remember this new build system uses all http now.
It does not talk to any tfs build controller.