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.
Related
I have to create CI/CD pipeline in TFS 2017 to execute JMeter performance test.
I've created a build definition according to the tutorial and a release definition (I have used created build definition as an artifact for the release definition).
After trying to create new release I get the following message: Versions could not be loaded for all artifact sources. This could be due to inaccessible artifact source or artifact source has been deleted or no versions are available.
Could someone help to fix it? Thank you in advance 😊
The error you are getting because it couldn’t access the artifact source anymore due to some reason.
May like there are not available builds (deleted by retention policy)
or your build definition renamed.
Make sure your build definition has successful builds, and it has
'Publish Artifact: drop' as the last task (Try both drop to the
server and a file share).
Another place you need to pay attention to is permission. Please
double check your account and those groups which contain your account
have sufficient permission to create release. Check if there are any deny setting, since deny trumps allow in TFS.
Set Inheritance > On, and then assigned full rights to the Administrators and Service groups in the Build (not Release). And this actually should bring back the drop-down content of artifacts versions in Releases.
Here are the documents which explains how to create the release definition and how to link the artifacts. Please kindly go through it in case you need:
Define your multi-stage continuous deployment (CD) pipeline
Release artifacts and artifact sources
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
I have an instance of TFS 2015 with vNext builds working on my DEV branch.
I cloned a working build definition and set the Maps and solution file to the corresponding paths on the Main branch. On the Main branch they fail with the error message: "Could not find a part of the path 'C:\agent4_work\5f9b9727\myTfsProjectName'." This path is not even being created in the _work directory like is when I use the paths for the Dev branch.
Notable similarities between the two builds:
The build steps being used in both cases are the NuGet Installer and Visual Studio Build steps.
Same code exists in both branches.
Notable differences:
Main is the parent branch of DEV
Main has an added permission group to deny certain users from checking in.
My TFS service account is not a member of this group so I don't that applies.
Note: If I change the clone to point to DEV, it doesn't fail.
Can anyone tell me how to solve this mystery? Thanks.
Edit:
I found another difference the working branch has that the Main branch doesn't.
I don't remember adding the Project Build Service to the Dev branch. I also don't know why Main did not have this security setting. After I added the same security credential to Main, builds on Main started working. This raises another question: Does one need to add the Project Build Service to every branch as a second step in order to perform TFS builds?
Usually, the Build service account should be created and added to code repository automatically when the project is created and it will be inherited in every child folders. So the user does not need to add it to other branches/folders manually. For your case, I'm not sure if the user is removed unexpectedly or any other things happen.
Have you set "Items To Build" to correct path?
In Build Definition->Process-Items to build
screenshot from Build Definition
How can I add a capability to a build agent in TFS 2015?
For example, I would like to install a build tool (on a TFS2015 build agent) and register this as a TFS Build agent capability.
I know that I can add this capability manually, through the web interface, but how to do it with a script?
I've read that TSF2015 discovers build agent capabilities alone, but.. how to instruct it about 'how to detect my build tool' ?
References
I've read so far:
http://nakedalm.com/using-build-vnext-capabilities-demands-system/
http://www.colinsalmcorner.com/post/why-you-should-switch-to-build-vnext
Credits go to Donovan Brown and its blog post
I have tried the solution it proposes, and it works in my scenario/environment:
set an environment variable during the software setup
this variable and its value will appear as agent capabilities in the TFS agent resume
According to a GitHub issue, this functionality will eventually appear in npm scripts accompanying vso-build-tasks.
In the Agent capabilities you can define custom "user capabilities"
I added a custom user capability called
"Tag" and set it to VS2015
In my build definition under General, under Demands, I added a demand that
"Tag" equals VS2015
This will now force my build to that specific Pool (or agent)
For example I installed a 3rd Party utility to one of my build agents and added to the Agent user capabilities "AutoIt" = True. In my build, under General, Demands, I added one called "AutoIt" exists, this forces this build to the agent with the 3rd party utility that is installed.
Our plan is to use Team Foundation Build service to do automatic builds, then use the testing facility to automatically perform testing on the build server then release that build onto the application server.
So far we have
Team Foundation Server with TF Build Controller configured
Build server with win2012, Visual Studio 2013 and Build agent configured.
SQL Server with SQL 2013 installed
Application Server with Win2012 and .netframework installed
My question is what do I need to do to set up automatic builds, and to execute the unit test harness once compilation is successful.
Also the deployment target machine will initially be DEV, however we would like to quickly build for test env and prod etc.
This is what I got so far.
Build Controller (Already set up I believe)
Build Agent (Already installed on build server)
Build Process Template (Do I need to do anything with this. Is this what controls the whole lot)
Team Build Definition (I had a look at this, and it seems to use the build process template)
Drop Folder (I am assuming this is where the executables will be dropped into).
At the moment I have bits and pieces of info, what I would like to know is how this whole thing is hanging together. From the moment the developer wants to do the build to the moment that exe is placed into the DEVAPPSERV (Development application server).
Is anyone able to point me in the right direction or give a summary of what I need to make this happen?
Many thanks,
Dalibor
Install TFS Server (TFS Disk) Create a Team Project Collection and any desired Projects
Install TFS Controller + Agents onto a dedicated machine (TFS Disk) Configure only the build options if on a different machine to the TFS Server
Configure Build Controller to connect to a Specific Team Collection on your TFS Server
Install VS Premium or higher on build machine, if you want code coverage results for your tests
Add some code to TFS Source Control
Create a Build Definition using the default template.
Configure the build definition.
Set the working folder for the build, include only what you need as this will speed up the process
Point the definition to your .sln or proj file.
Ensure testing is enabled and that your test assembly names will match the regex used to identify test dll's i.e. name your test assemblies with the word test.
Set the trigger to be CI or what ever flavour of build you require i.e. gated build
Save the build definition
Trigger a manual build and debug any issues
you should have the basics done and a repeatable build created.
That should cover the basics, you may want to customise the build template (see Ewald Hoffman's guide for tips), you may want to narrow down your code coverage (look for runsettings file info).
If you follow these steps you should be able to get a basic build created and running from these, if you hit any issues you can come back and ask specific questions about a particular area
In order to do automatic builds you should check the CI build option ( under the trigger build option ) and third party automated testing can be run by executed by a post build script.
See the following TFS article about post build scripts.
http://msdn.microsoft.com/en-us/library/dn376353.aspx