DevOps at Microsoft

  • Comments posted to this topic are about the item DevOps at Microsoft

  • From the linked MS article:

    We wanted to reduce delays in handoffs between developers and testers and focus on quality for all software created, so we combined the traditional developer and tester roles into one discipline: software engineers. Software engineers are now responsible for every aspect of making their features come to life and performing well in production. This does not mean testing was abandoned, quite the contrary. This meant testing and quality was everyone’s responsibility.

    I would be interested to know how this worked out! Developers writing unit tests is one thing but making them do all testing sounds like a sure-fire way to lose good team members.

  • I like much of what I see from Microsoft, but most of the issues I have with Redmond, aren't technical issues or a reflection of engineering ability, but management decisions.

  • chrisn-585491 (9/27/2016)


    I like much of what I see from Microsoft, but most of the issues I have with Redmond, aren't technical issues or a reflection of engineering ability, but management decisions.

    I've never worked there but have heard horror stories myself.

  • We are a small shop with half a dozen programmers and as many other IT personnel. We develop software that we only use in house, do not sell. We have a good relationship with all departments and share in the design, development, and testing process. It works well for us.

  • DevOps works when it's intentional; like when IT staff have DevOps as part of their official job description, are separate from the development team and have their own manager. DevOps isn't simply an application developer who's been granted an admin account so they can be the go-to guy for production deployments and account management.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • funbi (9/27/2016)


    I would be interested to know how this worked out! Developers writing unit tests is one thing but making them do all testing sounds like a sure-fire way to lose good team members.

    Depends. I think expectations are important. If you know you're doing testing, you might be OK. Compensation matters as well.

    I do think that there does need to be a separate test group in most places. MS has the advantage of being able to use customers under the beta flag. People are always willing to try new things.

  • Iwas Bornready (9/27/2016)


    chrisn-585491 (9/27/2016)


    I like much of what I see from Microsoft, but most of the issues I have with Redmond, aren't technical issues or a reflection of engineering ability, but management decisions.

    I've never worked there but have heard horror stories myself.

    Forget what you know. Lots has changed.

    I tend to agree that I think management has been poor, but from friends, it seems to be better. Is it great? Time will tell.

  • Eric M Russell (9/27/2016)


    DevOps works when it's intentional; like when IT staff have DevOps as part of their official job description, are separate from the development team and have their own manager. DevOps isn't simply an application developer who's been granted an admin account so they can be the go-to guy for production deployments and account management.

    Don't agree with the first sentence, but I do agree with the last.

  • Steve Jones - SSC Editor (9/27/2016)


    Eric M Russell (9/27/2016)


    DevOps works when it's intentional; like when IT staff have DevOps as part of their official job description, are separate from the development team and have their own manager. DevOps isn't simply an application developer who's been granted an admin account so they can be the go-to guy for production deployments and account management.

    Don't agree with the first sentence, but I do agree with the last.

    OK, how about the first half of the first sentence?

    "DevOps works when it's intentional; ..."

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • That I agree with.

  • Steve Jones - SSC Editor (9/27/2016)


    That I agree with.

    Where I work now, we have a dedicated DevOps team who performs functions like application configuration and support, deployments, automation tooling, etc. I would say that even going back 20 years to my first IT job, I've always performed tasks that are out of the box in addition to my regular role as a developer or DBA. I can do tasks that would fall under the category of DevOps, but I've never operated at the same level of proficiency as someone who is properly trained and supervised in the role. For example, I'm so glad I'm not the go to guy for IIS issues anymore. That's something one has to work with on a regular basis to really know what one is doing with any degree confidence.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • I very much agree with Steve that culture and behaviour has to change if you are going to get the best out of a technique or toolset.

    The building of a reliable build pipeline including scripted infrastructure deployment is not a trivial task but the payback is immense. I can't remember the last time a deployment failed because of environmental differences.

    The bit people have to embrace is that when a mistake is made you learn from that mistake, work out how to test for the situation that allowed the mistake to be made and implement the automated process to detect it as part of the test suite. The range of tests accumulate so that failure is truly exceptional.

    The time wasted on Crucifixion or Lions blamestorming is more productively spent designing out the errors in the process.

    The DevOps disciplines need broad adoption within an IT department otherwise a "DevOps" department will become a bottleneck and may jeopardise the adoption. There will always be specialists but the basic skills should be embedded in the teams so the specialists can focus on the thorny problems.

  • My experience, at my current company at least, has been that the software QA team tests the software (firmware, really) that's used in the products we sell. Applications developed internally that are used by customers but aren't what we "sell" don't get tested by the QA team because QA is perpetually busy with product testing. I've asked executive management to let me hire someone to QA these other applications but it hasn't been approved. I figure I must be doing a really good job at it - I do the development, testing, and production deployments myself.

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply