継続的デプロイは、急速に進化するソフトウェア開発において非常に重要なものとなっています。リリースサイクルの高速化、人的ミスの削減、そして最終的にはユーザーエクスペリエンスの向上が可能です。
ソフトウェア開発は言うなれば、現実世界の問題をコードで解決する挑戦です。ソフトウェアの作成から顧客までの道のりには多くの段階があり、スピード、安全性、信頼性が要求されます。そこで重要になるのが、継続的デプロイメントです。
この記事では、CircleCIプラットフォームを統合して継続的インテグレーションと継続的デリバリー/デプロイメント(CI/CD)ワークフローを作成する方法をご説明します。この組み合わせは、開発から本番へのスムーズな道のりを開く鍵になります。
継続的デプロイメントを理解する
継続的デプロイは単なる「流行り言葉」ではなく、ソフトウェア開発におけるパラダイムシフトです。ビルド、テスト、そして本番サーバーへのコード変更のデプロイプロセスを自動化することを意味します。
継続的デプロイの基本コンポーネントであるCI/CDパイプラインは、プロセス全体をオーケストレーションする。これには、バージョン管理、自動テスト、自動デプロイが含まれます。各ステージは、信頼性が高く、テストされたコードのみがプロダクションに到達することを保証する上で極めて重要になります。
CircleCIとは
CircleCIはCI/CDを実装するのに便利なツールです。GitHub、GitLab、Bitbucketのようなバージョン管理システムと統合し、CI/CDパイプライン全体を自動化することができます。そのスケーラビリティ、拡張性、様々なプログラミング言語のサポートにより、あらゆる規模のプロジェクトに対応する汎用性の高い選択肢となっています。
CircleCIを使うことで開発者は、コードのコミット時に自動的にトリガーされるワークフローを定義できます。これにより、ビルドとテストのプロセスを開始し、これが正常に完了すると、対象の環境にコードがデプロイされます。「ハンズオフ」アプローチであることで、手間の削減だけでなく、デプロイにおける人間が犯すミスも最小限に抑えます。
Kinsta APIを理解する
Kinsta APIを使用することで、Kinstaでホストするサービスとプログラムを介してやり取りすることができます。その機能の一部がアプリケーションのデプロイです。CI/CDワークフローで作業する際には、ワークフローからKinsta APIと対話するのにcURLコマンドを使用できます。
APIを使用するには、MyKinstaで少なくとも1つのWordPressサイト、アプリケーション、またはデータベースのアカウントを持っている必要があります。そして、APIへのアクセスを認証するにはAPIキーを生成します。
APIキーを生成する方法は以下の通りです。
- MyKinstaに移動
- 「APIキー」ページに移動((アカウント名)>「企業の設定」>「APIキー」)
- 「APIキーを作成」をクリックします。
- 有効期限を選択(または、キーの有効期限を指定)
- キーに一意の名前を付ける
- 「生成」をクリック
APIキーを作成したら、コピーして安全な場所に保管してください(パスワードマネージャを使用することをお勧めします)。
Kinsta APIでデプロイをトリガーする方法
APIを使用してKinstaへのアプリケーションのデプロイをトリガーするには、アプリケーションのIDとGitリポジトリ内のデプロイ可能なブランチの名前が必要です。アプリケーションのIDを取得するには、まずアプリケーションの一覧を取得します。
次に、cURLコマンドでAPIの/applications/deployments
エンドポイントにPOSTリクエストを行います。
curl -i -X POST \
https://api.kinsta.com/v2/applications/deployments \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
-H 'Content-Type: application/json' \
-d '{
"app_id": "<YOUR_APP_ID>",
"branch": "main"
}'
このcURLコマンドがワークフローで使用されます。
CircleCIを利用する
CircleCIを使うには、お好みのGitサービスにホストされたソースコードが必要になります。この説明では、Kinsta APIでWordPressサイトを作成する方法で開発したサイトビルダーアプリケーションを使用することにします。GitHubのリポジトリで「Use this template」>「Create a new repository」に進みます。
Reactアプリケーションでは、各コンポーネントをテストする単体テストを作成します。また、完璧な構文とコードの書式を強制するためにESLintも使用します。ビルド、テストし、コードの構文が正しいことを確認し、最後にAPIを使ってKinstaにデプロイするCI/CDワークフローをセットアップしたいと思います。
始めるにあたって、いくつかの重要なコンセプトを整理しておきましょう。
- ワークフロー:CircleCIはワークフロー、つまりCI/CDパイプラインの段階を形づくるジョブのシーケンスに基づいています。ワークフローは、ビルド、テスト、デプロイなど様々なステップを内包することができます。
- ジョブ:ジョブはワークフロー内の個々の作業単位です。各ジョブが、コードのコンパイル、テストの実行、サーバーへのデプロイなど、特定のタスクを実行します。これには、順番に実行される(並列実行)様々なステップを指定でき、1つが失敗するとジョブ全体が失敗します。
ステップ1. CircleCIアカウントの作成
CircleCIのウェブサイトにアクセスし、まだアカウントを持っていない場合はアカウントを作成してください。お好きなGitサービスを使って新規登録できます。これで簡単に追加の設定なしでリポジトリにアクセス可能です。
ステップ2. 設定ファイルの作成
プロジェクトのルートディレクトリに.circleciフォルダがなければ作成し、その中にconfig.ymlファイルを作成します。このファイルにワークフローの設定を格納します。
ステップ3. リポジトリの設定
ログインしたら、CircleCIダッシュボードに移動し、左サイドバーの「Projects」をクリックしてリポジトリ一覧を表示し、設定したいリポジトリの「Set Up Project」ボタンをクリックします。
CircleCIが自動で設定ファイルを検出します。次に、「Set Up Project」ボタンをクリックします。これでCircleCIがコードベースにアクセスし、コード変更時に定義したワークフローを実行できるようになります。
ステップ4. ワークフローのジョブの定義
CircleCIパイプラインのセットアップの中心がこのステップです。config.ymlファイル内でワークフローを定義します。ここで、パイプラインが実行する一連のアクションを編成することになります。開発から本番までの青写真を描くようなものです。
これはCircleCIのバージョンを定義することから始まります。現在のバージョンは2.1
です。
version: 2.1
すべてのReactプロジェクトにbuild
ジョブが必要です。このジョブは、コードをデプロイするための基本的な処理を行います。これには、必要な依存関係のインストール、コードのコンパイル、テストの実行、コードの品質チェック、そして最後にコードをデプロイ先にプッシュすることが含まれます。
Reactプロジェクトでは、作業完了のためにNode.jsなどとの統合が必要になることが多く、CircleCIはこれをあらかじめパッケージ化したイメージとして提供しています。使用するNode.jsのバージョンを指定します。ここではNode.js v20を使用します。
jobs:
build:
docker:
- image: cimg/node:20.5.0
このジョブは様々なステップを実行するため、それらを作成していきます。最初のステップはcheckout
です。リポジトリから最新バージョンのコードを取得し、後続のすべてのアクションが最新のコードで動作するようにします。
steps:
- checkout
続いて、ここからが本番です。checkout
に続くステップで、依存関係のインストール、ソースコードのコンパイル、単体テストの実行、ESLintを使ったコードの検査といった重要なタスクを行います。
steps:
- checkout
- run:
name: Install Dependencies
command: npm install
- run:
name: Compile Source Code
command: npm run build
- run:
name: Run Unit Tests
command: npm test
- run:
name: Run ESLint
command: npm run lint
各ステップには、旅の道しるべのように、ワークフローが本格化したときに何が起こるかを追跡できるように名前が付けられています。このように明確にすることで、トラブルシューティングが容易になり、ワークフロー内のすべてが機能していることを確認できます。
Kinstaへの継続的デプロイのトリガー
build
ジョブの最後のステップは、API 経由でKinstaへのデプロイを開始することです。これにはAPIキーとApp IDの2つの値が必要になります。これらの値はCircleCIの環境変数として保持されます。とりあえず、ワークフローのデプロイステージを定義しましょう。
- run:
name: Deploy to Kinsta
command: |
curl -i -X POST \
https://api.kinsta.com/v2/applications/deployments \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"app_id": "'"$APP_ID"'",
"branch": "main"
}'
このコードで、環境変数に格納されたアプリケーションIDを使用してデプロイをトリガーするのにcURLコマンドを実行します。環境変数には、次の構文でアクセスします。
"$VARIABLE_NAME"
CircleCIによる環境変数の保存
環境変数は、継続的インテグレーションおよびデプロイメントワークフローのセキュリティと柔軟性を維持する上で非常に重要です。CircleCIで環境変数を保存するには、以下の手順に従ってください。
- プロジェクトを開いてパイプラインの詳細を確認し、「Project Settings」ボタンをクリック
- サイドバーの「Environment Variables」タブをクリックし、環境変数を追加
ステップ5. ワークフローの設定
ジョブの設定、ステップとしての構造化をしたところで、次はワークフローを設定します。ワークフローはオーケストレーターとして機能し、ジョブのシーケンスを導き、そのジョブがどのように実行されるかを決定する特定のフィルタやルールを組み込む役割を担います。
この説明では、リポジトリのmain
ブランチでコードのプッシュや変更があったときだけビルドジョブをトリガーするワークフローを作成します。
workflows:
version: 2
build-test-lint:
jobs:
- build:
filters:
branches:
only:
- main
この設定にはフィルタを使用します。フィルタを使用することで、特定の条件に基づいてジョブの実行タイミングを制御することができます。また、ワークフローを実行するタイミングをスケジュールするトリガーを組み込むことも可能です(例:毎日午前12時UTCなど)。
workflows:
version: 2
build-test-lint:
jobs:
- build:
filters:
branches:
only:
- main
triggers:
- schedule:
cron: "0 0 * * *"
上記のワークフローでは、schedule
キーワードでtrigger
を定義しています。cron 式"0 0 * * *"
は、毎日午前0時(UTC)にワークフローをスケジューリングすることを意味します。
cron式には、スペースで区切られた5つのフィールドがあり、それぞれが異なる時間単位を表します。以下の通りです。
- 分(0~59):最初のフィールドは分を表し、
0
に設定すると、その時間の開始時にトリガーされる。 - 時(0~23):2番目のフィールドは時間を表し、午前0時の場合は
0
にする。 - 日(1~31):第3のフィールドは日付を表し、任意の日にする場合はアスタリスク(
*
)を使用する。 - 月(1~12):4番目のフィールドは月を表し、任意の月にする場合はアスタリスク(
*
)を使用する。 - 曜日(0~6、0は日曜日):5番目のフィールドは曜日を表し、任意の曜日にはアスタリスク(
*
)を使用する。
このワークフローの設定により、定義したジョブがいつ、どのような条件で実行されるかを効果的に管理し、効率的で合理的なCI/CDパイプラインを維持することができます。
ステップ6. コミットと観察
ワークフローの設定が完了したら、変更をバージョンコントロールリポジトリにコミットします。CircleCIが設定ファイルの存在を自動で検出し、コードの変更時に定義したワークフローをトリガーします。
ビルドジョブをクリックして詳細を確認できます。複数のジョブがある場合は、すべて一覧で表示されます。ジョブをクリックすると、「STEPS」タブに実行ステップとそれが成功したかどうかが表示されます。
各ステップをクリックして詳細を見ることもできます。「Deploy to Kinsta」のステップをクリックすると、APIリクエストの詳細が表示され、成功したかどうかがわかります。
MyKinstaを確認すると、ワークフローが自動でデプロイをトリガーしていることがわかります。以下がCircleCIワークフローの完成形です。
version: 2.1
jobs:
build:
docker:
- image: cimg/node:20.5.0
steps:
- checkout # Check out the code from the repository
- run:
name: Install Dependencies
command: npm install
- run:
name: Compile Source Code
command: npm run build
- run:
name: Run Unit Tests
command: npm test
- run:
name: Run ESLint
command: npm run lint
- run:
name: Deploy to Kinsta
command: |
curl -i -X POST \
https://api.kinsta.com/v2/applications/deployments \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"app_id": "'"$APP_ID"'",
"branch": "main"
}'
workflows:
version: 2
build-test-lint:
jobs:
- build:
filters:
branches:
only:
- main
まとめ
これで、CircleCIを通じてKinstaへのReactアプリケーションのデプロイプロセスをカスタマイズすることができました。デプロイメントに対する柔軟性と十分な権限が確保され、チームでのステップの実行が効率的になるはずです。
CircleCIを採用することで、開発手法の向上に向けて大きく前進することになります。CI/CDパイプラインの自動化は、コードの質を保証するだけでなく、リリースサイクルの高速化に貢献します。
あなたはKinsta APIをどのように使っていますか?APIに追加してほしいエンドポイントはありますか?次に読みたいKinsta API関連の説明はどのようなものでしょうか?
コメントを残す