Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Phabricator Introduce

halfrost
January 20, 2016

Phabricator Introduce

halfrost

January 20, 2016
Tweet

More Decks by halfrost

Other Decks in Programming

Transcript

  1. Agenda Phabricator Summary pre-push code review tool —— Differential code

    repository browse tool — Diffusion post-push code review tool —— Audit Other Feature Summary Final
  2. Let’s do it git commit - (arc diff - accept)-

    pull - (arc diff - accept) -push
  3. Review vs Audit Phabricator supports two similar but separate code

    review workflows: Differential is used for pre-push code review, called "reviews" elsewhere in the documentation. You can learn more in Differential User Guide. Audit is used for post-push code reviews, called "audits" elsewhere in the documentation. You can learn more in Audit User Guide. (By "pre-push", this document means review which blocks deployment of changes, while "post-push" means review which happens after changes are deployed or en route to deployment.) Both are lightweight, asynchronous web-based workflows where reviewers/ auditors inspect code independently, from their own machines -- not synchronous review sessions where authors and reviewers meet in person to discuss changes.
  4. How Audit work ? audit request trigger Audit tool primarily

    keeps track of two things: Commits and their audit state (like "Not Audited", "Approved", or "Concern Raised"). Audit Requests which ask a user (or some other entity) to audit a commit. These can be triggered in a number of ways (see below).
  5. audit & commit Required Audits are open audit requests that

    require you, a project you are a member of, or a package you own to audit a commit. An audit request is closed when you approve the associated commit. Problem Commits are commits you authored which someone has raised a concern about in audit. Problem commits go away when you satisfy all the auditors and get them to "Approve" the commit.
  6. Audit Triggers Audit requests can be triggered in a number

    of ways: If you put Auditors: username1, username2 in your commit message, it will trigger an audit request to those users when you push it to a tracked branch. You can create rules in Herald that trigger audits based on properties of the commit -- like the files it touches, the text of the change, the author, etc. You can create an audit request for yourself by commenting on any commit. You can create an Owners package and select "Enable Auditing" (this is an advanced feature which is only likely to be useful for very large teams).
  7. Audit Tips When viewing a commit, audit requests you are

    responsible for are highlighted. You are responsible for a request if it's a user request and you're that user, or if it's a project request and you're a member of the project, or if it's a package request and you're a package owner. Any action you take will update the state of all the requests you're responsible for. You can leave inline comments by clicking the line numbers in the diff. You can leave a comment across multiple lines by dragging across the line numbers. Inline comments are initially saved as drafts. They are not submitted until you submit a comment at the bottom of the page. Press "?" to view keyboard shortcuts.
  8. –Grady Booch,One of the UML founders “The function of good

    software is to make the complex appear to be simple”