背景
業務において、CICD環境に冗長な部分があったり、自動化できる部分を手動で実施している部分があり、ヒューマンエラーのリスクや保守作業の長時間化が発生していた。
(特にリリース作業で、開発者の手作業による部分が多かった)
前提
言葉の定義として、下記のようにデプロイとリリース使い分けてます。ご認識置きください。
- デプロイ：実行ファイルを実行環境に配置し、利用可能な状態にすること
- リリース：製品やサービスとして公開し、ユーザーが使える状態にすること
この「実行ファイルを実行環境に配置し、利用可能な状態にする」ことを「デプロイ（deploy）」と呼びます。
もともと英単語のdeployは、「配置する」「展開する」という意味があります。
ソフトウェアのインストールや公開までを含んだ意味の広い言葉で、開発環境からステージング環境への反映も、ステージング環境から本番環境への反映もデプロイと呼ばれることがあります。そして「リリース」は製品やサービスとして公開し、ユーザーが使える状態にする工程を指します。
資産構成としては下記を想定しています。
プロジェクトフォルダ
-clinet(フロントエンド資産)
-server(バックエンド資産)
-function(Function(バッチ)資産)
設計
思想としては、マイクロサービスで作ってます。
- マイクロなパイプラインは個別実行することもできる
- 本番リリースみたいな一連の流れが必要となる作業においても、大元のパイプラインから各マイクロなパプラインを呼び出すことで、一連の流れを自動化できる
- マイクロなつくりなので、個別で実行することも別環境向けに使いまわすことも可能
パイプライン一覧
- 向き先の環境は、パイプライン実行時にラジオボタンから選択できるようにしてます
【Pipelines > Pipelines】
★がついてるものは、マイクロなパイプラインを呼び出す元のパイプラインになります。
| No | パイプライン名 | 役割 | トリガー |
|---|---|---|---|
| release/ | |||
| ①★ | -- release | 本番リリースに係る一連の作業を行う。リリースに伴い、③④⑤⑥のパイプラインを呼び出す。各タスクごとに承認を得てから、次タスクを実行する。 | 手動 |
| deploy/ | |||
| ②★ | -- deploy | 開発・保守環境向けに資産をデプロイする。③のパイプラインを呼び出す。 | 手動 |
| artifact/ | |||
| ③ | -- artifact | 資産のビルド・テスト・アーティファクト※を行う。また、スケジュール実行で資産の品質チェックも行う。スケジュール実行時のみ、⑩⑪を呼び出す。 ※デプロイ資産を生成すること |
手動+①②からの呼出+スケジュール |
| environment-setting/ | |||
| ④ | -- environment_variable_setting | Azure上のリソースに対して、環境変数を設定する。 | 手動+①からの呼出 |
| ⑤ | swap | Azure上のリソースに対して、スロットのスワップを実行する。 | 手動+①からの呼出 |
| migration/ | |||
| ⑥ | migration | 指定した環境のDBに、migrationを実行する。 | 手動+①からの呼出 |
| minimum-check/ | |||
| ⑦ | -- minimum_check-client | developブランチのclient資産が、ビルド・テストが通ることをチェックする。 | 手動+develop変更時+プルリクエストComplete時 |
| ⑧ | -- minimum_check-server | developブランチのserver資産が、ビルド・テストが通ることをチェックする。 | 手動+develop変更時+プルリクエストComplete時 |
| ⑨ | -- minimum_check-function | developブランチのfunction資産が、ビルド・テストが通ることをチェックする。 | 手動+develop変更時+プルリクエストComplete時 |
| quality-check/ | |||
| ⑩ | -- npm-vulnerability-check | client/server/functionsのnpmライブラリに、脆弱性が含まれないかをチェックする。 | 手動+③からの呼出 |
| ⑪ | -- stress-test | 開発管理者用Appservice向けに、k6による性能テストを実施する。 | 手動+③からの呼出 |
【Pipelines > Releases】
- 無し
- Releasesのパイプラインからyamlパイプラインを呼び出すことができなかったため、デプロイパイプラインもyamlに移行する
ユースケース
【リリース(本番)したい時】
| No | タスク | 作業者 |
|---|---|---|
| 1 | release(①)を実行する | 開発T |
| 2 | artifact(③)が実行される | -- |
| 3 | No.2で生成された資産がデプロイされる | -- |
| 4 | スワップ(閉塞)の承諾を行う | 承認者 |
| 5 | swap(⑤)が実行される | -- |
| 6 | スロットの確認を行う | 開発T |
| 7 | マイグレーション実行の承諾を行う | 承認者 |
| 8 | migration(⑥)が実行される | -- |
| 9 | DB更新を確認する | 開発T |
| 10 | 環境変数設定の承諾を行う | 承認者 |
| 11 | environment_variable_setting(④)が実行される | -- |
| 12 | 環境変数の確認を行う | 開発T |
| 13 | スワップ(閉塞解除)の承諾を行う | 承認者 |
| 14 | swap(⑤)が実行される | -- |
| 15 | スロットの確認を行う | 開発T |
| 16 | -------リリース完了-------- | |
| 17 | -------跡片付け-------- | |
| 18 | スワップ(資産整理)の承諾を行う | 承認者 |
| 19 | swap(⑤)が実行される | -- |
| 20 | スロットの確認を行う | 開発T |
| 21 | デプロイの承諾を行う | 開発T |
| 22 | artifact(②)が実行される | -- |
| 23 | No.2で生成された資産がデプロイされる | -- |
| 24 | スロットの確認を行う | 開発T |
| -------終了-------- |
※基本的に開発T作業は確認のみになる。
【デプロイ(開発・保守)したい時】
| No | タスク | 作業者 |
|---|---|---|
| 1 | deploy(②)を実行する | 開発T |
| 2 | artifact(③)が実行される | -- |
| 3 | No.2で生成された資産がデプロイされる | -- |
| -------終了-------- |
【マイグレ流したい時】
| No | タスク | 作業者 |
|---|---|---|
| 1 | 対象環境を選択して、migration(⑥)を実行する | 開発T |
| 2 | -------以降、本番環境を指定した時のみのタスク-------- | |
| 3 | マイグレーション実行の承諾を行う | 承認者 |
| 4 | migration(⑥)が実行される | -- |
| 5 | DB更新を確認する | 開発T |
| -------終了-------- |
【環境変数設定したい時】
| No | タスク | 作業者 |
|---|---|---|
| 1 | 対象環境を選択して、environment_variable_setting(④)を実行する | 開発T |
| 2 | -------以降、本番環境を指定した時のみのタスク-------- | |
| 3 | 環境変数設定の承諾を行う | 承認者 |
| 4 | environment_variable_setting(④)が実行される | -- |
| 5 | 環境変数の確認を行う | 開発T |
| -------終了-------- |