Experiment on the test phab instance with ways to update tickets when a new iOS alpha build is deployed. Regardless the means, the end could be that deployed tickets are associated with an "iOS Deployed" project, whose default column is "Alpha." It can then be the team's responsibility to manually move tickets into "Beta" and "App Store" columns as they move through the process.

Some different approaches are outlined below:

• Use herald rules to detect when a new "alphas/" tag is pushed, and crawl diffusion history to mark tickets associated w/ branches as deployed (e.g. branch feature/blah/T12345 was merged, so T12345 should be associated w/ the "iOS Deployed" project
  • Pros:
    • Usable by other teams
    • Lives in Phab
  • Cons:
    • Might be hard to parse relevant tickets that need to be updated
• Use the Phabricator/Conduit Ruby client to manually update tickets from CI (e.g. implement as a lane in fastlane which is run from Jenkins)
  • Pros:
    • All information is available at runtime (git history, current build, last successful build, etc.)
  • Cons:
    • Hard to leverage from other teams