I missed a few updates while I was out over the summer but, hopefully, now I’m back on my normal cadence.
This week, we are deploying our sprint 104 work to VS Team Services. It looks to me like it’s a new record on number of items (defined by number of lines in the release notes) released in a sprint. You can read the release notes for all the details.
A few things I want to comment on…
I mentioned in a previous post that we are in the middle of some UI updates. One of the big areas of investment here is in pull requests and you can really see that work coming to life in this deployment. There’s a long list of improvements that make PRs much more productive. Among the most significant is the ability to iterate on updates to a pull request and view diffs of each update to watch the evolution. Our pull request experience has particularly benefited from a *lot* of internal use. We now have almost 10,000 Microsoft engineers using it every month and giving us tons of feedback. I expect we’re going to continue to iterate and improve it for the next several months.
There’s some nice new Jenkins integration that makes using Jenkins builds with Team Services better.
We’ve taken the old “work item templates” Power Tool and made it a part of our web UI. This is one more step toward incorporating all of our Power Tools into the product and eliminating the separate tooling. Work item templates make it easy for you to effectively create “macros” that automate changing several field values with one action. Some of our internal team use this a lot during bug reviews to route, prioritize and schedule bug fixes.
The new experience for dragging attachments on to work items is a really nice improvement over the old browse experience.
As our service continues to grow and mature, we are constantly evolving our ability to understand and improve the reliability and performance that we provide. In this sprint, we introduced a new capability we call “Rate limiting”. Sometimes a user creates some automated tool or script that, due to a bug or just bad design, generates a massive amount of load against Team Services. It essentially amounts to an unintentional denial of service attack and compromises the experience for other customers of the service. We now have the ability to detect these patterns and to apply rate limits that slow them down so they don’t overwhelm the system.
Because people often have no idea that they’ve built a tool that is doing this, we have also created mechanisms to alert account owners that some activity in their account is being rate limited and we provide a web page that will enable them to figure out who/what is generating it and fix it.
Rate limiting is still work in progress and the overall experience will improve in the coming sprints. We are also rolling it out gradually so we can make sure we don’t compromise people doing legitimate things – or at least give them the opportunity to switch to an approach that doesn’t generate so much load.
You can read more about rate limiting in the release notes and even more in the documentation.
I’ve just listed a few personal favorite highlights here. The release notes have the rest. Most of this (except service specific stuff – like rate limiting) will also be showing up on TFS 15 RC2. This is likely the last major batch of new feature work that will go into TFS 15. From here on, it will be more minor refinement, bug fixing, etc. until TFS 15 ships. VS Team services will, of course, continue to march forward, though probably slow down a bit in the next few weeks as we will have a lot of focus on wrapping up TFS 15 work.