Heroku Pipeline概要

この記事はHeroku Dev CenterにあるPipelineのページを翻訳したものです。
Pipelineは今年の9月にbeta版として公開された機能です。
日本語の資料があまりにも少ないのでチャレンジしてみます。
ある程度意訳していますが、間違っている点等あればご指摘ください。

目次

• 複数環境の複雑さ
• パイプラインによるデプロイ
• パイプラインへのアクセス
• CLI経由のパイプライン
• パイプラインの作成
• パイプラインにアプリケーションを追加する
• パイプラインに複数アプリケーションを配置する
• 反映
• GitHub連携
• Review Apps
• パイプラインフロー
• FAQ

[warning]
パイプラインは現在ベータ版です。もしフィードバック、提案、質問等があればこの記事にフィードバックを残してください。パイプラインはGitHubからのコードデプロイをよりよいものにする取り組みのひとつです。なにかあれば[e-mail] もしくはsign up for the GitHub beta mailing list.あてにご連絡ください。

[note]
この記事はパイプラインの新しいフェーズについて書いており、以前のHerokuLabs:Pipelineにとってかわるものです。

パイプラインは同じコードを共有しているHerokuアプリケーションのグループです。パイプラインの中のアプリケーションはreview、development, staging, production環境といったものに代表される、継続的配信ワークフローの中の異なるデプロイの段階です。コードの変更は典型的には最初にPullRequestにデプロイされます。それらは自動的にreview appとして作成され、masterにマージされると今度はstagingに自動デプロイされます。最終的にはアプリケーションのエンドユーザーが新機能を利用できるようになる本番環境に反映されます。パイプラインの概要ページはそれぞれの環境のステータスのフローがイメージしやすいようになっています。たとえばproductionのアプリケーションはstagingとは異なるコードで動いていることがわかります。

複数環境の複雑さ

stagingとproductionといった複数環境を維持することはHerokuではシンプルにできます。しかしながらこれらの環境の間で一貫したデプロイを維持することは、アプリケーションの管理者がデプロイのワークフローを手動で管理しなければいけません。手動デプロイワークフローにおいてあげられる課題は例によって間違ったコミットをpushすることや、テストしていないコードのリリース、または、正しくない環境へのpushを含みます。

パイプラインによるデプロイ

パイプラインはコードをいかにして次の環境へ流していくか定義することを可能にします。たとえば、stagingにコードをpushするとスラグにビルドされ、stagingスラグからproductionに反映されます。これは同一のコンパイル済みのコードであることを保証するだけでなく、スラグを再コンパイルするよりもはるかに早いのです。パイプラインの共通の例は以下のようになります。

シンプルなstagingからproductionへのパイプライン

myapp-staging ---> myapp

もしくは、チームでの複雑なパイプライン

myapp-jim-dev ---
                  \
                    ---> myapp-staging ---> myapp
                  /
myapp-kim-dev ---

[note]
パイプラインの語彙にある、後段とはパイプラインにおける次のアプリケーションの参照です。例えば dev--->staging--->production というパイプラインの場合、stagingはdevの後段であり、productionはstagingの後段です。

一度パイプラインを定義すれば、個人でもチームでも、次にデプロイするアプリケーションについて心配しなくてよくなります。代わりに、heroku pipelines:promote を行えば、アプリケーションのスラグを新しいリリースとして後段にコピーします。

[warning]
パイプラインはアプリケーションのスラグのみ管理します。gitリポジトリやコンフィグの変数およびアドオン、その他の環境に依存するものはパイプラインの一部として考えるものではなく、独立して管理されるべきです。Heroku Forkを使うとdevやstagingとして使うためにproductionを素早くcloneできます。またReview AppはすべてのPullRequestのための一時的なアプリケーションを作ることができます。

[warning]
アプリケーション間でスラグを反映すると、Herokuは変更なくスラグをコピーします。特に、スラグは対象アプリケーションの環境でリビルドはされません。もしビルドアプリケーションの環境でビルドが行われると、そのスラグはアプリケーション間で移動できません。また、ビルドした場所のアプリケーションから反映したときにも正常に動作しません。次のようなケースがあげられます。もし、Ruby on Railsを使っていて、ビルド環境に定義されたCDNのアセットでビルドするアセットパイプラインの場合、このような例に該当する可能性があります。これはビルドアプリケーションの固有のURLがcssやjsに書かれるためです。これらは反映時に正常に動作しません。

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

パイプラインの中のアプリケーションは個別のアプリケーションとしては見えないようになっています。代わりに、個別のアプリケーションはドロップダウンで閲覧できるようになっています。

CLI経由のパイプライン

多くのパイプラインの操作はCLIから作業可能です。
CLIにはPipelines plugin for the Heroku Toolbelt.が必要です。
以下のようにインストールしてください。

$ heroku plugins:install heroku-pipelines

パイプラインの作成

新しいパイプラインを作成するには、アプリケーションリストの右上の+アイコンをクリックし、Create new pipelineを選択します。もしくは、アプリケーションのデプロイタブから新しいパイプラインを追加します。

CLIからもパイプラインをつくることができます。必ずパイプラインを追加するアプリケーションでスタートする必要がありますが、特別なstageになる必要はありません。もし、--stage STAGEを明示しない場合CLIは適切なstageを推測してくれますし、デフォルトを上書くこともできます。同じようにパイプラインの名前はアプリケーション名から推測されますが、コマンドラインからNAMEを追加すること、もしくは、反映時に異なる名前を入力することで上書きできます。

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

[note]
もし以前にGitHub連携を使ったことがあれば、我々がこれらのアプリケーションをパイプラインに移行したときにすでにアプリケーションのリストでパイプラインを見たことがあるかもしれません。

パイプラインにアプリケーションを追加する

パイプライン概要ページで、+ Add appをクリックし、既存のアプリケーションをパイプラインに追加してください。CLIからは以下のようになります。

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

パイプラインに複数アプリケーションを配置する

パイプラインのステージには一つ以上のアプリケーションが含まれる可能性が有ります。たとえば、productionステージには、同じコードバージョンで、異なる設定ファイルで動いているメインのproductionアプリケーションとadminアプリケーションが存在するかもしれません。

反映

変更が特定のステージで十分にテストされたら、スラグは後段のステージへPromoteボタンを押すことで反映されるようになります。もし、後段に複数のアプリケーションがあった場合、スラグはデフォルトですべてのアプリケーションに反映されます。心配は必要ありません。何が反映されるか、コミットのあとにそれがどこにいくか、反映の前に確認することができます。

CLIからはソースから特定してアプリケーションを反映できます。対象アプリケーションは自動的に後段のステージにしたがって決定されます。たとえば、productionにふたつのアプリケーションがある場合、stagingからの反映はproductionのふたつのアプリケーションにリリースされます。

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

GitHub連携

stagingからproductionへの反映は素晴らしいですが、GitHub連携を使い、stagingへのデプロイもさらに最適化したフローにすることができます。たとえば、github上のmasterブランチが更新され、CIでのテストが通ったときに、stagingに自動的にデプロイすることができます。

Review Apps

もしGitHubを使っていれば、PullRequestを使うこととreview appsを設定することをおすすめします。

パイプラインフロー

多くの開発者がプロジェクトで開発を進めており、Herokuでシングルアプリケーションを構築しています。ここでのポイントは、それは本当の「production」ではないということです。ただのアプリケーションなのです。しかし、ある時点では、それを他人に公開していて、もしかするとユーザーはそれに依存しはじめているかもしれません。そのときにバグを含むコードを貴重なユーザー向けにpushしてしまうことはよくないことでしょう。そこであなたはstagingアプリケーションを用意しようと思います。また、ある時点では、新しいアイデアを前もってテストするためdevelopmentアプリケーションが急に必要になります。たいていはそれをmasterにマージしてstagingからproductionへのフローにのせるべきか決定する前に変更を他のだれかに見せたいときです。
チームが成長したとき、開発者たちはシングル構成のdevアプリケーションについて論争を目にするでしょう。そしてそれぞれの開発者の個別のdevアプリケーションを作り始めます。これはすべてよいことですが、review appsが現れたことによってすべてのPullRequestに一時的なアプリケーションを用意するという新しいことがおきます。変更をチームの誰か他の人に見せたいならPullRequestを作って新しいアプリケーションのリンクをクリックすればよいだけなのです。これはGitHub Flowによって美しく動作します。PullRequestをmasterにマージする前の最終ステップとしてとらえるよりも、議論の始まりとしてそれを考えるべきです。フィーチャーが発展するとき、議論の積み重ねができます。フィーチャーが最終的にマージされたとき、PullRequestは閉じられ、review appも自動的に削除されます。（GitHub連携をしていれば新しくマージされたコードは自動的にstagingにデプロイされます。）
多くのチームが個別のdevelopmentアプリケーションはこれ以上必要ないことに気づきます。古典的なdev--->staging--->prodというフローはreview--->staging--->prodに変わります。Heroku Pipelineはこれらのフローの両方をサポートしますが、後者を奨励します。
別の人気のあるフローでgit-flowと呼ばれるものはHeroku Pipelineととても相性がよいです。review appsをPullRequestによってフィーチャーブランチと紐付ければdevelopブランチはdevelopmentアプリケーションに、一つもしくは複数のreleaseブランチはstagingアプリケーションに、masterはproductionブランチに紐付けられます。Hotfixブランチはまったく合いませんが、forkを使うことで一時的なアプリケーションの作成によって取り扱うことができるかもしれません。そしてそれらをstagingと置き換えるわけです。
ユーザーの中にはtestingやqaや、user-acceptance、さらにその他のステージを使うこともあるでしょう。これからはこれらのアプリケーションをdevelopmentもしくはstagingに置き換えてみてください。もし本当に動作しない場合は我々に知らせてください。

FAQ

Q.他にpipeline cliでできることはありますか？

A.詳細な使用方法を含むパイプラインコマンドの完全なリストはコンソールから利用可能です。

$ heroku help pipelines

repository README for the Heroku CLI pluginでも追加の使用例と更新履歴を見ることができます。

Q.development、staging、production以外のパイプラインステージを持つことはできますか？

A.できません。現在はこれら３つのステージと特別なステージであるreviewのみサポートされています。

Q.反映の際にrake db:migrateのようなスクリプトを実行することはできますか？

A.反映の際にはできません。もしコードの変更が、DBのマイグレーションや、S3やCDNへの静的アセットのアップロードのような特定のアプリケーションの環境を要するその他のアクションを必要とする場合、これらのアクションはパイプラインの反映のあとで手動で実行されるようにすることが必要です。

Q.古いパイプラインから新しいパイプラインに以降することはできますか？

A.できません。今のところダッシュボードから新しいパイプラインを再設定していただく必要がございます。

Q.パイプラインのステージに一つ以上のアプリケーションをもてますか？

A.はい

Q.GitHubなしでパイプラインを利用できますか？

A.はい、GitHubとの連携が望ましいですが、単体でも動作します。

Q.developmentステージが見当たりません。どのようにdevelopmentアプリケーションを追加したらよいですか？

A.アプリケーションはどのステージにも追加できます。アプリケーションのメニューからアプリケーションをdevelopmentに移動します。あるいは、Deployタブから、パイプラインのdevelopmentステージに追加します。

Q.パイプラインは組織アカウントから動作しますか？

A.はい、パイプラインは組織アカウントを完全にサポートしています。しかしながら、幾つかのケースではチームメンバーがアクセス制限によってパイプラインの中のアプリケーションを操作できないかもしれません。App Privileges for Heroku Organizationsで説明されているように。ユーザーはアプリケーションで適切な操作が行えるよう十分な権限を付与されている必要があります。

最後に

明日は実際にパイプラインを使ってみての操作感や期待できることについて考えて書こうと思います。
スクショはあとから付け足します。