engineering process at microsoft
Download
Skip this Video
Download Presentation
Engineering Process at Microsoft

Loading in 2 Seconds...

play fullscreen
1 / 13

Engineering Process at Microsoft - PowerPoint PPT Presentation


  • 61 Views
  • 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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

agenda
Agenda
  • Roles
  • Career paths
  • Product release cycle
  • Tools
roles
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
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)

Architect

Lead

Manager

Executive

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