I would like to use VSO as App life cycle management (ALM) tool for other platforms, native android development to be specific. I understand that I can use it for sprint planning and related things.
However, I would like to associate my checkins with BLIs/Tasks/Features.
I think if its achievable then raising pull requests should be as per flow.
Yes, it is possible for you to associate checkins with Tasks or Features work items.
You can do it via opening the work item in IE, and go to All Links tab, select LinkTo and choose Changeset link type. See:
If you are using Git repositories in Visual Studio Online, work items are linked to commits by using the notation #1234 using the work item number. The server will see it and automatically associate the work item with ID of 1234 to that commit and use it in other locations like builds, pull requests, etc.
We call the feature "#mention" and you can see more information about it here: https://www.visualstudio.com/en-us/news/2015-jun-3-vso.aspx
Related
What is a good learning resource for TFS and how to use TFS with Visual Studio?
Specifically, I want to know two things.
Exactly what are the step-by-steps procedures of checking in code. I know that I am required to do a code review. So, after the code review is done by a peer, I understand that this is not enough and the original developer has to click to do something to submit the code into the TFS system. I mean, I want to know precisely what buttons to click on.
I also want to know how to use Visual Studio to look up the actual version. How do I determine the details of what is already checked in?
There are many blogs videos in google. If you want a full detail resource, suggest you directly take a look at our official doc here -- Azure DevOps Server Documentation
A suggested learn order for your reference:
Installation (you could skip this if your company already done this)--
Code -- Build&Release -- Packages-- Test-- Work-- Analysis-- Admin
Tool
TFS supports two types of version control: Git and Team Foundation Version Control (TFVC). One centralized and one distributed. As for which version control system should you use, you could take a look at this thread: Choosing the right version control for your project
For your case, you could easy check the history in server side. It's called changeset in TFVC and commit in Git.
For example, when you check in your changes, they are stored on the server as a changeset. Changesets contain the history of each item in version control.
You can view a changeset to see what the exact file changes were, discover the owner's comments, find linked work items, and see if any policy warnings were triggered.
The same as Git, actually you could find the answer for both question 1&2 in Code part. Hope it helps.
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
I currently use TFS 2013 with custom work items for bugs, change request, requirements and features. I am wondering if I can migrate them to visual studio cloud 2015? is there a tool within VS or 3rd party that can do this?
If you are meaning the vsts. Possibly duplicate with this question: How to migrate work items from TFS to VS Team Services (VS Online) . There has been perfect answer from jessehouwing, suggest use one of below three ways as he suggested:
Use Excel for import/export - Will work for most work items, you loose attachments and work item links other than parent/child. The
trick is to extract from one Project Collection then copy all fields,
except the ID to an Excel sheet bound to the target project
collection. You will need to fix all Identity fields (works best when
users have the exact same display name on premise as in VSTS) and
you'll have to import once with state new and then past the current
state/reason over the just imported values and sync again. Test
Cases, Plans, Suites and Shared Steps will not be imported with their
relations in tact. The approach would be very similar to this
one.
Use the TFS Integration Tools - Will work for most work item types, though it will loose custom kanban states and tags. Test
cases, Shared steps and their relations will not be imported. This
option will allow you to import import work items and source code
with their relationships in tact.
Use a 3rd party solution - Out of the available options currently OpsHub offers the most complete solution. For test case and
source control link migration you're looking at the commercial
edition, which comes at a steep price. It still has a long list of
known issues and last time I tried it, I ran into numerous
issues which required their support to resolve them. PS: You can aslo try the tool as Dave suggested in the comment: VSTS Sync Migration Tools
We are building a Saas application and would like to have a section of our app that shows release notes, upcoming releases, recent changes. For the last part, it would be great to simply be able to read the comments from our check-in history from VS Team Services and display them within a web page in our app. I know that means we have to write these comments with a customer-facing perspective...we'll deal with that. But just want to reduce having to manually put these updates on our web-page every time we do a change.
Is there any API to this database that you can read from externally?
You can use the Team Explorer API to query changesets and read the comments.
We started programming in a project that uses Agile Work Item Templates. Now, there is some history of the code that we want to keep.
Also, we want to change to a customized CMMI template, so it is close to CMMI, but customized, with slightly different work items, also some new/removed ones (for testing purposes, we set it up in a different project).
How can we now merge the source (and history) from the one project with the work items from another project?
From my understanding, you could simply export/import the work item types, but then, all the reports and queries as well as the dashboard would not get updated properly as well? So all scenarios we can come up with now result in a loss of version history (simply importing the current state of the source into newly created project using CMMI and then updating the work items).
Is there a better solution?
(using TFS 2010 and VS 2010)
edit: some useful information to be found here: http://blogs.msdn.com/b/willy-peter_schaub/archive/2011/05/17/tfs-integration-tools-where-does-one-start-part-3-dust-has-settled-did-it-work.aspx - like me, you will probably especially run into trouble with the ProcessBuildTemplates
Have you considered using the TFS Integration Tools? I'm not sure about the successful migration of work items for Team Projects using different templates, but I've been able to successfully migrate code with its history between Team Projects.