@Stalen: Hi Stalen, I could not agree more. Weird was a bad choice of words. The point we were trying to make was although we use VSTS for 48 hours before we release to the next ring we do not test every scenario.
"In that deployment, we pulled in version 5.1.4 of the System.IdentityModel.Tokens.Jwt library. This library had a performance regression in it that caused CPU utilization on the SPS web roles to spike to 100%."
Taking a dependency is not like adding a feature you can turn on or off. Either you take the dependency or you do not.
@David_Lean: I could not agree more. As I said in the video I hope people don't go crazy with this. When I was a consultant I spent a lot of my time talking customers out of customizing the template. Take the time to really learn why the template is the way it is before you change it.
Ask yourself why are we moving from where we are now to VSTS? The answer normally is because the tool/process you have today is lacking. So why customize VSTS back to the tool you are leaving?
The out of the box process templates are great and have been shaped over a long period of time. They have best practices and years of team experiences baked in.
After sitting with a customer and understanding why the made the customization I realized what they wanted was already in the template they just did not know how to use it.
@Dave Wilson:I don't think they meant the actual deployment takes 24 hours. It sounds like the feature(s) sit in a ring for 24 hours before the next ring gets the feature(s).
That is correct. We actually let the code bake in Ring 0 for 48 hours before the deployment to the next ring. Munil and I just recorded another episode today (being produced) where we go into more detail.