@PhilBolduc: Good question Phil! This is primarily just a naming convention as you described. We recently added a feature in VSTS whereby you can check a box to delete the topic branch when you complete a PR. (When you click "Complete Pull Request" you'll see it on the next dialog)
While the option to secure a branch/repo exists in VSTS/TFS, we don't typically lock things down. Topic branches are wide open, and there are valid reasons where you might be collaborating with somebody on a change that you might need to go edit their topic branch contents. I can't think of a time when somebody accidentally or maliciously changed somebody else's topic branch contents, but since all these changes are ultimately logged in VSTS/TFS there isn't much of a concern here.
Where we DO enforce security (by way of branch policies) is in the master branch. Note that we don't apply ACL's to the master branch, but instead we rely on the branch policies screen (which I showed in the demo) to define the quality gates whereby changes need to flow into main. This implicitly guarantees security because there are specific reviewers who have to approve changes into main.
@orloffm:That's fair feedback. We tend to use these Foundational sessions as an annual update for the things our team is working on related to ALM / DevOps. It just so happens that for this cycle the bulk of our innovation has happened on VSO, although I did cover a few things which are specific to TFS today (like our Release Management tooling).
Thanks everybody for the outpouring of very nice comments! We are going to miss doing the show every week but I'm sure we'll be back from time to time. You are in very good hands now with Nikola, Vlad, Jeremy, Nisha and of course Greg who has been with TWC9 since the very beginning.
@dhollon: Visual Studio Online provides you with a place to store your source code and manage your projects. I would say anecdotally that yes, the vast majority of customers I speak to are practicing some form of Scrum and using continuous integration as well. I would encourage you to check out our Get Started tutorials which detail some of the specific tasks VSO can help you with. Here's a specific topic on Continuous Deployment to Azure.
Today as you probably know there is no integration between our on-premises Release Management solution and Visual Studio Online. If you want to use Visual Studio Online but still take advantage of Release Management on premises, I have seen some customers set up integration bridges between the two. This is fairly straightforward to do if you are using Git. So for example you would do your day-to-day work in VSO, then set up a mirror between the VSO Git repo and an on-premises TFS server's Git repo. You could then check into VSO, mirror your changes to TFS, trigger a build, and have RM deploy it.
In a scenario such as this you would be required to have user licenses for VSO and TFS, as well as a TFS server license, and the appropriate Release Management deployment licenses. If you already have MSDN Subscriptions then this would cover you for the user licenses and TFS server license. If you had VS Ultimate licenses this would also grant you an allocation of Release Management deployment licenses.
Feel free to keep the Channel 9 conversation going if I didn't fully answer your question, although I also wanted to point you at the Visual Studio Licensing Whitepaper which might be helpful.