We have migrated to TFS 2017 from TFS 2010.
While executing the builds, the builds are taking too long to get completed successfully.
Previously, in 2010, we use to use community build manager to execute the builds, in TFS 2017 do we have any such tools to queued up the builds to execute them all at once. Not just manually executing them one by one.
There are many reasons for this problem, eg hardware, software, bandwidth, size of the project... Please refer to below article to check that, it's still available for vNext build (Task based build process): Optimizing Team Foundation Server Build Time
In case if you installed earlier version of Visual Studio 2017 on your build agent machine, then you may have this problem. There are issues tracked in developer community site :
VS 2017 Build very slow
Slow compile times compared with VS 2013
In this case, you can try the solutions/workarounds mentioned in the issues, alternatively you can also try to install VS 2015 for the building.
Related
I need to configure a build definition in TFS 2017 for a solution that is developed in VS 2005.
The agent server that execute Build tasks is configured with Windows Server 2012 R2, and it's installed VS 2005.
In a build definition, I have tried with a command line task, but it remains executing the compilation and it is canceled by time-out
Can someone please reference me documentation or indicate me how to do it?
Thanks a lot for your help.
Audberto
I doubt that you'll be able to get the "Visual Studio Build" task https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/visual-studio-build?view=tfs-2017 working, but you may look at the MSBuild task https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/msbuild?view=tfs-2017 since you have a little more control.
Since 2005 (along with 2008 and 2010) are end of life, I don't think you'll get much support from Microsoft to support your scenario in the built in tasks.
I've searched for answers to my question on this forum and elsewhere, but so far unsuccessfully.
We are upgrading our toolset from VS2008/TFS2008 to VS2013/TFS2013. We now have TFS upgraded (phew!) but the big questions remaining are:
We have a single build agent using Team Build 2008 running on a Windows 7 x64 SP1 machine, with build results published to an old XP machine. Will the new TFS2013 server be able to work with it fully, or are we compelled to upgrade the build agent to Team Build as well? if so, does Team Build 2013 run on Windows 7 x64 SP1 or will we need a complete new server platform?
If we are compelled to upgrade the build agent to Team Build 2013, will/should our existing build scripts continue to work?
Can anyone advise?
The answer to your question is, "It depends."
The build system was totally redesigned in TFS 2010 to be based on Windows Workflow build process templates instead of MSBuild files. TFS 2010/2012/2013/2015 can all run old-style MSBuild files by using a build process template called "Upgrade Template". Whether they'll work immediately out of the box depends on how customized your MSBuild files are and what (if any) custom assemblies you're using. Custom assemblies may need to be recompiled, or may need code changes to continue to work.
TFS 2008 build agents do not work with TFS 2013. You will need to upgrade your build agents. However, TFS 2013 and 2015 build agents will both run on Windows 7 SP1, so you're good to go there.
The build system was revamped again in TFS 2015. My recommendation would be to get on TFS 2015 ASAP and skip the XAML build system entirely. The new build system is much easier to work with and can be extended with far less pain.
You are in a scenario with a fair amount of risk, especially if your business depends on your CI builds running regularly. Your best bet will be to do a test upgrade of your environment and validate what steps will have to be taken to ensure your builds continue to run against the Upgrade Template, or how much effort it will take to retire your MSBuild-based build templates and switch over to a newer build paradigm.
Regardless, I would strongly recommend making the move to TFS 2015 over 2013. Why go through the effort of upgrading from 2008 to 2013, only to still be a major version behind?
Our development sandboxes are currently running visual studio 2013 (update 2) and ssdt March 2014 release for our database projects. The latter was downloaded via the former.
I have started to look into tfs builds for the database projects. Our build box (controller and agent on the same box) is a windows server 2012 Standard with TFS 2012 installed.
I am trying to figure out what ssdt installs are required on the build box in order for msbuild to build and publish database projects - unfortunately I am not getting a clear picture.
Questions so far:
Is http://sqlproj.com/index.php/2012/03/headless-msbuild-support-for-ssdt-sqlproj-projects (still) relevant to our build box?
Do I have to install a visual studio shell to get ssdt March 2014 release? Or is there a standalone install?
Will ssdt March 2014 release suffice to get msbuild to build and publish?
The sqlproj.com article you referenced is still one of the better articles to follow. Note that right now it may be easier and better to install the VS2012 SSDTBuildUtilities.msi on your TFS 2012 build server. That is downloadable from the SSDT download page - the easiest way to get specific MSIs is to create an administrative install point which will lay them all out in a specific folder.
There have been a number of changes in the March 2014 release that require updates to the install recipe:
You need to use the SQL Server 2014 feature pack instead of 2012. The same MSIs are needed.
The expected install directory for the DAC and SSDTBuildUtilities compoments has changed. It's now expected to be under the Visual Studio install directory and will depend on having the $(VisualStudioVersion) environment variable set to match the VS version. If you're running TFS2012 the likely location will be "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\120". You can confirm this by checking the targets file just as that article suggests
We are currently working on an improved TFS / Build Server configuration experience as this is clearly harder than it should be to set up right now, especially with the changes to DAC and SSDTBuildUtilities location. However we do not have a firm commit date on when this might be released.
This question of FxcopCmd vs Code Analysis has been discussed in SO, but my question is a bit more specific. We use VS2012 for development and TFS 2010 for TFS Builds. My question is - Without having VS2012 installed on TFS, I wanted to know if VS 2012 version of Team Tools (FxCopCmd) could be installed on TFS 2010 so that I get same FxCopCmd output on both development env with VS2012 and TFS build as well? Today when I run Code Analysis in VS2012, the count of violations obviously is different from the count seen with FxCopCmd run as part of TFS 2010 Build. This is understandable due to version differences, though I ensured that both run with the exact same command line parameters. FxCopCmd references point to v4.0 .NET assemblies in both cases.
Can I just have VS 2012 version of FxCopCmd or Team Tools installed on TFS 2010 and would that provide same results as that of running CodeAnalysis on VS2012? (Code Analysis in VS2012 in turn uses FxCopCmd)
Can I just have VS 2012 version of FxCopCmd or Team Tools installed on
TFS 2010 and would that provide same results as that of running
CodeAnalysis on VS2012? (Code Analysis in VS2012 in turn uses
FxCopCmd)
Yes, this is possible. You will need to specify a CodeAnalysisPath property value that points at the correct path, but otherwise the only concerns should be around licensing, not technical issues.
I am testing the compatibility between TFS 2012 Source Control and TFS 2010 Build Agents, and I am glad to inform that they are compatible. I am wondering if there are any advantages to using TFS 2012 build agents. At this point, I have not found any information on advantages of using TFS 2012 build agents.
The 2012 build agent support the new Unit Test Runner, Lab Management environment, .NET 4.5 building, improvements in CodedUI, capability to trigger tests on a 2012 test agent, 2012 version of Code Analysis, improvements to Code Coverage and many many other things.
The main reason to support 2010 build agents, is to allow you to upgrade TFS from 2010 to 2012 without having to big-bang upgrade all build agents. When the next version of TFS comes, it will support the 2012++ and the 2012 build agents. It will no longer support the 2010 build agent.