Go to Qiita Advent Calendar Top
LoginSignup
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 3

フリュー Advent Calendar 2025

@dacchan(だっちゃん)inフリュー株式会社

DeployGate の配布リンクを Github Action で更新する

Posted at

この記事は フリュー Advent Calendar 2025 の3日目の記事となります。

4年目のフリュー Advent Calendar、今年も 3日目の記事を書かせていただきます。


今年は DeployGate のアプリ配布を改善した時の記事にしてみたいと思います。


仕事の中で、DeployGate を使い、社内メンバーへのアプリ配布をしている会社やチームも多くないと思います。
DeployGate での配布の良いところとして、配布対象のアプリのリビジョン管理ができるところなどが挙げられます。

ユーザーは好きなリビジョンを選択することで、様々な状態のアプリでの動作確認ができるので、ちょっとしたデザイン変更の確認から、不具合の動作確認、スプリントレビューの時にみんなで一斉にアプリを触ってもらいフィードバックをもらうことにも活用できます。

アプリをどう配布するか

アプリを配布する方法として、以下の2つの方法があります

  • メンバー配布
    • アカウントを作成し、グループへの追加を行うことで許可された人のみがインストールできる
  • リンク配布
    • 専用の配布リンクを作成し、リンクを知っているユーザーは誰でもインストールできる
    • 一度リンクを配布すれば同じダウンロード先を提供できる（リンクの公開設定もすぐに変更できる）

私が所属しているチームでは、メンバー配布とリンク配布の両方を用途に分けて利用しています。
どのように分けているかというと、以下のようになります。

  • メンバー配布
    • 開発者、SD、UD など、頻繁にアプリのインストールやリビジョンの変更が必要になるメンバー向け
  • リンク配布
    • 頻繁にインストールしないメンバー向け
      • スプリントレビューの時だけインストールしたい
      • UT、グループインタビュー、社内イベント等の時だけインストールしたい

なぜ用途を分けているか？

用途を分けている理由としては「アカウント管理」になります。

契約プランにより登録できるアカウント数は変わりますが、それでも上限は存在します。
そして、だれがどのアカウントを使い、どんな権限をつけるか、アカウントの棚卸しと様々な管理コストがどうしても発生します。（発生しています😔）

アカウントをどのように管理するか？

私たちのチームでは「アカウントを作成する条件」を設けました。内容としては以下になります。

  • アプリ開発メンバー
  • 頻繁にインストール（アップデート）するメンバー
    • QA、SD、UD など

理由として以下のようにしています。

  • アプリ開発メンバー
    • アプリの作成・更新、リビジョンの管理など頻繁に DeployGate の情報更新が必要となるため
  • 頻繁にインストールするメンバー
    • アプリ開発を進めていく中で、機能追加・機能改善やバグ改善の動作確認など、頻繁に発生するアプリのインストール・アップデートが必要となり、その都度リンク配布のリビジョン更新は手間であり、間違いにもつながるため

ただ、まだ条件の抜け漏れなどはありそうなので、運用しながら都度見直しています 💪

リンク配布のリビジョン更新

DeployGate のリンク配布の使い方を簡単に説明すると

  • 専用のアプリ配布ページを作成する
  • 配布ページからダウンロードできるアプリのリビジョンを1つ選ぶ
  • 配布ページのURLをユーザーに連携しインストールしてもらう（QRも用意されています）

このように、かんたん3STEPでユーザーにアプリをインストールしてもらえる環境を整えることができます。
（3ステップは言い過ぎですが、とてもかんたんに作業を進められます、ありがとうございます！）

リンク配布の注意点

リンク配布にもデメリットというか、気をつける点がいくつかあります。
そのなかで、今回の Github Action 化する理由になるのが以下の2点になります。

  • 更新できる権限が admin のみ
  • リビジョン更新は「手動」変更

デメリットとは書きましたが、内容的には「配布ページの管理」としては当たり前のものとはいえそうです。

配布ページの内容を勝手に変更され、よくわからない状態のものになっていると、アクセスしてくるユーザーが困ることにながります。
また、admin 権限にはプロジェクト全体の構成管理の変更権限も付与されるため、すべてのアカウントに admin 権限をつけるという判断も取りづらいです。

複数の開発者がアップロードすることもあるので、様々な状態のリビジョンが存在するため、何が正しいバージョンかどうかは人による管理が必須になる。

これらを解決するために、今回の改善を行うに至りました。

リビジョン更新をどう改善したか

DeployGate には さまざまなAPI が用意されています。
その中に「配布ページ管理API」として 配布ページのリビジョンを更新するAPIが用意されており、このAPIを利用することで外部サービスからの更新も可能となります。

curl \
  --url "https://deploygate.com/api/distributions/${DISTRIBUTION_KEY}/packages" \
  -H "Authorization: Bearer ${API_TOKEN}"  \
  -X POST \
  --form-string "revision=${REVISION}" \
  --form-string "release_note=${RELEASE_NOTE}"

引用: DeployGate Docs - 配布ページのリビジョンを更新する1

最初、DISTRIBUTION_KEY に設定する値の説明が書かれているにもかかわらず、何を設定すれば良いかわからなくて困りました。
DISTRIBUTION_KEY なので、配布に関連するKey情報やトークンなどを設定していたことで、エラーとなっていました。
時間をおいてよくよく見てみると、説明の理解ができ、なぜこんなことに気づかなかったのか悲しい気持ちになったのを覚えています🙄

要は、配布ページとして作成されたURL、仮に https://deploygate.com/distributions/abcd123hogehugapiyopiyo があるとして、このURLの最後である abcd123hogehugapiyopiyo がそれに該当します。

トークンによる一意なサイトを作成していると思われますが、まさかこのURLの一部を使うとは思っておらず、30分ほど悩んでいましたね。説明にも書かれているのに・・・😔

Github Action でどう対応したか

リンク配布ページに設定するリビジョンをAPIを利用して更新できることがわかりました。
次は、Github Action で実行できる環境を作成していきます。

Github Action の対応

on:
  workflow_dispatch:
    inputs:
      distribution_pages:
        description: "配布ページ"
        type: choice
        options:
        - スプリントレビュー
        - UT確認
        required: true
      revision:
        description: "配布リビジョン"
        type: string
        required: true
      message:
        description: "配布メッセージ"
        type: string
        default: ""

jobs:
  updateRevision:
    runs-on: ubuntu-latest

    steps:
      # 必要に応じてSTEPを追加

      # Fastlane を使うので Ruby を準備
      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.2'
          bundler-cache: true

      - name: Update revision
        run: |
          bundle exec fastlane update_revision_for_deploygate \
           api_token:"${{ secrets.DEPLOYGATE_API_TOKEN }}" \
           distribution_key:"${{ github.event.inputs.distribution_pages }}" \
           revision:"${{ github.event.inputs.revision }}" \
           message:"${{ github.event.inputs.message }}"

workflow_dispatch の説明

input 説明
distribution_pages 作成済みの配布ページの名前をリストアップ。リビジョンの更新をどの配布ページに対して行うかを選択する。
revision 配布ページに対して、更新したいリビジョン番号を入力する。
message 配布ページに対して、更新したリビジョンのリリースノート（説明やメッセージ）を表示させるない表を入力する。空文字の場合は空文字で更新されます。

Fastlane の対応

lane :update_revision_for_deploygate do |param|
  distribution_key = Deploygate.distribution_pages["#{param[:distribution_key]}"]

  sh("curl \
    --url \"https://deploygate.com/api/distributions/#{distribution_key}/packages\" \
    -H \"Authorization: Bearer #{param[:api_token]}\" \
    -X POST \
    --form-string \"revision=#{param[:revision]}\" \
    --form-string \"release_note=#{param[:message]}\"
  ")
end

module Deploygate
  ## 配布ページごとの `DISTRIBUTION_KEY` をマッピング情報として管理
  def self.distribution_pages
    {
      "スプリントレビュー" => "hogefugapiyosprintreviewpage",
      "UT確認" => "piyofugahogeutconfirmpage"
    }
  end
end

module Deploygate の説明

配布ページごとの DISTRIBUTION_KEY を管理するために、専用の定義を管理する設計にしました。
理由としては Github Action の input パラメータで type: choice を使う場合「表示値と選択値」を分けた設定ができないためです。

DISTRIBUTION_KEY を選択形式として表示させたとしても、何を指すものかわからないため、それを解決する手段として利用しました。

Fastlane を使用している理由

今回の事例では iOS のアプリ開発のプロジェクトに対して環境を構築しました。
そのため、アプリのビルドや配布などを Fastlane を利用して行なっているため、自動化を行う際の拡張性などを考慮したものになります。

Github Action で「リビジョンの更新だけ」を行う場合は少し大袈裟な設定が必要になるのがネックではありますが、他の Fastlane アクションとの組み合わせはしやすいはずです。

使い方

使い方は簡単で、リポジトリに登録した Github Action の Wokflow に必要な情報を入力して実行するだけです。

必要パラメータを入力させたいため workflow_dispatch にしているので、ブランチの選択項目が出てきてしまうのはUI的には不要な情報になるので残念なところです 😓

「配布リビジョン」に設定する「リビジョン番号」とは、DeployGate にアプリをアップロードされると、リビジョンごとに採番される番号のことで、リビジョン管理画面で表示されている赤枠の # を除いたものがそれに該当します。

引用: DeployGate Docs - リビジョンを管理する2

あとは数秒待てば、実行が完了し配布ページのリビジョンが更新されます。

今後について

Fastlane を使用している理由 で、他の Fastlane の実行と組み合わせるために構築したと書きましたが、今後運用してくなかで利用シーンがなさそうであれば「実行速度」や「管理情報の分散」などのことを考慮して、 Github Action のシェル実行設定として書き換えることも検討しています。

新しく配布ページの設定を追加する際に、2ファイルを変更するのは面倒であり、「DISTRIBUTION_KEY マッピング情報」の表示名で齟齬も発生しやすそうなためです。

さいごに

Gtihbu Action からの実行に変えることで、配布ページのリビジョン更新作業は簡略化できたと思います。
DeployGate の管理画面からもできますが、リンクを辿る操作、リビジョン番号が正しいかの再確認、アカウントの権限問題などによる「できないからやってほしい」などの手間を減らせたと思っています。

現段階では「リビジョン番号を管理画面で一度確認する」作業は残っていますが、今後改善できればと考えています。
あとは、リポジトリごとに複数作る必要が出てくるのも面倒であり、保守運用コストも出てきそうなので、専用のツールなどを作ることも良いかもしれないですね。


それでは、明日以降もアドベントカレンダーをお楽しみください！

  1. https://docs.deploygate.com/ja/docs/api/application/update-revision-of-distribution-page ↩

  2. https://docs.deploygate.com/ja/docs/developer-guide/app/app-revision-list ↩

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?