I've seen this question on another forum with no answers and I am actually trying to figure out the same thing.
https://superuser.com/questions/1120229/vsts-branch-users-username-organization-for-git-repos
Any idea how to create a branch under users//?
You can create users/frank as a branch. But you can't then create users/frank/somefeature. Just create the branch locally with the full name users/frank and then publish it to VSTS from Visual Studio or push from the commandline.
Related
I am trying to setup sanity in a Svelte & Routify project. was wondering if having an entire thing for sanity is necessary, I know you can publish the studio to .sanity.io, wondering why isn't everything online in the first place and not somethings local
Developing your studio locally allows you to make and test incremental changes. Other developers on your team can work from their own local studios and make their own changes as well. The deployed studio might be the tool used by members of your team who aren't developing the studio itself but are accessing or editing the content. They can work from that studio without seeing (potentially breaking) changes as they're being made, which would be the case if everything was edited online.
If you're familiar with how git works, you can think of a repo like you might have on GitHub. You can work on your repo locally—saving as you go by committing. No one else on your team can see these changes and they don't impact the remote repo. That's your local studio. Once you push your commits to GitHub, they're accessible to the rest of your team. That's your deployed studio.
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.
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.
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/
So I have a Visual Studio solution which contains 3 database (.dbproj) projects. These projects need to reference other sql projects from other solutions, which I have packaged and uploaded to nuget. How can I manage these external packages / references in Visual Studio within the dbproj's?
Right clicking the database project within visual studio doesn't give me the "Manage NuGet Packages..." option.
I can Manage NuGet Packages for Solution to at least download the required packages to the solution root but at the project level, where the references are required I'd have to manually manage the references within each projects' references and update manually any time the package is updated so the reference points to the correct versioned package directory.
Is there a better way to do this for dbproj references for database projects in Visual Studio??
I ended up following the same path, creating NuGet packages of the referenced databases and then manually (via command line) installing them at the standard \package location. Then correcting the database references manually in the IDE
There is a work item for this functionality, go vote it up. There is a fork of the functionality already developed that sounds like it is fairly feature complete. You might try it out.