VS Team Services Update – Oct 12
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. That is by design and it is part of our strategy to control the damage from any bugs we miss in the testing process. Our deployment process is currently divided into 5 “rings”. The first (we call ring 0) is our own Team Services instance – the one the Team Services team uses to build Team Services. The second is a small public instance with external customers on it and the rings grow to more and more public instances. When 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. So, assuming we have no issues that extend the 24 hour “observation time”, it takes us at least 5 days to do the deployment. Sometimes we have issues and it takes 6, 7 or 8 days. A sprint ends every 3rd Friday. The first production deployment (ring 0) generally happens by Wed or Thurs of the week following the sprint end. 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. So then, ring 2 – Tuesday, …, ring 4 Thursday and the deployment is finished and everyone has everything by Friday of the second week. And then we go straight into finishing up the work for the following sprint on the 3rd week and start all over again – it’s never ending 🙂 So when do we notify customers that we’re making an update? My philosophy has generally been that I don’t want people seeing new features roll out without being able to find release notes/docs describing them. 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. So, our policy has been to publish the release notes when the deployment to ring 1 (the first public ring) is complete. 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. Over 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. 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. To honor that request, we are experimenting with changing our publishing process. We have started publishing the release notes as soon as they are ready – 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. That 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. We hope this, combined with the more course grained roadmap that we publish will meet the needs of people looking for more forewarning of changes. We also hope that people can wrap their head around the update announcements well before availability (on average, about a week before). Some people have asked for even more forewarning and, for now, I don’t have any solution for that. 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. Given our backlog based development methodology, anything between those two granularities is hard to do and likely to have a lot of errors. As always, feedback is welcome. So, on to Sprint 107 updates… Sprint 107 is delivering quite a few updates and some of them are pretty darned nice. The biggest visual change is that we are flipping the new navigation structure on by default. 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. Probably the most helpful set of changes are the version control ones – lots of very nice UX improvements and new features. The Cherry-pick and revert additions are very nice. The new file/folder quick search is small but a really nice, snappy experience. The 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 Azure CI/CD capability. Stay tuned for more every sprint. There’s lots of other nice improvement that I don’t mean to downplay. Check out the release notes for full details. Brian
Light
Dark
0 comments