I am very new in TFS, need to implement CICD using TFS 2017 and its build and release feature,
when I tried to run build after creating build definition, I got error like no agent found, I googled and found how to configure agent, but I have logical confusion in my mind as below:
How Agent works with TFS 2017?
Where process of CI will be run on Agent or on TFS server?
Where I need to have msbuild ? where my built code will be placed?
What other dependencies would be there on Agent machine?
all question might be silly but as I have worked with Jenkins and Git, i dont have knowledge of Microsoft technologies, and I can't find well documents for the same.
How Agent works with TFS 2017?
In short to build with TFS, you need to Deploy an agent, in the agent machine you need to install the proper build components/SDKs accordingly based on your project.
Create a build definition. Once a build is triggered , the sources will be downloaded from the TFS repository to the agent machine and then build in the agent machine.
Related documents : Agent pools and queues; Build and Release Agents; Build definition options
Where process of CI will be run on Agent or on TFS server?
You can eanble the CI (turn on the Continuous integration trigger) in build definition. See Configure continuous integration for details. Thus the build will automatically be triggered once changes are checked in.
Related documents: A quick introduction to CI/CD ; Build and release
Where I need to have msbuild ? where my built code will be placed?
For vNext build, it's task based build system. You can define your build definition based on the tasks. See Build and release tasks .
e.g.: You can use MSBuild or Visual Studio Build task, you can specify the MSBuild Arguments as needed.
You can use the utility task: Copy and Publish Build Artifacts and Publish Build Artifacts to specify where the built code will be placed. (Artifact Type : Server/File share path)
What other dependencies would be there on Agent machine?
Refer to the answer for the first question.
Related
Are there any issues with running a vNext build agent on the same machine that is running Functional Tests? My plan is to have an agent pool that consists primarily of test machines where each build agent has a one-to-one relationship to running functional tests on each respective machine.
Yes, you have the ability to run some Unit Tests both on a machine different from that one is running the build and on the same machine.
To select build agent in a pool which include multiple agents:
You can add a User Capability to that specific build agent then in the
build definition you put that capability as a demand (General tab)
How to specify a build agent in vNext build
About how to configure build pipeline and deploy test agent, you could refer below tutorials:
Running Automated Test on agent machine using vNext Build
TFS — Setup CI/CD pipeline for automated functional tests
Hope this helps.
I am currently in the process of migrating a couple of legacy Qt5 projects to a new Team Foundation Server. All projects have been developed for Windows in Visual Studio using the Qt VS AddIn (and thus don't use .pro-files). I would love to use the TFS Build Agent to build these on other platforms (mainly linux).
I have previously done this on other projects using Jenkins and qmake, having platform-dependent settings in the .pro-file.
Is there an established workflow for building VS projects using Qt5 via a TFS Build Server on other platforms?
I don't use TFS but, since TFS Build operates on Visual Studio solutions, it ought to be possible to use the "Linux development with C++" feature of VS2017. Just setup a Linux project in the VS solution and it should build like any other.
Seems you'd like to build Cross-Platform Code in Linux using TFS vNext build system. To build or deploy you'll need at least one agent. The cross platform build agent is support on Ubuntu, Red Hat, and CentOS.
Detail steps please refer this tutorial-- Deploy an agent on Linux. Then simply create the build definition add build task, select the Linux build agent the same as build on windows. More detail step and build configuration you could take a look at this video tutorial-- Building and Deploy Applications In Linux With TFS
In your case, there is not corresponding VS/Qt VS AddIn in your Linux environment. You need to set up your Linux build agent local environment to build your qt5 application successfully, then it's not hard to build through tfs.
Another way is scripting the Linux build process to run over SSH or some other remote protocol, and driving this process from the Windows build agent.
I am leveraging Visual Studio Team Services Build Vnext to build ASP.NET application present in my Microsoft GIT Repository.
The Microsoft GIT repository is created under an Agile Team Project of the VSTS instance.
The VSTS build is getting executed successfully without any issues.
But I have a query with respect to the cloning activity of the GIT Repository that gets executed on the VSTS Build Agent.
During the build, the VSTS build Agent is cloning the entire master branch of the GIT repository instead of downloading the required ASP.NET application folder.
Is there a way to download the specific application folder on to the build agent instead of the entire branch.
we have this option for the onpremise TFS build having TFS as the Source control.
As far as I know there is no way to pull only a specific folder on a git repository unlike tfsvc. This is why you don't have such an option for the build tasks.
I'm getting the following error on a TFS2013 build:
TF900547: The directory containing the assemblies for the Visual Studio Test Runner is not valid ''.
Looking here, it would seem that the answer to this is to change the test runner from VS test runner to MSTest. However, when I try to edit the Test Run in the build definition, the test runner option is set to Visual Studio Test Runner and greyed out. What determined what is shown in this box, and how can I add MSTest?
I have installed VS2012 agents for handling tests on the server.
I fixed this by installing VS2013 on the build agent
We had the same problem as the OP but, because the TFS server is considered a production box (other departments use it for other things), we were not permitted to install VS2013 on the server. The same applied to any third party tools needed for builds, they were a pain to integrate into the build.
I eventually worked round this by using another dev box to act as a build server for TFS. By installing the Build Server component of TFS on the dev box and setting up a controller and build agents on that box, TFS could pass the responsibility for the actual build to the dev box, on which we could install anything, without compromising the TFS server itself.
While it is not perfect - an extra box and VS2013 license needed - it is by far the easiest way to avoid poluting a production TFS box. Alternatively, nominate a developer's own box and install the build agent there - the environment is ready built, it will simply slow down a little during a build.
Look at section Define Multiple Test Runs of this article. It is very informative and explains different configuration in dept. Hope this helps !!!
I have configured TeamCity with Git to get my ASP.NET MVC project.
My solution contains the web app and the corresponding unit tests:
MY_SOLUTION.sln:
- WebAppProject
- SomeCoreLibrary
- SomeCoreLibraryTests
- OtherProjects...
The steps that I have configured in TeamCity are the following:
Get external packages using NuGet
Build the solution and deploy it
Run Unit Tests
Run Automated Tests (using Selenium)
I want to run the unit tests after building but before deployment and stop deployment if the unit tests failed. Currently the deployment is done after the build using the following Command Line Parameters:
/p:VisualStudioVersion=11.0
/p:DeployOnBuild=true I want this to be done only after SomeCoreLibraryTests.dll unit tests have passed
/p:PublishProfile=MyWebDeploy
/P:AllowUntrustedCertificate=True
/P:UserName=username_here
/P:Password=password_here
Thanks,
Ionut
What I've done in similar cases is to use RoboCopy to just mirror the new website into the deployment path. Doesn't that work for you?
P.S.: if you do get this working, I'd suggest doing a performance improvement change in TeamCity (which would allow you to run the unit tests in parallel to the automated tests):
I assume you are employing a single build configuration for all those steps. If that is the case, what I would recommend instead is using Dependent Build configurations to separate the different concerns. You can see an example here in an open source project of mine:
http://teamcity.codebetter.com/viewLog.html?buildId=112432&buildTypeId=bt1075&tab=dependencies
Log in as Guest and expand the Testeroids :: Publish to NuGet tree node to visualize the build flow.
To achieve this, basically you pass around the result of your build step in the artifacts (e.g. you pass the resulting binaries from Compile into Unit Test). You gain several things by using dependent builds: several independent build steps can run in parallel on different agents, plus if one of your build steps fails because of external factors (e.g. let's say Publish failed because the network went down), you can trigger again the build and it will only rebuild the failed steps.
I am not familiar with the tools that you use. However, I would, in general, use a few build configurations for a project:
build configuration, triggered on change, containing these steps: get the latest source code and packages, build/compile and unit test. Then create an artifact for deployment task.
build configuration to deploy to a development server, triggered by successful completion of and using artifact (via dependency) from (1).
build configuration for long running (eg integration/functional) testing that is scheduled to run less frequently.
An advantage of (2) is that you can, if necessary, re-deploy a build/artifact without having to rebuild the artifact first. Also, if you have multiple agents, (2) and (3) can run independently of each other.
Furthermore, you can also tag build in (2) that have passed development checks and then use its artifact in another build configuration to deploy it to test server, etc.