Team Services Update – Feb 15

Brian Harry

This week we are beginning the deployment of our sprint 113 improvements.  You can read the release notes for details. Among other things, there’s a bunch of nice improvements to the Pull Request experience – we continue to refine and evolve it. We also did a “V2” overhaul of the package management UI.  We think it’s more responsive and simpler.  We certainly appreciate any feedback you have.  For now it is an “opt-in” experience.  Eventually, it will become the default experience. A note on release notes… The way me manage release notes continues to evolve.  Several months ago, we changed our process to post release notes at the very beginning of deployments rather than “in the middle” – meaning you get earlier notice of changes that are coming but you get the notice days, or even a week or more, before the changes actually appear in you account. This sprint we’ve evolved even further.  As we continue on our journey of service decomposition and autonomy, we really no longer have a single deployment wave.  We have many independent services deploying at different times.  Starting this sprint, you should now think of the release notes as describing work that is complete and will be deployed over the next 3 weeks.  I’ve decided on this small decrease in precision rather than publishing lots of smaller release notes.  Until we can actually provide personal release notes for your account, we’ll never get to fully precise release notes because every service takes about a week to deploy across the world, even if nothing goes wrong. As always, I’m open to feedback if you feel I’m making the wrong trade-offs.  The principles I’m currently using are:

  1. Always tell people what’s coming before it shows up in their account.
  2. Don’t tell people something is coming that doesn’t (no release note retractions).
  3. Don’t pepper people with constant release note updates – a 3 week cadence is reasonable.



Discussion is closed.

Feedback usabilla icon