Chapter 06

CodePipeline

sotaro116

2022.10.24に更新

CodePipeline, CloudFormation セクションの目標

CI/CD について理解する
CodePipeline, CloudFormation の仕組みを理解して、エラーログを追えるようになる
CodePipeline, CloudFormation の仕組みを理解して、自力で環境構築できるようになる

今回実施すること

CodePipeline を作成する
CodeCommit リポジトリを作成する
リポジトリのクライアント資源を CodePipeline から S3 に反映する

CI/CD とは

アプリケーション開発のプラクティスの一つ。
CI (継続的インテグレーション)と CD (継続的デリバリー)に分かれるが、ひとまとまりで語られることが多い。
主に開発プロセスの自動化による品質の向上と素早いフィードバックが得られることが利点。
　・資源を頻繁にマージすることにより、資源の競合、バグのリスクを低減することができる
　・マージ後の不具合を素早く検知することができる
リリースの頻度を高めることができる。
　・常にテストをパスした、リリース可能な状態を保つことができるため
「実装 > テスト > デプロイ・リリース」のサイクルを可能な限り自動化
　・アジャイル開発では上記のサイクルを繰り返すので相性が良い

CI/CD https://speakerdeck.com/cybozuinsideout/cd-2021

CI (継続的インテグレーション)

CD (継続的デリバリー)

アジャイル開発と CI/CD

リポジトリ、バージョン管理とは

リポジトリ⇒保管場所
バージョン管理⇒ファイルを誰がいつどこを修正したのかを管理
　・任意のバージョンに戻すことが可能

CodeCommit とは

CodePipeline とは

素早く確実性のあるアップデートのためにパイプラインの継続的デリバリーを自動化
自分でリリースモデルを定義できる. ビルド⇒テスト⇒デプロイ

14:22-20:10 AWS CodeStar は使っていないので興味があれば
39:23-43:55 構成例はサーバーレスのみ理解できていれば OK
49:15 以降は参考程度

各アクション

環境変数とは

コンピュータ上で働くプロセスの実行環境に存在している変数のこと。
雑に解釈するとグローバル定数のようなもの。
プログラムの外から変数を渡すことができるため、実行時等に値を渡し分けることで開発環境を分けて作成することができる。
（例：環境変数にdevという値を渡すと開発環境、prodという値を渡すと本番環境）

CodeBuild

AWS CodeBuild はクラウドで動作する、完全マネージド型のビルドサービスです。CodeBuild はソースコードをコンパイルし、単体テストを実行して、すぐにデプロイできるアーティファクトを生成します。

AWS CodeBuild、または AWS CodePipeline コンソールを使用して、CodeBuild を実行できます。

CodePipeline の Build アクションで実行できる。
ビルドプロジェクトの中で環境変数を定義可能。
ここで定義した環境変数は、buildspec.yml の中で使用することができる。

buildspec

CodePipeline の Build アクションでビルドプロジェクトが読み取り、実行するコマンドを記載するファイル。
テストコマンドを実行することで、テスト完了が担保された状態で開発環境に資源を反映することができる。

ポイント

パイプラインが実行されるトリガーは、指定したリポジトリのブランチに更新（リモートへの push）があったとき。
Source には CodeCommit リポジトリのブランチを指定する。
ビルドプロジェクトに設定する buildspec.yml の中で、ビルド時に実行する処理を記述する。
環境変数を使用することで、各開発環境のパイプラインの設定を大きな差分なく構築することができる。

ハンズオン

CodeCommit リポジトリの作成

CodeCommit コンソールを開く。
リージョンが東京 (ap-northeast-1) であることを確認する。違う場合、東京に設定する。
▼ ソース＞リポジトリページで「リポジトリを作成」を選択。
リポジトリ名に任意の名前を入力。（今回はクライアント資源のリポジトリを作成するため demo-digi-client-{グループ番号}）
「作成」を選択。

CodeCommit リポジトリの引き込み

CodeCommit コンソールを開く。
▼ ソース＞リポジトリページの右側にある「URL のクローン」から、上記で作成したリポジトリの「HTTPS」を選択。Git リポジトリのクローンを作成するアドレスがクリップボードにコピーされる。
ターミナルまたはコマンドラインで、ローカルリポジトリを保存するディレクトリに移動する。（例：/work）
次のコマンドを実行してリポジトリをローカルにクローンする。その際、認証情報を聞かれるため、IAM ユーザーのアクセスキーとシークレットキーを入力する。^[1]
```
git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/demo-digi-client-{グループ番号}
```
認証に成功すると、ローカルに demo-digi-client-{グループ番号} という名前のディレクトリが作成される。
it ブランチを作成してリモートにプッシュ

CodeCommit リポジトリへの資源追加

上記で作成したディレクトリに、以前の研修で作成したクライアントアプリを直接配置する。
以下のファイルをbuildspec.ymlとしてルートディレクトリに作成する。

buildspec.yml

version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 16
    commands:
      - cd $CODEBUILD_SRC_DIR;
      - npm install
      - ls
  pre_build:
    commands:
      - echo 'pre build'
      - npm run test
  build:
    commands:
      - echo 'EXEC build(nuxt generate)'
      - ls
      # $Envは環境変数　
      - echo $Env
      - npm run generate:$Env
      - ls dist
  post_build:
    commands:
      - echo Entering postbuid phase
      # aws s3 sync コマンド $CODEBUILD_SRC_DIR/distと$BUCKETを同期（一致）させる
      - aws s3 sync $CODEBUILD_SRC_DIR/dist $WEBBUCKET
      # aws s3 cp コマンド $CODEBUILD_SRC_DIR/error.htmlを$BUCKETにコピーする
      # - aws s3 cp $CODEBUILD_SRC_DIR/error.html $BUCKET
      - echo sync complete
      - echo Build completed on `date`
# CodeBuildの出力
artifacts:
  files:
    #dist配下の資源全量をアーティファクトとして返却
    - dist/**/*

以下のコマンドを実行して、リモートリポジトリに資源をアップロードする。
1. カレントディレクトリをローカルリポジトリに移動する。
```
cd c:/work/training-{グループ番号}
```
2. すべてのファイルをステージングする。
```
git add .
```
3. コミットメッセージを付与してファイルをコミットする。
```
git commit -m "init"
```
4. ローカルリポジトリから CodeCommit のリモートリポジトリにファイルをプッシュする。
```
git push
```
CodeCommit コンソールを開き、該当リポジトリを選択。資源が反映されていることを確認する。

パイプラインの作成

パイプラインを通して S3 に配備されたことを確認したいため、以前の研修で使用した公開 S3 バケットの中身を削除する。
CodePipeline コンソールを開く。
画面右上の「パイプラインの作成」ボタンを選択。
パイプライン名に任意の名前を入力。（例：demo-digi-client-{グループ番号}）
「既存のサービスロール」を選択。「ロールの ARN」からCodePipelineRole を選択。
「高度な設定」はデフォルトのままで、「次に」を選択。
「ソースプロバイダー」は AWS CodeCommit を選択。
「リポジトリ名」はdemo-digi-client-{グループ番号} を選択。
「ブランチ名」は it を選択。
「検出オプションを変更する」をAWS CodePipelineに選択し、「次に」を選択。
「プロバイダーを構築する」で AWS CodeBuild を選択。

「プロジェクトを作成する」を選択し、ビルドプロジェクトを作成する。設定項目は以下の通り。

プロジェクト名：demo-digi-client-build-{グループ番号}
追加設定：デフォルト（未入力）
環境イメージ：マネージド型イメージ
オペレーティングシステム：Amazon Linux 2
ランタイム：Standard
イメージ：~x86_64-standard:4.0
イメージのバージョン：最新のイメージ（末尾の日付で判断できる）
環境タイプ：Linux
サービスロール：既存のサービスロール
ロールの ARN：CodePipelineRole（下のチェックボックスのチェックをはずす）
追加設定：デフォルト
ビルド仕様：buildspec ファイルを使用する
バッチ設定・ログ：デフォルト

「環境変数の追加」を選択。以下の値を設定する。

名前：WEBBUCKET
値：s3://{以前の研修で使用したs3バケット名}
タイプ：プレーンテキスト

名前：Env
値：it
タイプ：プレーンテキスト

その他の設定はデフォルトのままで、「次に」を選択。
「導入段階をスキップ」を選択。モーダルも「スキップ」を選択。
「パイプラインを作成する」を選択。
CodePipeline コンソールでパイプラインが作成されていることを確認する。

パイプラインの実行

正常にパイプラインが作成された場合、自動的に最新のリポジトリの資源が取得されパイプラインが実行される。
- 実行されない場合…
  - 該当のパイプラインを選択し「変更をリリースする」を選択すると、手動で取得済の最新の資源を元にパイプラインを実行することができる。
  - 資源に修正を加え、リモートリポジトリにファイルをプッシュすると、パイプラインを実行することができる。
パイプラインが成功した場合、該当の S3 内のオブジェクトを公開し、 S3 の URL にアクセスしてアプリが表示されることを確認する。
- 失敗した場合…
  1. 該当のパイプラインを選択。
  2. 「詳細」→「実行の詳細へのリンク」を選択して、ログを確認する。

TODO

itブランチで資源を修正してリモートpushをし、pipelineが回り、s3資源が変更されることを確認してみましょう
buildspecをいじり、意図的にpipelineを失敗させて、エラーをどのように見ていくのか確認しましょう(変なコードは入れず、 $WEBBUCKETを$ WEBBUCKETTTTTに変更する等)

脚注

https://<username>:<password>@git~ の形式でキーを指定することも可能。 ↩︎