Amplify Multi Environment でチーム開発を整備する

2020.02.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amplifyを利用してごく小規模な開発を行っています. 初めは開発を私主体で行っており特に問題も不便さもありませんでした.
ですが開発するメンバが増えるのでデプロイフロー含めて整備する必要が出てきました.
そこでAmplify Multi Environmentの導入と開発フローを少し整備したのでまとめてみました.

tl;tr

  • Amplify Consoleに接続したブランチと環境はCLI側から変更しないようにする
  • Amplify ConsoleとGitHub Flowを利用して開発を進めようとしている

Amplify Envについて

Amplify Multi EnvironmentはAmplifyで複数環境を管理する機能です.
アプリケーション開発で開発環境, ステージング環境, 本番環境を分けて作成するのは普通の流れですね.
それぞれの環境は依存しておらず切り離されているべきであります.
この機能を利用することで 開発環境, ステージング環境, 本番勧業ごとにバックエンドを独立して作成させることが可能です.
またそれぞれの環境は独立しているため, ステージング環境と本番環境で別アカウントを利用すると言ったことも可能です.

今回の環境について

Amplifyはprod環境とdev環境を用意します. また開発フローとして, GitHub フローを利用するのでmasterブランチと複数のfeatureブランチがリポジトリ上に存在します.
この状態でAmplify Consoleでmasterブランチと, prod環境を紐づけて自動デプロイできるようにします.
dev環境についてはブランチと紐付けを行わずに開発者が検証や開発を行う環境として利用します.
まだプロジェクトを外部公開しておらずステージング環境が不要でかつ, 必要になった段階でAmplify Pull Request Review機能を追加しようと思っているので, devとprodのみにしています.

またProd環境のバックエンドについてはAmplify CLI側で操作を行わずAmplify Console経由からの操作のみ行うようにします. この理由ですが, 例えば下記の操作を行ったとします.

  • prod環境にAmplify CLI側でAuthを追加する
    • Amplify CLIはCloudFormationスタックを作成してCognito UserPoolの作成と, バックエンドの設定ファイル追加と書き換えを行う
  • この変更をmasterにmergeする前に他の開発者がmasterブランチにfeatureブランチをmergeする
    • Amplify Consoleによる自動デプロイが行われる

この操作を行うとAmplify Consoleは設定ファイルにないAuthリソースをprod環境から削除します.
自動デプロイによって必要なリソースが削除されては困るのでそのための予防策として下記の3つを考えました.

  • prod環境はAmplify CLIから変更を行わないい
  • prod環境はmasterブランチと接続を行い, バックエンドのデプロイもAmplify Consoleの自動デプロイ機能からのみ行う
  • dev環境はブランチとの接続を行わない

今までの話を簡単に要約すると

  • GitHub Flowに近い形で開発を行う
  • 開発者はAmplify dev環境で開発を行う
  • Amplify Prod環境へCLIからの操作は行わない

が今回の開発のメインルールとなります.
またブログには記載していませんが, GitHubの機能でmasterブランチはレビュー必須で保護をかけています.

環境の追加

今回使用したAmplify CLIのバージョンは4.12.0です. またすでにAmplify Projectの作成部分については一旦飛ばした上で, prod環境はすでにあるものとします.

環境の追加方法は非常にシンプルです.下の流れで作成できます.

$ git switch -c 'feat/devenv'

$ amplify env add
	Note: It is recommended to run this command from the root of your app directory
	? Do you want to use an existing environment? No
	? Enter a name for the environment dev
	Using default provider  awscloudformation
	
	For more information on AWS Profiles, see:
	https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html
	
	? Do you want to use an AWS profile? Yes
	? Please choose the profile you want to use PROFILE_NAME

これでdev環境が作成されました. しかしまだバックエンドが作成されていないので合わせて作成します. push時には環境名が出るので問題ないかを合わせて確認しましょう.

$ amplify push

$ amplify status

	Current Environment: dev
	
	| Category | Resource name   | Operation | Provider plugin   |
	| -------- | --------------- | --------- | ----------------- |
	| Api      | NAMEPRODUCTION  | No Change | awscloudformation |

リソースの追加も問題なさそうですね.

Auth を追加する

次にdev環境でバックエンドリソース追加と, Amplify Consoleでprodにリソース追加されるかを確認します. 一番最初に提示した例のように本当に私はAuthリソースを消し飛ばしてしまったで再度追加します.

$ amplify auth add

$ amplify status

Current Environment: dev

| Category | Resource name   | Operation | Provider plugin   |
| -------- | --------------- | --------- | ----------------- |
| Auth     | NAMEPRODUCTION  | Create    | awscloudformation |
| Api      | NAMEPRODUCTION  | No Change | awscloudformation |

dev環境にリソースを追加しました.
この変更後にPull Requestを作成して変更をmasterにmergeしましょう. しばらく後にデプロイが完了するので, statusを確認してみます.

$ amplify env checkout prod

$ amplify status

Current Environment: prod

| Category | Resource name   | Operation | Provider plugin   |
| -------- | --------------- | --------- | ----------------- |
| Api      | NAMEPRODUCTION  | Create    | awscloudformation |
| Auth     | NAMEPRODUCTION  | Delete    | awscloudformation |

追加は確認できており, バックエンドの設定と現在の状態が異なるので, この状態でpushするとAuthリソースが消えます.
危ないのでdev環境にちゃんと切り替えておきましょう.

開発への参加について

最後に開発者がどのように参加するかの流れを記載します. 普通のAmplifyでの開発と同様にinit時に環境を指定するだけで大丈夫です.

$ git clone path/to/your/repo

$ amplify init
	Note: It is recommended to run this command from the root of your app directory
	? Do you want to use an existing environment? Yes
	? Choose the environment you would like to use: dev
	? Choose your default editor: Visual Studio Code
	Using default provider  awscloudformation

これだけで準備が完了します. この辺りのスピード感もAmplifyが便利だなぁと思います.

さいごに

開発フローに正解はなく, チームに依存する問題なので頭を悩ませながらこういったフローを採用してみました.
今後も問題点は出てくるので適宜修正できればなぁと思っています.

参考文献