Share via

ALM Rangers Dogfooding – Code Review and Build process

  • Article

As part of our dog fooding we have been working on improving the Quality Bar, Definition of “DONE” and knowing when it is safe to sleep peacefully, project principles and more recently code reviews with the overall objective of shipping better solutions and creating happier users.

Updated: 2014-04-25 – Distinguish between minor and major change.

WARNING: This post is a journal of how we are dog fooding our environment. It is intended as transparent information sharing and should not be mistaken for guidance. We are intentionally focusing our teams to use what come with Visual Studio and Team Foundation Service out-of-the-box to ensure we eat our own dog food Smile

Overview

In the current vsarUnitTestFx project, which has the quest of “Better Unit Testing with Test Code Generation” we have settled down using a basic branching scenario with a main and release branch, as defined in the Branching and Merging Guide (https://aka.ms/treasure18).

image … we have moved away from a dev and feature branches for most projects, unless we require additional isolation.

Our main branch is protected by two checkpoints:

  1. Gated check-in, to ensure that submitted changes merge and build successfully in our Team Foundation Service home.
    image
  2. Code review is performed by the product owner, dev lead, project lead and the team.
    • Major change or milestone
      For major milestones, for example ALPA, BETA, V1 or a potentially code/feature breaking change, the current dog fooding rule is to do a code review and then do a gated check-in.
      image
    • Minor change and no milestone
      For minor changes, which are unlikely to break code or features, the current dog fooding rule is to do a gated checkin and start a code review in parallel. This is to ensure that the team is not blocked for potentially 48h (see below) if reviewers are slow to respond.
      image
    • What is reviewed?
      1. Code Quality -Raising the Quality Bar for Tooling (Part 1)
      2. Adherence to acceptance criteria
      3. Coding concepts, style … learning from others
            

Code Reviews … as currently defined and used by the team

  • We are using the Visual Studio 2012 code review feature in our Team Foundation Service home. The intent is to dog-food the feature and give real-world feedback to the product team.
  • We are involving the following personas as code reviewers at the time indicated:
    Team Member When Block Review Focus
    Product Owner Closing Epic Yes

    Verify PG-level code quality, PG alignment and be in a position to sign-off associated Epic.
    Dev Lead Closing PBI Yes

    Verify code and guide team as dev lead. Focus on feature alignment and quality bar.
    Project Lead Closing PBI Yes

    Verify Ruck-level code quality, feature alignment and support DL where needed. Raising the Quality Bar for Tooling (Part 1)
    Quality Check Closing Epic Yes

    Verify Ruck-level code quality and perform an independent code quality review.
    Everyone Always 48h For maximum transparency loop in everyone.

 

  • We usually include the entire team reviewers for maximum transparency, but their review feedback may not be required for task closure. As per table only the code reviews by product owner, project lead, dev lead and quality check SME are required and blocking. The rest are optional and after 48h (max) the code review request is closed.
  • We do not release bits or move to next objective until all reviews have been completed and PO/DL/PL signoffs have been made. If a blockage is created, the team usually united to extinguish any fires and blockers as a team.

For other dog-fooding posts, see https://blogs.msdn.com/b/willy-peter_schaub/archive/tags/dogfooding/.

ACRONYMS: PO=Product Owner, PL=Project Lead, DL=Dev Lead, PG=Product Group

How do you deal with code reviews?

Comments

  • Anonymous
    May 06, 2013
    The comment has been removed
  • Anonymous
    May 06, 2013
    @Brian, I added a list of the (frustrating) acronyms.