{"id":12346,"date":"2016-10-13T09:26:37","date_gmt":"2016-10-13T14:26:37","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/bharry\/?p=12346"},"modified":"2019-02-16T22:46:10","modified_gmt":"2019-02-16T22:46:10","slug":"vs-team-services-update-oct-12","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/bharry\/vs-team-services-update-oct-12\/","title":{"rendered":"VS Team Services Update – Oct 12"},"content":{"rendered":"

Before I get to talking about this update let me talk about a change in the way we are announcing updates…\nIt takes a while for an update to roll out across the entire service.\u00a0 That is by design and it is part of our strategy to control the damage from any bugs we miss in the testing process.\u00a0 Our deployment process is currently divided into 5 “rings”.\u00a0 The first (we call ring 0) is our own Team Services instance – the one the Team Services team uses to build Team Services.\u00a0 The second is\u00a0a small public instance with external customers on it and the rings grow to more and more public instances.\nWhen we deploy a sprint release to a ring, we wait for 24 hours to monitor it and see if any issues arise and fix them before rolling to the next ring.\u00a0 So, assuming we have no issues that extend the 24 hour “observation time”, it takes us at least 5 days to do the deployment.\u00a0 Sometimes we have issues and it takes 6, 7 or 8 days.\nA sprint ends every 3rd Friday.\u00a0 The first production deployment (ring 0) generally happens by Wed or Thurs of the week following the sprint end.\u00a0 Because we don’t like to deploy to ring 1 on a Friday and risk not being here for issues over the weekend, we usually wait until Monday of the second week to roll out ring 1.\u00a0 So then, ring 2 – Tuesday, …, ring 4 Thursday and the deployment is finished and everyone has everything by Friday of the second week.\u00a0 And then we go straight into finishing up the work for the following sprint on the 3rd week and start all over again\u00a0– it’s never ending \ud83d\ude42\nSo when do we notify customers that we’re making an update?\u00a0 My philosophy has generally been that\u00a0I don’t want people seeing new features roll out without being able to find release notes\/docs describing them.\u00a0 But I also have resisted rolling out release notes for changes that no one can see – it just creates anxiety about why I can’t have it now.\nSo, our policy has been to\u00a0publish the release notes when the deployment to ring 1 (the first public ring) is complete.\u00a0 Of course, as we’ve added more rings and the deployment has stretched out, an increasing number of customers do end up seeing release notes before the features go live in their accounts and it hasn’t created a huge problem.\nOver the past few months, we’ve been getting a bunch of feedback, particularly from our larger customers with hundreds or thousands of Team Services users, that they would like to know what’s coming sooner.\u00a0 They don’t like being surprised when stuff just shows up and they need a little time to investigate what the changes mean for them and whether or not they need to send additional communication to their teams.\nTo honor that request, we are experimenting with changing our publishing process.\u00a0 We have started publishing the release notes as soon as they are ready\u00a0– which generally means the middle of the 1st week after a sprint end, around the time ring 0 is deployed, but before *any* external customer can actually see the changes.\nThat is why our sprint 107 release notes were published yesterday afternoon and I am blogging about it today, despite the fact that none of you have access to any of it.\u00a0 We hope this, combined with the more course grained roadmap <\/a>that we publish will meet the needs of people looking for more forewarning of changes.\u00a0 We also hope that people can wrap their head around the update announcements well before availability (on average, about a week before).\nSome people have asked for even more forewarning and, for now, I don’t have any solution for that.\u00a0 Our roadmap gives a longer term picture (6 months) of the big things we are working and our release notes, now, give a 1 week preview of imminent changes.\u00a0 Given our backlog based development methodology, anything between those two granularities is hard to do and likely to have a lot of errors.\nAs always, feedback is welcome.\nSo, on to Sprint 107 updates…\nSprint 107 is delivering quite a few updates and some of them are pretty darned nice.\u00a0 The biggest visual change is that we are flipping the new navigation structure on by default.\u00a0 If users aren’t ready for the change yet, they can still turn it off but we’re going to remove that ability before too long and everyone will be on the new nav experience.\nProbably the most helpful set of changes are the version control ones – lots of very nice UX improvements and new features.\u00a0 The Cherry-pick and revert additions are very nice.\u00a0 The new file\/folder quick search is small but a really nice, snappy experience.\nThe Azure continuous delivery enhancements are just one step out of many in the journey we are on over the next few months to create a truly impressive and simple\u00a0Azure CI\/CD capability.\u00a0 Stay tuned for more every sprint.\nThere’s lots of other nice improvement that I don’t mean to downplay.\u00a0 Check out the release notes <\/a>for full details.\nBrian<\/p>\n","protected":false},"excerpt":{"rendered":"

Before I get to talking about this update let me talk about a change in the way we are announcing updates… It takes a while for an update to roll out across the entire service.\u00a0 That is by design and it is part of our strategy to control the damage from any bugs we miss […]<\/p>\n","protected":false},"author":244,"featured_media":14617,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[9],"class_list":["post-12346","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-vs-team-services"],"acf":[],"blog_post_summary":"

Before I get to talking about this update let me talk about a change in the way we are announcing updates… It takes a while for an update to roll out across the entire service.\u00a0 That is by design and it is part of our strategy to control the damage from any bugs we miss […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/posts\/12346","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/users\/244"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/comments?post=12346"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/posts\/12346\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/media\/14617"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/media?parent=12346"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/categories?post=12346"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/tags?post=12346"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}