DrupalプロジェクトでAquiaを利用しつつも、このままではいろいろとリスクがあると感じたので、GitHubをホスティングサービスを利用する方法について、調べてみました_φ(・_・
Acquiaを利用しつつ、GitHubまたはGitLabを「主要な開発リポジトリ」として併用する具体的な手順について
このアプローチは、チーム開発の効率性、コード品質、レビュープロセスの透明性を大幅に向上させます。少し複雑に感じるかもしれませんが、一度構築すれば強力な開発基盤となります。
GitHub/GitLabを主要リポジトリとする開発ワークフロー
この手順では、GitHubを例に進めますが、GitLabでも同様の概念と機能で実現可能です。
1. プロジェクトのリポジトリ構成
まず、Gitリポジトリの構成を明確にします。
- GitHub/GitLab (主要開発リポジトリ):
- あなたのチームが日常的にコードをプッシュ、プル、ブランチ、プルリクエスト/マージリクエスト(PR/MR)を作成する場所です。
main
、develop
、feature/xxx
、bugfix/xxx
などの開発ブランチがここに存在します。- CI/CD(GitHub Actionsなど) もここで設定し、テストやLintチェックを実行します。
- Acquia Git (デプロイ用リポジトリ):
- Acquiaのデプロイメントパイプラインが監視しているGitリポジトリです。
- 通常、
master
(本番)、develop
(ステージング/開発)、test
(テスト)などの環境ブランチがあります。 - このリポジトリには直接プッシュしないことを原則とします。外部Gitホスティングからの自動同期または手動同期でのみ更新します。
2. GitHub (またはGitLab) でプロジェクトをセットアップする
-
新しいプライベートリポジトリの作成:
- GitHub.com にログインし、「New repository」を作成します。
- リポジトリ名を決定し、必ず「Private」を選択します。
Add a README file
、.gitignore
(PHP用またはDrupal用)、Choose a license
は任意で追加しても構いませんが、既存のプロジェクトを移行する場合は後で調整できます。
-
既存のDrupalプロジェクトを新しいGitHubリポジトリにプッシュ:
- ローカルのDrupalプロジェクトディレクトリに移動します。
- もし既にローカルでGit管理されているなら、新しいGitHubリポジトリをリモートに追加し、プッシュします。
- もしローカルでまだGit管理されていないなら、以下の手順で初期化します。
- 重要: この時点で、
.gitignore
ファイルが適切に設定されていることを再確認してください。vendor/
、web/core/
、web/modules/contrib/
、web/themes/contrib/
、web/sites/*/files/
など、Composerで管理されるものやユーザーアップロードファイルはGitリポジトリに含まれないようにします。
3. Gitワークフローの確立 (GitHub/GitLab上)
少人数チームでも、一貫したワークフローは必須です。
-
ブランチ戦略の採用:
- GitHub Flow: 最もシンプルで、迅速なデプロイに適しています。
main
ブランチのみが存在し、機能開発はすべてフィーチャーブランチで行い、main
に直接PR/MRでマージします。 - Gitflow: より厳格なリリースサイクルを持つ場合に適しています。
main
とdevelop
の2つの主要ブランチがあり、フィーチャーブランチはdevelop
から派生します。 - 推奨: 少人数チームなら、まずはシンプルな GitHub Flow またはそれに近い形から始めるのが良いでしょう。
- GitHub Flow: 最もシンプルで、迅速なデプロイに適しています。
-
プルリクエスト (Pull Request: PR) / マージリクエスト (Merge Request: MR) の活用:
- 「フィーチャーブランチ」の作成: 新しい機能開発やバグ修正を行う際は、必ず
main
(またはdevelop
)から新しいブランチ(例:feature/add-contact-form
)を作成します。 - コードの変更とコミット: 必要なコード変更を行い、ローカルでコミットします。
- プッシュ: 自分のフィーチャーブランチをGitHubにプッシュします。
- プルリクエストの作成: GitHubのWeb UIから、プッシュしたフィーチャーブランチから
main
(またはdevelop
)ブランチへのプルリクエストを作成します。- PRのタイトルや説明に、何を変更したのか、その目的、関連するイシュー番号などを明確に記述します。
- レビュー担当者(チームメンバー)をアサインします。
- コードレビュー:
- レビュー担当者はPRの内容(コード差分)を確認し、コメントや質問、変更要求を行います。
- 必要に応じて、CI/CDが自動テストを実行し、その結果もPRに表示されます。
- 議論を重ね、コードが合意に至ったら、レビュー担当者が承認 (Approve) します。
- マージ: 承認されたら、PRを
main
(またはdevelop
)ブランチにマージします。GitHubのWeb UIから「Merge pull request」ボタンをクリックするのが一般的です。
- 「フィーチャーブランチ」の作成: 新しい機能開発やバグ修正を行う際は、必ず
4. CI/CD (継続的インテグレーション/継続的デリバリー) の設定
これが、GitHub/GitLabとAcquiaを連携させる肝となる部分です。
-
GitHub Actions (またはGitLab CI/CD) の設定:
- GitHubリポジトリのルートに
.github/workflows
ディレクトリを作成し、その中にYAMLファイル(例:deploy-to-acquia.yml
)を作成します。 - このYAMLファイルにCI/CDパイプラインの定義を記述します。
- GitHubリポジトリのルートに
-
パイプラインで自動化すること(例):
- トリガー:
main
またはdevelop
ブランチへのプッシュ(またはPRのマージ)をトリガーとする。 - 環境セットアップ: Node.js, PHP, Composer などの環境を準備。
- Composer依存関係のインストール:
composer install
を実行。 - コード品質チェック: PHPStan, PHP_CodeSniffer, ESLint などでコードの品質を自動チェック。
- 自動テスト: PHPUnit、Behat などでユニットテスト、機能テストを実行。
- Acquiaへのプッシュ:
- すべてのテストがパスしたら、AcquiaのGitリポジトリにコードをプッシュします。
- これには、Acquia GitリポジトリへのSSHキー(デプロイキー)またはトークンをGitHubのSecretsに安全に保存し、CI/CDワークフローから利用します。
- 例:
注意: 上記の例はあくまで雛形です。実際のAcquiaのGit URL、SSHキーの設定、デプロイブランチの指定(例: GitHubの
main
をAcquiaのmaster
へ、GitHubのdevelop
をAcquiaのdevelop
へなど)は、あなたのAcquiaプロジェクトの構成に合わせて調整してください。--force
オプションの使用は慎重に検討し、チーム内で合意を取ってください。
- トリガー:
5. 環境とデプロイメント
-
DDEV / Lando を活用:
- 開発者はローカル環境でDDEVまたはLandoを使用し、GitHub/GitLabからクローンしたコードで開発を行います。
- データベースダンプはAcquiaから取得し、DDEV/Landoにインポートします。
ddev drush updb
やddev drush cim
は、ローカル環境でコード変更と設定変更を適用するために頻繁に利用します。
-
Acquiaの役割:
- 環境管理: 開発、ステージング、本番などの環境を提供します。
- デプロイメント: AcquiaのGitリポジトリへのプッシュを検知し、設定されたブランチに基づいて自動的にデプロイを実行します。
- データベース同期: AcquiaのGUIやDrushコマンドを使って、環境間のデータベースのコピーや同期を行います。
まとめ
このアプローチは、GitHub/GitLabの優れたコラボレーション機能を活用しつつ、AcquiaのDrupalに最適化されたホスティングとデプロイメントパイプラインを利用するという、Drupalエンタープライズ開発における一般的な「分業体制」 です。
初期設定は少し手間がかかりますが、一度構築してしまえば、
- コードレビューと品質管理が格段に向上する
- チームメンバー間のコラボレーションがスムーズになる
- デプロイプロセスが自動化され、ミスが減る
といった大きなメリットを享受できます。
ぜひ、このアプローチを検討してみてください。