Glen Eustace

My feedback

  1. 18 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    We do multiple deployments a day, this is very challenging to do in a services world, especially for the cloud part: the portal and multiple other parts of the online service can change and be redeployed dozens of times each day, every day, on a typical week when developers check in new code, this goes thru a bunch of automated validation, and then gets pushed out.
    We have ability to show/hide new features to selected tenants/workspaces – but there are a lot of teams that independently contribute to the portal and system for various scenarios, and check in and deploy their changes independently thru automated workflows.

    We intentionally go ‘slower’ with the Intelligence Packs – because we know that they can affect on-premises. Those are generally pushed out at a slower cadence, but can still happen a few different times in the same week; the deployment mechanisms are similar, but…

    An error occurred while saving the comment
    Glen Eustace commented  · 

    I don't believe there is any right answer for this, we haven't come up with one anyway. We have now been bitten twice with IP pushes that have impacted our production environment. We do appreciate that MS are taking as much care as possible with their releases but there is always a risk that something will break. From our perspective, we lose credibility as we have tried hard to get SCOM deployed and have assured people during deployment that in most cases adding monitoring has little or no impact on production services. When a service is then impacted by an IP push, which we didn't initiate and therefore hasn't gone through our change management process, SCOMs reputation suffers as it is seen as a system that breaks things.

    Glen Eustace supported this idea  · 

Feedback and Knowledge Base