最終更新日 2023年08月14日(月)

パイプライン​は、同じコードベースを共有する Heroku アプリのグループです。パイプライン内の各アプリは、継続的デリバリーワークフロー​内の次のいずれかのステージを表します。

• 開発
• レビュー
• ステージング
• 本番

パイプラインは、アプリの複数の環境を管理​するためにきわめて有効です。一般的なパイプラインワークフローには、次のステップが含まれます。

1. 開発者は、コードベースに変更を加えるためのプルリクエストを作成します。
2. Heroku は、そのプルリクエストのレビューアプリ​を自動的に作成し、開発者が変更をテストできるようにします。
3. 変更が準備できると、その変更はコードベースのマスターブランチにマージされます。
4. マスターブランチは、それ以上のテストのためにパイプラインのステージングアプリに自動的にデプロイ​されます。
5. 変更が準備できたら、開発者はステージングアプリを本番にプロモート​し、それをアプリのエンドユーザーから使用できるようにします。

パイプラインの概要ページには、このフローのステージが示され、各ステージのステータスに関するメタ情報が表示されます。たとえば、本番アプリがステージングとは別のコードを実行しているかどうかを確認できます。

パイプラインの作成

Heroku Dashboard での操作

アプリの一覧の右上にある New​ (新規) ボタンをクリックし、Create new pipeline​ (新しいパイプラインの作成) を選択します。

あるいは、アプリの Deploy​ (デプロイ) タブに移動し、そのアプリを含む新しいパイプラインを作成することもできます。

Heroku CLI での操作

CLI からパイプラインを作成するには、pipelines:create​ コマンドを使用できます。このコマンドでは、パイプラインに追加する既存のアプリを指定する必要があることに注意してください。

$ heroku pipelines:create -a example-app
? Pipeline name: example-pipeline
? Stage of example-app: production
Creating example-pipeline pipeline... done
Adding example-app to example-pipeline pipeline as production... done

CLI から、パイプラインの名前と、それに追加するアプリのステージ (development​、staging​、または production​) を指定するよう求められます。

このコマンドのオプションの完全な一覧を表示するには、heroku help pipelines:create​ を使用します。

パイプラインへのアクセス

パイプライン内のアプリは、Heroku Dashboard には個々のアプリとして表示されません。代わりに、個々のアプリを表示するためのドロップダウンを備えた 1 つのパイプラインエントリの一部として表示されます。

パイプラインへのアプリの追加

Heroku アプリは、1 つのパイプラインの 1 つのステージのみに属することができます。

Heroku Dashboard での操作

パイプラインの概要ページから、デプロイステージの横にある + Add app​ (+ アプリの追加) をクリックして、パイプラインのそのステージに既存のアプリを追加します。

Heroku CLI での操作

heroku pipelines:add​ コマンドを使用して、パイプラインにアプリを追加します。

$ heroku pipelines:add example-pipeline -a example-staging-app
? Stage of example-staging: staging
Adding example-staging to example pipeline as staging... done

パイプラインステージの複数のアプリ

パイプラインステージには、複数のアプリを含めることができます。たとえば、本番ステージには、同じバージョンのコードを実行しているが、設定の異なるメインの本番アプリと管理アプリが含まれることがあります。

パイプラインでのデプロイ

パイプラインでは、デプロイされたコードがある環境から次の環境へどのように流れるかを定義できます。たとえば、コードをステージングアプリにデプロイし (これが slug)​ にビルドされる)、後でその同じ slug を本番にプロモート​することができます。このプロモーションフローにより、本番にはステージングでテストされたのとまったく同じコードが含まれ、さらに slug の再ビルドよりはるかに高速にもなります。

プロモーション

特定のパイプラインステージの変更を完全にテストしたら、それに関連付けられた slug をダウンストリームステージのアプリにプロモートできます。

Heroku Dashboard での操作

特定のステージの slug は、パイプラインの概要ページで関連付けられた Promote​ (プロモート) ボタンをクリックすることによってプロモートできます。

ダウンストリームステージに複数のアプリが存在する場合は、slug をどのアプリにプロモートするかを指定できます。

Heroku CLI での操作

CLI から、heroku pipelines:promote​ コマンドを使用して slug をプロモートできます。このコマンドでは、ソースアプリの名前 (-a​) または Git リモート (-r​) を指定する必要があります。

$ heroku pipelines:promote -r staging
Promoting example-staging to example (production)... done, v23
Promoting example-staging to example-admin (production)... done, v54

デフォルトでは、このコマンドは、ソースアプリの slug をダウンストリームステージのすべての​アプリにプロモートします。--to​ オプションを使用して、プロモート先にするこれらのアプリのサブセットを指定できます。

$ heroku pipelines:promote -r staging --to my-production-app1,my-production-app2
Starting promotion to apps: my-production-app1,my-production-app2... done
Waiting for promotion to complete... done
Promotion successful
my-production-app1: succeeded
my-production-app2: succeeded

プロモーション中のリリースフェーズ

slug がプロモートされると、新しいビルドが作成されない場合であってもリリースフェーズ​が実行されます​。

パイプラインの所有権と移動

パイプラインの Web インターフェースと CLI では、パイプライン内のアプリがパイプライン所有者​によって所有される必要があります。この所有者は、パイプラインの Web インターフェースの Settings​ (設定) タブで割り当てることができます。

パイプライン所有者 (通常は Heroku Team) を割り当てることを選択すると、コラボレーションワークフロー内のアクセス許可に関連した一般的な問題が防止されます。これは、所有者がチームメンバーに本番アプリ、ステージングアプリ、開発アプリに対する異なるアクセス権を割り当てたいと考えている場合に特に重要です。

この機能により、パイプライン内のより適切な構造や管理の階層が促進されます。

ユーザーがパイプライン内のアプリを所有している場合、そのユーザーはパイプラインを所有する資格があります。 ユーザーがパイプラインの所有権を引き継いだ場合、Web UI では、そのユーザーが所有していないパイプラインアプリが強調表示され、パイプライン内の外部アプリをパイプライン所有者に移動するための UI が提供されます。

個人が所有しているパイプラインは、その個人がメンバーである Heroku Team (または Enterprise Team) にのみ移動できます。Team が所有しているパイプラインは、そのチームのメンバーである任意の個人に移動できます。 ただし、請求のセキュリティのため、個々のパイプラインを他の個人に直接移動することはできません。

GitHub 同期

ステージングから本番へのプロモーションは優れた機能ですが、GitHub 統合​を使用してステージングに自動的にデプロイすることによって、フローをさらに最適化できます。たとえば、GitHub 上で master​ ブランチが更新され、継続的インテグレーション (CI) テストに合格した場合は常に、ステージングを自動デプロイできます。

レビューアプリ

GitHub を使用している場合は、プルリクエストを使用し、対応するレビューアプリ​を設定することを強くお勧めします。レビューアプリによって使用される dyno とアドオンは、通常のアプリとまったく同じように課金されます。詳細は、「レビューアプリの管理と費用​」を参照してください。

パイプラインと Heroku CI

GitHub を使用している場合は、Heroku Pipelines と容易に統合できる Heroku の視覚的な低設定のテストランナーである Heroku CI​ をオンにすることができます。すべての Heroku Pipeline がすでに CI に対応しているため、パイプラインの Settings​ (設定) タブでこれをオンにするのみです。テストラン期間中の dyno およびアドオンの実行時間には、秒単位の従量課金​で通常料率の料金が発生します。

一時的なアプリのアクセス許可

レビューアプリと CI アプリは、短時間の “一時的な” アプリです。パイプラインのアクセスタブを使用して、ユーザーアクセス許可を設定し、パイプライン内のすべての一時的なアプリへのアクセスを管理できます。このアクセスタブは、Heroku Teams​ および Enterprise Teams​ の “管理者” ユーザーと、個人のアカウントでのパイプライン所有者​から使用できます。

新しいバージョンのレビューアプリでは、Enterprise Teams および Heroku Teams の “メンバー” ロールを持つすべてのユーザーが、"表示"、"操作"、および “デプロイ” アクセス許可での自動参加を通して、レビューアプリに自動的に追加されました。パイプラインアクセスタブにより、自動参加アクセスを管理および変更することが可能になります。自動参加アクセス許可の変更は、Enterprise Teams に対してのみ可能です。Heroku Teams の場合、"メンバー" が自動参加を通して取得する “表示"、"操作"、および "デプロイ” アクセス許可は静的であり、変更できません。

Enterprise Team の既存のパイプラインに対するアクセス許可を編集するには、パイプラインアクセスタブの 「Default permissions for new team members」 (新しいチームメンバーのデフォルトのアクセス許可) セクションにある小さな鉛筆アイコンを選択します。また、自動参加を完全に無効にすることもできます。アクセス許可の変更や自動参加の無効化/有効化は新しいアプリに対してのみ有効であり、以前の設定は変更されません。

新しいパイプラインの場合、デフォルトでは自動参加が有効に設定され、"表示"、"操作"、および “デプロイ” アクセス許可が選択されます。パイプラインを作成するときに、自動参加を無効にしたり、アクセス許可を変更したりできます。

自動参加を通して自動的には追加されないその他のすべてのユーザーについては、手動で追加できます。たとえば、"共同作業者" ユーザーにパイプライン内のレビューアプリと CI アプリへの “操作” アクセスを許可する場合は、このユーザーを “操作” アクセス許可が選択されたパイプラインアクセスタブで手動で追加します。

Heroku Teams​ の場合、アクセス許可は静的であり、変更できないため、自動参加を有効にするときにアクセス許可を選択するオプションはありません。

また、既存のユーザーアクセス許可を編集するオプションもありません。ユーザーには、チーム内のそのロールに基づいて、静的アクセス許可が事前に設定されています。

個人のアカウント​の場合は、より高いチームレイヤーが存在しないため自動参加の概念はありませんが、各パイプラインには、そのパイプライン内のレビューアプリと CI アプリにアクセスできるユーザーを追加するために使用できるアクセスタブがあります。

アクセス許可と機能

パイプラインレベルのアクセス許可は Heroku のアプリアクセス許可​と同じように見えますが、それらの機能は異なり、ユーザーがレビューアプリと CI アプリに対して実行できるアクションに固有のものです。

設計に関する考慮事項

パイプラインは、アプリケーション slug のフローのみ​を管理します。アプリの Git リポジトリ​、環境設定​、アドオン​、その他の環境依存関係は、独立して管理する必要があります。

パイプラインプロモーションを使用したデプロイは、ステートレスビルド​のアプリにのみ推奨されます。環境設定の値を slug にコンパイルするビルド (つまり、ステートフルビルド​) は、プロモートされるときに問題が発生する場合があります。ステートフルビルドのアプリの場合は、代わりに Heroku の標準の Git ベースのデプロイ​または GitHub デプロイ​を使用してください。

slug がプロモートされると、Heroku はそれを何も変更せずにコピーします。ターゲットアプリの環境に合わせて再ビルドされることはありません​。ビルドがビルドアプリのコンテキストから環境に組み込まれている場合、その slug はパイプラインステージ間で移植できなくなります。これは、たとえば、ビルド環境内の URL によって定義された CDN でホストされているアセットをビルドするために Ruby on Rails とアセットパイプラインを使用している場合が考えられます。これは、ビルドアプリに固有の URL が css および js ファイルに組み込まれ、それらがプロモートされたときに正しく機能しないためです。これを Rails で設定する方法に関する手順については、この記事​を参照してください。

よくある質問

パイプラインの CLI では他に何を実行できますか?

コンソールで、使用法の詳細を含むパイプラインのコマンドの完全な一覧を表示できます。

$ heroku help pipelines

Heroku CLI プラグインのリポジトリ README​ では、追加の使用法の例や機能の履歴が提供されています。

開発、ステージング、本番以外のパイプラインステージを使用できますか?

いいえ。これらの 3 つのステージに加え、特殊なステージであるレビューのみが現在サポートされています。

プロモーション時に rake db:migrate などのスクリプトを実行できますか?

Heroku Release Phase​ を使用すると、新しいバージョンのアプリが継続的デリバリーフローのいずれかのステップにデプロイされる前に、スキーマ移行などの一般的なタスクを実行できます。詳細は、関連するドキュメントを参照してください。

パイプラインステージで複数のアプリを使用できますか?

はい。

パイプラインには常にアプリが必要ですか?

はい。パイプラインには常に 1 つのアプリケーションが含まれている必要があります。 アプリが含まれていないパイプラインにはダッシュボードからアクセスできず、削除されることになります。 レビューアプリがパイプライン内に存在することが常に保証できないため、少なくとも 1 つの永続的なアプリをパイプラインに含めることを強くお勧めします。

パイプラインは GitHub なしで動作しますか?

はい。パイプラインは GitHub と極めて適切に統合されていますが、この統合は必須ではありません。

“開発” ステージが表示されません。開発アプリを追加するにはどうすればよいですか?

アプリは他の任意のステージに追加できます。それには、アプリカードのコンテキストメニューを使用して、アプリを “開発” に移動します。あるいは、アプリの Deploy​ (デプロイ) タブに移動し、そこから “開発” ステージを指定してパイプラインに追加することもできます。

パイプラインは Heroku Enterprise Teams と連携して動作しますか?

はい。パイプラインは Enterprise Teams で完全にサポートされています。 ただし、場合によっては、「Using App Permissions in Heroku Enterprise Teams​」(Heroku Enterprise Teams でのアプリアクセス許可の使用) で説明されているように、チームメンバーがアクセス制御のためにパイプライン内の特定のアプリで操作できなくなることがあります。ユーザーは、アプリ上で関連する操作を実行するには十分なアクセス許可が必要です。

パイプラインは Private Space と連携して動作しますか?

はい。パイプラインは、Common Runtime および複数の異なる Private Space のアプリにまたがって動作できます。これにより、本番アプリでのみ Private Space にプロモートしながら、Common Runtime または別の Private Space でテストおよびステージングアプリを使用できます。

パイプラインのコストはいくらですか?

パイプライン機能の使用自体は無料ですが、パイプライン内のアプリによって使用される dyno やアドオンにコストが発生します。