Engineering process at microsoft
1 / 13

Engineering Process at Microsoft - PowerPoint PPT Presentation

  • Uploaded on

Engineering Process at Microsoft. Dmitri Gavrilov Principal Software Development Lead Exchange Server. Agenda. Roles Career paths Product release cycle Tools. Roles. Three main roles: dev , test, product management Product Manager (PM): Owns scenarios Does not write code

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Engineering Process at Microsoft' - briar-harvey

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Engineering process at microsoft

Engineering Processat Microsoft

Dmitri Gavrilov

Principal Software Development Lead

Exchange Server


  • Roles

  • Career paths

  • Product release cycle

  • Tools


  • Three main roles: dev, test, product management

  • Product Manager (PM):

    • Owns scenarios

    • Does not write code

    • Interaction with customers, other teams

    • Writes functional specs

  • Dev (SDE):

    • Owns product code

    • Fixes product bugs

    • Writes design specs

  • Test (SDET):

    • Owns product quality

    • Writes test code and fixes test bugs

    • Writes test specs

Additional roles
Additional Roles

  • Managers

    • Lead, Manager, Director/PUM/GM

  • Executive (a hierarchy of VPs)

  • Architects

    • Super-smart individual contributors

  • Contractors

    • Manual testing/deployment/operations

    • Hourly pay, can only work 9 months out of 12.

More additional roles
More Additional Roles

  • User Experience/docs/help writers

  • Support

    • Escalation Engineers (frontline support, mostly in India, answer FAQs)

    • Support Engineers (second line of defence, know product well, can solve most problems)

    • Critical Problem Resolution Engineers (virtuoso debuggers)

    • Premier Field Engineers (dedicated to important customers)

  • Product Marketing

  • Sales

Career paths
Career Paths

Individual Contributor (IC)





Product release cycle
Product Release Cycle

  • Milestones (6-9 months)

    • MQ (quality)

      • Dev/Test: fix postponed items from prev release

      • PM: Prioritize scenarios

    • M1-Mn (dev milestones)

      • Dev/Test/PM: Implement features

    • MP (polish)

  • Later milestones are released to external testers:

    • Internal testing (dogfooding)

    • Public Betas

    • Release Candidate

    • RTM/RTW (release to manufacturing/web)

  • SE (Support Engineering): hotfixes, service packs

Bug bar
Bug Bar

  • Criteria for taking/not taking bug fixes

  • There are always more bugs in the product

  • Do you fix them now or in the next milestone/release?

  • Bug bar is raised towards the end of milestone

  • Highest setting just before RTM

  • After RTM, the bar goes down somewhat

    • Safer to release a hotfix to a set of customers that need it

    • Hotfixes are rolled into service packs

  • When bar is high, bugs are triaged/approved by the War Team (release management people)

    • You come to war and defend your bug: prove why it meets the bar.

Bug bar example
Bug Bar Example

  • High

    • High impact or frequent crash/hang, serious perf degradation, scale, config that will prevent production

    • Core scenario with high impact with no reasonable workaround

    • Data corruption or loss

    • RC blockers or RC failures

    • Very high impact supportability bugs that could save lots of time and money down the road

    • High impact globalization/localization issues

    • DOA and Test Pass blockers

    • CPX issues that prevent from shipping (Policheck, API scan, etc)

    • Security Issues rated as “Critical” based on the SWI guideline

  • Medium

    • Critical partner dependency issues (including other component teams, ExRAP and PSS)

    • Regressions

    • Functional behavior that is clearly against the design

    • Security issues rated as “Moderate” based on the SWI guideline

    • Supportability issues

  • Low

    • Code cleanups

    • Performance improvements beyond the stated goals

    • DCRs that are not essential to E12 SP1

    • Branding

    • Bug with an easy workaround

Tools bug tracking
Tools: Bug Tracking

  • Product Studio: database of bugs

  • Tree of components

  • Bug types: code bug, Design Change Request, Work Item, Customer Escalation, etc…

  • Bug lifetime:

    • Opened

    • Triaged by component triage team, assigned to a dev

    • Dev works on the fix

    • Tester verifies the fix

    • (optional) Bug is marked as ReadyToCheckIn, to be approved by war

    • Dev checks in the fix, resolves the bug

    • Tester verifies the bug is fixed, closes the bug

  • Mgmt uses bug database to track progress

  • Bug resolution: Fixed, NotRepro, Duplicate, WontFix, Postponed, External.

Tools source change management
Tools: Source Change Management

  • Database of source code: Source Depot

  • To work on a file, you have to check it out

  • Multiple people can check out a file

  • At check in, you may need to merge with other people’s changes, resolve conflicts

  • Change history is preserved (incremental changes)

  • Checkins are associated with bugs

  • Branches are super powerful concept

    • One primary product branch

    • Code forked near milestones

Tools automation
Tools: Automation

  • Smoke

    • Automated test running system

    • Smoke must be run before checkin

    • Builds product with your changes

    • Deploys on multiple test topologies

    • Runs tests

    • Tests are prioritized, depending on which code is changed

  • TopoBuilder

    • Automated topology deployment

    • Topologies: from single machine to complex multi-domain multi-machine topologies

    • Quotas

    • Lifetime management: machines are automatically reclaimed into the common pool after a while.