Visual Studio Online Update – May 1st
This week, we are deploying our sprint 64 work. You’ll notice that there’s no update on the release notes page. We decided to skip the release notes because there wasn’t really anything new to tell you about. Why? A couple of reasons – we released a bunch of stuff at Build less than a month ago, we have a bunch of work piled up for TechEd week after next and we’ve been working on a bunch of infrastructure work. In fact, if you read the paragraph above carefully, you’ll notice that I said “This week, we are deploying our sprint 64 work”. In previous posts on sprint deployments I’ve almost always said something more like “Today, we…”. There’s a lot more in that change in wording than would appear from a single word difference. It signals a major change in the way we do deployments. Since late last year, we’ve been working on adding support for what we call “scale units”. Basically that’s VS Online service clusters that can be separately deployed and yet be part of the broader VS Online service. I’ve mentioned some of this in previous posts and we’ve made good progress along the way but this sprint was a milestone. It is the first sprint where we are really exercising our new deployment model enabled by scale units. Previously we would upgrade VSO “in a day”. Now an upgrade is a multi-day exercise. We have 4 scale units deployed – 1in Chicago (the one you are used to), 2 in San Antonio and 1 in West Virginia. We currently call them SU0, SU1, SU2 and SU3 – we need better names because I’ll quickly forget which is which 🙂 SU0 is our “Canary” scale unit. It only contains accounts for some of our dogfooding teams, test teams, and customers who have signed up to be on the bleeding edge. It is where we deploy first and make sure that we didn’t miss anything major before rolling it out to the rest of the world. After we deploy SU0, we wait about 24 hours to verify that everything is good. Then we roll out to the next scale unit, and so on. At any point in the roll out process, if we detect issues, we can stop and address them before continuing. As a result deployments are now going to take days to roll out across the totality of our scale units (we’re ultimately going to have dozens of them around the world). The biggest effects on you, I expect, are:
- Even better stability during deployment times.
- A bit of confusion about when new features show up.
I will blog about, and we will post release notes about, new features early in the deployment process. Your account many not actually get the new feature for a couple of days. So, you will be able to read about the new features ahead of being able to experience them. I know I’m going to get a bunch of comments and emails saying “it’s broken; I don’t see the new feature”. I don’t know how to fix that – the alternative being that new features show up in your account before we provide any explanation of what those features are. I think that’s worse. I guess one thing we are going to need to do is be able to communicate to you which scale unit your account is on and where we are in the deployment process. I’ll look into that. At this very moment, your account is on SU1 because that was our original instance and we haven’t started directing customer accounts to other SUs yet. – but, that will happen soon. In the next week or two, we will open up SU2 and start creating a fraction of new accounts there. Now, all that said, we’re wanting to populate the SU0 instance with accounts that are willing to tolerate some risk in being first and help us validate changes as we roll them out. I don’t yet have a way to scale a process by which you could “opt-in” to having an account on SU0 but it is my goal to enable that at some point, assuming there is sufficient interest. Sorry I don’t have more exciting new features to talk about but stay tuned we’ve got some good stuff in the works.
Brian
Light
Dark
0 comments