Change Details

//I'm keeping this task on the low visibility, because I want some high-quality feedback before exposing the concept to the general public. Please add anyone you think would be good to add here. I've CCed some people I vaguely remember chatting with about this at some point. // We're looking for a Release system, and I'd like to have some feedback about which parts of this might match other parts of Phabricator and which parts may be interesting to the upstream (Starmap or otherwise). I'd also be interested in cooperation with other teams, where applicable. First, some background: - We're not using Phabricator yet at our company. We are "Strongly Evaluating" it, and started migrating a couple of fringe teams to it this week. If this goes well, I expect we will move ~70 GH repositories to Phabricator by the end of the year (If it doesn't go well, we'll probably migrate to Gerrit, so there's a strong incentive for this to go well :) ) - We have 3-4 different Release Flows, and the whole process is manual. The "Apps" release flow has about 40 apps, so it's ready for automation, code-name "Release Server". Primary use-cases for Release Server: - Codify and trace release procedures. - Answer: When had Commit X hit production / some deployment group? Is commit Y in production now? - Make Release Notes easy to build Details: - A Release has a "Cut point" - a commit hash on a repository (Optionally, several repositories / something completely different) and a name/number/identifier ("3.11") - A Release may have several Artifacts - in all cases I can think of, an artifact is a single file (or archive), and all artifacts in a release have a trivial relationship to each other and to the code: - Under our "Apps" flow, an APK (ZIP file) is created from the source code, and then repeatedly signed several times (More signature files are added to the zip file). - In one Firmware flow, an binary image is compiled from source, and a couple of derivatives are made from it by appending another image and signing. - As artifacts are created / derived outside of the system, they must be verified when they are fed back - e.g., in the Apps flow, the signatures are verified and the signed content is compared to the primary artifact. - A Release Flow has Steps. - A Step might have Actions to take when starting (Harbormaster plan, probably) - e.g., "Deploy to Staging env" or "Deploy to Canary servers", or "Send email to Bob" - A Step will have a "Completion Conditions" - requirements to proceed to the next step. This might be a manual approval ("QA Testing Step") or the creation of an Artifact ("Signature Step") The two high-level objects I see are Release and Workflow: * A **Workflow** is similar to HM Build Plan, except that it's used to track progress instead of driving it. For each step, record (In a conduit-available way) when it started, when it was completed, any who authorized it. * A **Release** is mostly a bag of properties (Custom fields?), with a template ("This is how we cut" and "Expect these kinds of artifacts") and a workflow. An **Artifact** is probably a File or a Phragment, but might have some metadata in the Release object/template. Some of the things I don't have a plan of attack yet (Like verifying uploaded artifacts), and I expect I'm missing some important stuff.

//This text is written after much discussion in this task, so some terms may have changed.// We're looking for a Release system, and hope to fit it into Phabricator. We have 3-4 different Release Flows, and the whole process is manual. The "Apps" release flow has about 40 Android apps. Primary use-cases for Release Server: ----- - Codify and trace release procedures. - Answer: When had Commit X hit production / some deployment group? Is commit Y in production now? - Make Release Notes easy to build (List changes between Releases) Example Release Flows: ------------------------- **Pull Requests**: I love GitHub and hate Phabricator, but I work at a company that has forced me to use Phabricator. I curse the Phabricator upstream daily. I work on a team (the "Backend Server" team) where everyone rightly feels the same way I do. We only want to use Pull Requests. These are the One True Way to build software. - I create a Product called "Backend Server". - I create one Release called "master". - Everyone pushes their local feature branches into the remote, then make "Release Change Request" (aka "Pull Request") to have their changes pulled to `master`. - When a request is accepted, Phabricator automatically merges it to `master`. Just like GitHub! - We reconfigure the header to say "GitHub (Bad Heathen Version)". For a time, there is peace. - After a while we add a "Run Tests" step to the Product, triggered "When a merge is requested". This is better than triggering on commits being pushed because we love pushing our local code into the remote in many different states of brokenness, retaining checkpoint commits, etc. But this is acceptable and we stop merging stuff that breaks the build. - A while later we add a "Deploy to Production" step to the product, triggered "When Deploy is Clicked". - Eventually we move that to "When Release is Updated" so that the thing deploys after every pull request is merged. **Facebook-Style Cherry-Picks / Phabricator-Style Stable / Backporting**: I am the Phabricator upstream and have a long-lived `stable` branch. - I create a "Phabricator" Product, and an "Arcanist" product and a "libphutil" product. - During the week, after fixing a bad bug I merge it into "stable" using the release tool ("Release Change Request" for a single commit). This helps keep track of what got merged. - Maybe "stable" is a single Release or maybe we cut a new one every week. Probably the former at first and then the latter once we get bigger. - Every time "stable" gets updated, Harbormaster starts rolling it across all servers **Binary Release**: My Release is sent to users in a box via the Post [Installed on my Enterprise servers] -- I create a new numbered Release every Wednesday, cut from `master`. -- Harbormaster compiles the whole thing as "3.11 RC1" and installs it on some Test environment -- QA runs some tests, finds some bugs -- I make a new "Release Change Request" to cherry-pick single commits to fix the bugs. Rebuild and deploy. -- I Freeze the Release, not allowing any more changes. If we finds more issues, I create a new Release. -- HM Builds "3.11 Final" -- HM asks for QA to sign off the release, and then automagically sends it to the printers [Starts rolling servers]. Details / Plans ---- We'll be taking some elements from Pipelines (https://github.com/PageUpPeopleOrg/phabricator-pipeline), and mostly use Releeph and Harbormaster. - A "Release" is the object currently known as Releeph Branch. We'll rename it, augment it with some more information, and maybe detach it from vcs branches. -- A Release is a HM Buildable - "Release Plan"/"Product Line" is the template for a Release. It will define: -- Several HM Build plans, to run at different occasions (Similar to Pipeline): Triggers for Cut, New Change, Update, Deploy, etc. -- Maybe instructions about "how to cut", "how to version" -- In my example, all 40 apps will use a single "Product Line" template for their releases - A Release may have several Artifacts - these will be either Files or Phragments or HM Artifacts. - A "Workflow" is just a Harbormaster Build. -- We'll add a "Wait For User Approval" step, to allow tracking manual steps (Probably end up using Quorum T9515). - Release Change Request object is essentially Releeph Pull Requests, but with some pending changes. - Probably rename "Releeph" to something else, or maybe write a new thing (Depending on Releeph's code state).

//I'm keeping this task on the low visibility, because I want some high-quality feedback before exposing the concept to the general public. Please add anyone you think would be good to add here.This text is written after much discussion in this task, I've CCedso some people I vaguely rememberterms may have chatting with about this at some point. nged.// We're looking for a Release system, and I'd like to have some feedback about which parts of this might match other parts of Phabricator and which parts may be interesting to the upstream (Starmap or otherwise). I'd also be interested in cooperation with other teams, where applicablehope to fit it into Phabricator. First, some background: - We're not using Phabricator yet at our company. We are "Strongly Evaluating" it, and started migrating a couple of fringe teams to it this week. If this goes well, I expect we will move ~70 GH repositories to Phabricator by the end of the year (If it doesn't go well, we'll probably migrate to Gerrit, so there's a strong incentive for this to go well :) ) - We have 3-4 different Release Flows, and the whole process is manual. The "Apps" release flow has about 40 apps, so it's ready for automation, code-name "RThe "Apps" release Server"flow has about 40 Android apps. Primary use-cases for Release Server: ----- - Codify and trace release procedures. - Answer: When had Commit X hit production / some deployment group? Is commit Y in production now? - Make Release Notes easy to build Details: - A Release has a "Cut point" - a commit hash on a repository (Optionally, several repositories / something completely different) and a name/number/identifier ("3.11") (List changes between Releases) Example Release Flows: - A Release may have several Artifacts - in all cases I can think of, an artifact is a single file (or archive), and all artifacts in a release have a trivial relationship to each other and to the code:------------------------ **Pull Requests**: I love GitHub and hate Phabricator, but I work at a company that has forced me to use Phabricator. I curse the Phabricator upstream daily. I work on a team (the "Backend Server" team) where everyone rightly feels the same way I do. We only want to use Pull Requests. These are the One True Way to build software. - Under our "Apps" flow, an APK (ZIP file) is created from the source code, and then repeatedly signed several times (More signature files are added to the zip file)I create a Product called "Backend Server". - In one Firmware flow, an binary image is compiled from source, and a couple of derivatives are made from it by appending another image and signing create one Release called "master". - As artifacts are created / derived outside of - Everyone pushes their local feature branches into the systemremote, they must be verified whenthen make "Release Change Request" (aka "Pull Request") to have they are fed backir changes pulled to `master`. - e.g.- When a request is accepted, in the Apps flow,Phabricator automatically merges it to `master`. the signatures are verified and the signed content is compared to the primary artifact.Just like GitHub! - A Release Flow has Steps - We reconfigure the header to say "GitHub (Bad Heathen Version)". For a time, there is peace. - A Step might have Actions to take when starting (Harbormaster plan,fter a while we add a "Run Tests" step to the Product, triggered "When a merge is requested". This is better than triggering on commits being pushed because we love pushing our local code into the remote in many different states of brokenness, retaining checkpoint commits, etc. probably)But this is acceptable and we stop merging stuff that breaks the build. - e.g.,- A while later we add a "Deploy to Staging env" or "DeployProduction" step to Canary servers"the product, or "Send email to Bob"triggered "When Deploy is Clicked". - A Step will have a "Completion Conditions" - requirements to proceed to the next step. This might be a manual approval ("QA Testing Step") or the creation of an Artifact ("Signature Step") The two high-level objects I see are Release and Workflow:Eventually we move that to "When Release is Updated" so that the thing deploys after every pull request is merged. **Facebook-Style Cherry-Picks / Phabricator-Style Stable / Backporting**: I am the Phabricator upstream and have a long-lived `stable` branch. * A **Workflow** is similar to HM Build Plan, except that it's used to track progress instead of driving it. For each step, record (In a conduit-available way) when it started - I create a "Phabricator" Product, and an "Arcanist" product and a "libphutil" product. - During the week, when it was completed,after fixing a bad bug I merge it into "stable" using the release tool ("Release Change Request" for a single commit). any who authorized itThis helps keep track of what got merged. * A **Release** is mostly a bag of properties (Custom fields?) - Maybe "stable" is a single Release or maybe we cut a new one every week. Probably the former at first and then the latter once we get bigger. - Every time "stable" gets updated, with a template ("This is how we cut" and "Expect these kinds of artifacts") and a workflow.Harbormaster starts rolling it across all servers An **Artifact** is probably a File or a Phragment**Binary Release**: My Release is sent to users in a box via the Post [Installed on my Enterprise servers] -- I create a new numbered Release every Wednesday, cut from `master`. -- Harbormaster compiles the whole thing as "3.11 RC1" and installs it on some Test environment -- QA runs some tests, finds some bugs -- I make a new "Release Change Request" to cherry-pick single commits to fix the bugs. Rebuild and deploy. -- I Freeze the Release, not allowing any more changes. If we finds more issues, I create a new Release. -- HM Builds "3.11 Final" -- HM asks for QA to sign off the release, but might have some metadata inand then automagically sends it to the Release object/templateprinters [Starts rolling servers]. Some of the things I don't have a plan of attack yet (Like verifying uploaded artifacts)Details / Plans ---- We'll be taking some elements from Pipelines (https://github.com/PageUpPeopleOrg/phabricator-pipeline), and mostly use Releeph and Harbormaster. - A "Release" is the object currently known as Releeph Branch. We'll rename it, augment it with some more information, and maybe detach it from vcs branches. -- A Release is a HM Buildable - "Release Plan"/"Product Line" is the template for a Release. It will define: -- Several HM Build plans, to run at different occasions (Similar to Pipeline): Triggers for Cut, New Change, Update, Deploy, etc. -- Maybe instructions about "how to cut", "how to version" -- In my example, all 40 apps will use a single "Product Line" template for their releases - A Release may have several Artifacts - these will be either Files or Phragments or HM Artifacts. - A "Workflow" is just a Harbormaster Build. -- We'll add a "Wait For User Approval" step, to allow tracking manual steps (Probably end up using Quorum T9515). - Release Change Request object is essentially Releeph Pull Requests, but with some pending changes. - Probably rename "Releeph" to something else, and I expect I'm missor maybe write a new thing (Depending some important stuffon Releeph's code state).