EngineeringProductivity/Projects/Conduit: Difference between revisions

EngineeringProductivity/Projects/Conduit (view source)

Revision as of 17:14, 4 April 2017

315 bytes removed , 4 April 2017

→‎High-Level Design and Plan: Update drawbacks and alternatives

Mcote

Confirmed users

1,927

edits

@@ Line 76: / Line 76: @@
 Conduit is designed around multiple small services, with the exception of necessarily larger tools, for example issue trackers and code-review apps.  Services will generally have their own UIs, moving away from our previous model in which automation interfaces have been integrated directly into the larger tools.  Standing up separate UIs for individual services, such as autoland, allows them to be used independent of bug-tracking and code-review tools and also speeds up development, freed from the confines of an extension system.
-Initial services will include autoland and a commit database.  Both functions currently exist but are tightly coupled with Review Board, with much of the code living in the MozReview Review Board extension. These will be split off into small, independent applications.
+Initial services will include autoland and a commit index.  Both functions currently exist but are tightly coupled with Review Board, with much of the code living in the MozReview Review Board extension. These will be split off into small, independent applications.
-In order to both demonstrate the functionality of the new system, and to offer push-to-review and autoland capabilities to teams that prefer to use BMO's patch-review functionality, the newly decoupled autoland and commit database services will then be extended to support BMO as both an issue tracker and code-review tool.  Supporting two code-review tools will likely be a temporary situation as we re-evaluate tooling requirements.
+In order to demonstrate and focus on the push-to-staging and autoland functionality, and to offer push-to-review and autoland capabilities to teams that prefer to use BMO's patch-review functionality, the newly decoupled autoland and commit database services will initially support BMO as both an issue tracker and code-review tool.
 == Drawbacks ==
-The initial benefit of Conduit will largely affect only developers on the team, as we take existing automation features out of Review Board and rework them into independent services.  This means fixes and improvements to MozReview will slow (but not cease) while this up-front work is completed.  However, we believe that this will be more than paid back both by quicker development cycles and by allowing our automation to be used with other tools.
+Extending this functionality to BMO can seem like a step backward, in that BMO's patch-review capabilities are very limited, and part of the purpose of MozReview was to move to a more powerful code-review tool.  However, it was a mistake to bundle the goals of modern code review with engineering-process automation.  By separating out the automation pieces into loosely coupled services, we can concentrate on improving them without changing code-review processes at the same time. Evaluating new code-review tools can be done independently.
-Extending this functionality to BMO can also seem like a step backward, in that BMO's patch-review capabilities are very limited, and part of the purpose of MozReview was to move to a more powerful code-review tool.  However, it was a mistake to bundle the goals of modern code review with engineering-process automation.  By separating out the automation pieces into loosely coupled services, we can concentrate on improving them without changing code-review processes at the same time. Evaluating new code-review tools can be done independently.
 == Alternatives ==
@@ Line 90: / Line 88: @@
 The other clear alternative is the path MozReview was previously on: continuing to develop automation services partially within Review Board, and continuing to improve core Review Board features at the same time. This has been unsatisfactory for the reasons expounded above.
-Another alternative is to use a full tool suite that implements the same level of changeset-based automation that we have (push-to-review, autoland) and that we are working on or planning for (conflict detection, static analysis, etc.).  Solutions in this area are few and far between and often designed with smaller applications in mind. GitHub can be seen as one such alternative, though it lacks critical features like support for confidential issues and patches and has clear integration path with our testing and CI systems.  We are planning some support for GitHub-based workflows, but it cannot be a full replacement for our processes.
+Another alternative is to use a full tool suite that implements the same level of changeset-based automation that we have (push-to-review, autoland) and that we are working on or planning for (conflict detection, static analysis, etc.).  Solutions in this area are few and far between and often designed with smaller applications in mind. GitHub can be seen as one such alternative, though it lacks critical features like support for confidential issues and patches and has clear integration path with our testing and CI systems.  We are planning some support for GitHub-based workflows, but it cannot be a full replacement for our processes.  Similarly, suites like Phabricator offer compelling issue-tracking and code-review tools that we can use in Conduit, but they lack an autoland feature that meets our requirements, as well as the flexibility offered by a repository-based system.
 In general, Firefox is a sufficiently unique, complex, and highly scaled project that it is highly unlikely that there exists any off-the-shelf solution that can fully automate our engineering processes.  However we are always exploring ways that we can avoid duplicating effort.