I have created a V-Next build using TFS 2015 and have defined some variables like IPAddress -
Screenshot for variable defined
Now I have to use this variable in my release management while invoking a powershell script.
Release management variable
Any idea how i can do this?
You can refer to this article to Configuration variables and system variables for release management.
However Release Management features have been integrated into the Build & Release hub in Team Foundation Server (TFS) and VSTS.
The newer web-based version is the recommended alternative to the server and client version. If you do not already have Release Management installed, we encourage you to use the web-based version in TFS 2015 Update 2 and above or VSTS instead of the server and client version.
Generally in TFS 2015 the custom variables set in build process can not be used in release management. But you can set the variables in release environment. Thus you can use the variables in release process.
Related
We are attempting to upgrade our rather old TFS environment from TFS2008 to TFS2015. The upgrade of the server and database is not a problem and is fine.
The issue is our build machine. This is still a Windows 2003 Server that is running Visual Studio 2010 and VB6. We still have a need to use this build machine to build legacy VB6 projects. We have installed the TFS2010 XAML build controller on this server and successfully connected it to our test TFS2015 server. However when we try to run a Xaml build, (any Xaml build regardless of whether it builds VB6 or .NET) we get the following error message almost straight away.
TF900560: Could not start build: Cannot set unknown member 'Microsoft.TeamFoundation.Build.Workflow.Activities.TfsBuild.TargetsNotLogged'.
The XAML build are using the 'UpgradeTemplate.xaml' template and using the TFSBuild.proj we used under Visual Studio 2010.
We have a also set up a TFS2015 build controller on another (Server 2012) machine and that successfully starts the build process. However, our VB6 projects use a lot of third party components that will not install on Server 2012 so we can't use that.
Has anyone ever set up this kind of arrangement before? Is there anything we are missing or are doomed in this scenario? Obviously, we'd like to move away from VB6 apps, but that is not possible in the medium term.
We have an old server machine with TFS 2012 installed on it. It has the 'DefaultCollection' of project collection. We want to copy (not move, i.e. leaving the collection in place) the 'DefaultCollection' collection to another machine which has TFS 2015 installed.
How can we do that please?
Thanks, ashilon
It depends a bit on how complicated your TFS installation is, but here are the steps for a simpler one server setup without Sharepoint:
Detatch the collection from your current TFS 2012 using the Team
Foundation Server Administration Console. This will copy the configuration into the collection database.
Take a full backup of the collection database (called something like Tfs_DefaultCollection) using SQL Server Management Studio (SSMS).
Restore the original collection on your TFS 2012 server
Re-attach the database on your TFS 2015 server using SSMS. Note that if you already created a collection on this server with the name DefaultCollection, you either need to delete/rename this or restore the cloned collection using a new name.
Attach the collection on your TFS 2015 server using the Team
Foundation Server Administration Console
Start the collection so that it get's into the Online state.
Please note that build servers, drop locations and so on will now point to same thing in the original collection and the clone collection, so you need to do a bit of cleanup.
The above is a shorter version of this: https://msdn.microsoft.com/en-us/library/dd936158(v=vs.110).aspx
Edit: I have successfully used the above approach to make a test migration from TFS 2010 to TFS 2013 RTM followed by the migration of our production environment. We use the server with the test migration for testing new updates before applying to production and we have done so with all updates from 2013 RTM until 2015 Update 3. I am currently applying the same approach in upgrading to 2017 in order to get a fresh server with never version of SQL.
Can't seem to find an answer to this on MSDN or on here, does the Team Foundation Server 2013 API expose any methods to allow Project Creation? and if so in which classes?
No: project creation is a complex process involving many modules (DLLs). In fact, it requires Visual Studio (or Team Explorer) the same or newer version of TFS.
If you need to automate, you may use the tfpt createteamproject command line tool.
Update 2016-07-22: Since TFS 2015 Update 2 it is possible to create a project using the REST API.
I am trying to build and deploy an SSRS project (rptproj) but MSBuild does not support this project type. What can I use to build and deploy this project?
I looks like I can use RS.EXE and Dev Env. What are the benefits of each?
It actually is recommended to install Visual Studio on the TFS Build machine to support building various types of projects that MSBuild alone does not support. You don't have to worry about licensing because as long as you have a Visual Studio license then you can put it on all of your machines.
You can find more details here.
I have been using a database project in visual studio 2010 to create a database. Visual Studio makes this process really easy to deploy the database and deploy updates. The issue I have is how I can get visual studio to create a script that will build the database that I can use on a QA or production system.
I thought that building the project would create a SQL file that did this but this does not seem to be true. Can someone please advise on how I can do this or what simple step I am clearly missing.
As strange as it may sound, Visual Studio does not create a SQL file to deploy your database when you perform a Build.
Instead, this occurs at Deploy time. The reason behind this lies in the way that Visual Studio makes changes to the database that you're deploying to: in order to change your database, it must first compare the project model (as defined in the files contained within the .dbproj) with that of the existing database schema to determine what changes you have made since the database was last deployed.
You then have the choice of manually executing the SQL script produced using the SQLCMD command-line utility (or through SSMS in SQLCMD mode), or alternately you can configure your Visual Studio Database Project to execute the script if you specify the following Deploy Action in project settings:
Generate a deploy script (.sql) and deploy to the database
Note that you will need to provide a connection string in project settings so VS knows where to deploy to.
When you get to the stage where you want to deploy to a QA or PROD environment, you have a couple of options:
Deploy directly within Visual Studio. In addition to the standard Debug and Release configurations that you get when you first create your Database Project, you can also create your own configurations which you could use to deploy to your QA and PROD environments (i.e. potentially with a different connection string/target database name).
Deploy from a Build Server. Install Visual Studio on a separate machine and call MsBuild against your .dbproj/.sln file with the Build and Deploy targets specified along with the appropriate connection properties.
Doug Rathbone has written a great blog post on subject if you want to learn more:
http://www.diaryofaninja.com/blog/2011/06/23/compare-amp-update-database-schemas-right-within-your-ide--part-2-automation-with-teamcity