Change Details

//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).

//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 movable-press-company [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).

//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 printersmovable-press-company [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).