1 / 13

Engineering Process at Microsoft

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

sommer
Download Presentation

Engineering Process at Microsoft

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Engineering Processat Microsoft Dmitri Gavrilov Principal Software Development Lead Exchange Server

  2. Agenda • Roles • Career paths • Product release cycle • Tools

  3. Roles • 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

  4. 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.

  5. 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

  6. Career Paths Individual Contributor (IC) Architect Lead Manager Executive

  7. 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

  8. 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.

  9. 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

  10. 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.

  11. 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

  12. 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.

  13. Questions?

More Related