On a quarterly basis we perform a disaster recovery exercise where we clone our PROD TFS environment by restoring the backups from a given date from our PROD TFS environment to another TFS 2015 environment. We've been doing this successfully with TFS 2012 and 2013. But when we attempted this with TFS 2015.1 the vNext build definitions are still getting source code from our PROD TFS server. We know how to make sure all of our XAML based build definitions are utilizing the DR environment but the vNext build definitions are a bit of a mystery. The system.collectionId GUID is different for the vNext build definitions in each environment. When we create new vNext build definitions they work as expected.
To move vNext build definitions, the best way would be using the REST API to get the build definitions, modify the JSON file, and load the file back to create definitions in new projects.
Useful links:
https://www.visualstudio.com/integrate/api/build/definitions
http://www.ericksegaar.com/2015/10/16/using-json-via-rest-to-create-build-definitions-in-vso/
https://writeabout.net/2016/03/03/how-to-move-build-definitions-in-tfs-to-other-projects-using-the-rest-api/
Related
We are using an on-premise installation of Microsoft Visual Studio Team Foundation Server Version 16.131.
We have a Development Continuous integration build definition that includes running some unit-tests on a very old application. As such, the unit-tests require a database to run (I know, not an ideal situation with unit tests...)
One of the artifacts of the build is a DACPAC of the database.
I'd like to deploy any database changes from that DACPAC as part of the build definition, before running the Unit-Test steps. That way, any tests that are added / changed that are dependent on database changes will (hopefully) pass.
Any ideas if this is possible, and if so, how can I publish from the DACPAC within the build definition?
We are using a PowerShell step in the build/release pipeline.
In the powershell script you will call SqlPackage:
&"C:\Program Files\Microsoft SQL Server\140\DAC\bin\SqlPackage.exe" /Action:Publish /SourceFile:"Dacpac_Artifact\DACPAC\DB.dacpac" /Profile:"Dacpac_Artifact\DACPAC\FileWithPublishPrife.publish.xml"
You could also have a look at this Microsoft DevLabs task, it also contains a sub task to deploy dacpac remotely, so you could deploy to another machine (or use localhost to deploy on the build server itself if you want). There are also other marketplace task you could use just navigate to the store and type sql you'll see a dozen.
IIS Web App Deployment Using WinRM
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
there is no code. Do we need to Re-configure all build server again?
After migration on VSTS can we configure All build servers on premises as well using old all XAML build definitions or not?
Please suggest on this.
XAML builds are still supported with Azure DevOps Service (with some limitations), see official response from Microsoft:
XAML build is still here until now. Current state :
If you have any XAML build data in your team project collection, you
will get a warning about the deprecation of XAML build features. You
will need to use VS or Team Explorer 2017 to edit XAML build
definitions or to queue new XAML builds. If you need to create new
XAML build agents, you will need to install them using the TFS 2015
build agent installer. Please refer to official document -XAML builds:
https://learn.microsoft.com/en-us/visualstudio/releasenotes/tfs2018-update2#xaml-builds
And we will keep it longer, how long does it can be used depend on
user feedbacks.
Installing TFS2015 Update 4.1 locally allows you to configure Build Server, Service and Agents that are connected to Azure DevOps Service, and run all your XAML builds from either Azure DevOps or Visual Studio.
XAML builds are no longer available in VSTS, so they will not work at all after a migration.
The good news is that TFS 2017 supports build vNext so you can convert your builds before you migrate to make sure you can still build after the migration.
Build vNext (Azure DevOps Pipelines) are much more flexible and easier to set up and customise than the old XAML builds. However if you have a lot of customised builds then it might take a while to convert them all.
One big advantage of the new build system is that the same build can be used across multiple branches, which might mean that you don't need to put as much effort in to converting builds as in the XAML system you needed a build per branch.
My suggestion is that you begin by familiarise yourself with the new build system and start to convert the builds before you migrate, then you can import you TFS database in to VSTS.
My solution consists from C# projects. I need one build definition that builds the whole solution. Most of projects have project to project referencies (like ProjectReference Include=) but some projects have explicit dependencies stored in solution file (ProjectSection(ProjectDependencies) in sln file).
old connect.microsoft.com article
claims that MSBuild ignores order specified in solution "Project dependencies". Are situation the same in TFS 2015? What MSBuild version does TFS 2015 use nowadays?
Does TFS 2015 Team Buider that uses MSBuild order building of projects properly according to dependencies stored in solution file?
It does, at least on solutions I have seen (consisting of 10-15 projects) dependencies never give issues.
Additionally TFS2015 have Visual Studio build step which is run not by standalone msbuild but Visual Studio installed on the build server. Naturally this build step completely replicates your local build behavior.
We have a TFS 2015 build server running the new Agent in Agent Pool.
Also we have a solution with three MS SQL database projects. One of these projects has references to another two.
When I build this solution in Visual Studio 2015 on my PC, the resulting model.xml includes all views with references through [$(DBName)] variables.
However, when I run the build on TFS, all objects with external references disappear from model, thus they cannot be found in .dacpac file and as result, we cannot do a deployment.
Could someone give a hint how to solve this issue?
Log on your build agent machine, and check the output of the TFS build to see whether the structure is the same as local build. Also, try to use MSBuild command line to build the solution manually on your build agent machine to see what result will you get.
It seems you reference output assemblies from one project. Instead of referencing output assemblies, it's suggested to make a project reference or create a NuGet package.
We have migrated few projects from TFS2008 to TFS2010 by using the method-
1.Attch TFS2008 DB to TFS2010 DB
2.Tfsconfig import
3.Delete the project not required.
There are few projects in the migrated projects which use VS2005. They do not want to do any change in their project and want to use VS2005 to work with migrated projects. We have applied couple of patches in VS2005 and now they are able to access the TFS2010 projects from VS2005.
However we are clueless about the build configuration. We have configured build server for their Collection...now what configuration needs to be changed in TFsbuild.proj to make the build run again.
Is there any more steps required to make the build work?
Any help would be very much appreciated.
Thanks Upfront.
Kabir
If you have not had a build definition for you TFSbuild.proj then you will need to create one. In your build definition, you will need to choose UpgradeTemplate.xaml as the build process template. In TFS 2010 this template is used to run legacy build definitions.
See how to run build with the UpgradeTemplate.xaml here.
I also found this useful post in the MSDN Build Automation forum that tells you the differences between 2010 and 2005 build processes.