【Drupal】Aquiaプラットフォーム利用時のGit管理についてのベストプラクティスは？

仕事でAquiaに触れることがあったのですが、チーム開発でGitをどのように管理するべきかわからず、調べてみたことをメモします_φ(･_･

レビューワークフローについて

AcquiaのGitリポジトリ機能は、GitHubやGitLabが提供するような高度なGUIベースのプルリクエスト/マージリクエストやレビューワークフローを直接統合していません。 AcquiaのGitは、主に「コードの保管場所」と「デプロイメントのトリガー」としての役割を担っています。

そのため、GitHubやGitLabに慣れている開発者にとっては、AcquiaのGit機能だけではコードレビューやコラボレーションのワークフローが不十分に感じられるのは当然のことです。

では、Drupal + Acquia で開発を行っているチームが、どのようにコード改修やチーム開発を進めているのか、日本および海外の一般的なベストプラクティスについて考察します。

Drupal + Acquia チーム開発における一般的なベストプラクティス

多くのAcquia利用チームは、以下の2つのアプローチのいずれか、または両方を組み合わせてコードレビューとコラボレーションを実現しているようです。

アプローチ1: 外部Gitホスティングサービス (GitHub/GitLab) を「主要な開発リポジトリ」として併用する

これが最も一般的で推奨されるアプローチです。AcquiaのGitリポジトリは「デプロイメント用」として位置づけ、開発はGitHubやGitLab上で行います。

ワークフローの概要

1. 主要な開発リポジトリ:

   • GitHub.com または GitLab.com (または自社でホストするGitLab Enterprise) に、Drupalプロジェクトのプライベートリポジトリを作成します。
   • チームメンバーはすべて、この外部リポジトリでコードをプッシュ/プルし、ブランチを切って開発を行います。

2. 開発ワークフロー:

   • ブランチ戦略: Gitflow、GitHub Flow、または独自の機能ブランチワークフローを適用します。
     • main または master: 本番環境にデプロイされるコード。
     • develop: 開発中の最新コード。
     • feature/xxx, bugfix/xxx: 個々の機能開発やバグ修正用のブランチ。
   • プルリクエスト (PR) / マージリクエスト (MR):
     • 開発者が機能ブランチでの作業を終えたら、develop ブランチへのPR/MRを作成します。
     • GUI上でコードレビューを行います（GitHub/GitLabの機能を使用）。変更差分の確認、コメント、承認、変更依頼などをここで行います。
     • 必要なテスト（CI/CD）がパスし、レビューで承認が得られたら、develop ブランチにマージします。

3. Acquiaへの同期とデプロイ:

   • develop ブランチにマージされたコードが安定したと判断されたら、AcquiaのGitリポジトリにそのコードをプッシュします。
   • これは通常、GitHub Actions や GitLab CI/CD などのCI/CDパイプラインを組んで自動化します。
     • 例: develop ブランチが更新されたら、自動的にAcquiaのDev環境（またはステージング環境）に対応するAcquia Gitブランチにプッシュする。
     • 本番デプロイの場合は、main ブランチが更新されたら、同様にAcquiaのProd環境に対応するAcquia Gitブランチにプッシュする。
   • AcquiaのGitリポジトリへのプッシュがトリガーとなり、Acquiaプラットフォームのデプロイメントパイプラインが起動し、Drupalサイトがデプロイされます。

このアプローチのメリット

• GitHub/GitLabの強力な機能を利用: コードレビュー、イシュートラッカー、プロジェクト管理、高度なCI/CDなどを普段使い慣れた環境で利用できます。
• 開発ワークフローの柔軟性: 多様なブランチ戦略やレビュープロセスを適用できます。
• コードのバックアップとポータビリティ: Acquiaと外部Gitホスティングの両方にコードが存在するため、リスクが分散されます。
• Drupalコミュニティとの親和性: GitHubやGitLabはオープンソースプロジェクトの標準であり、コントリビューションにも対応しやすいです。

このアプローチのデメリット

• 二重管理と同期の複雑さ: Acquiaと外部Gitリポジトリの同期が必要です。CI/CDで自動化しないと手間がかかり、手動だとミスが発生しやすくなります。
• コスト: プライベートリポジトリの利用規模によっては、GitHub/GitLabの有料プランが必要になる場合があります（ただし、Acquiaの費用に比べれば小さいことが多い）。

アプローチ2: 外部Gitホスティングサービスなしで、レビューとデプロイメントのベストプラクティスを確立する

このアプローチは、セキュリティポリシー上外部サービス利用が難しい場合や、二重管理を避けたい場合に選択されますが、実装にはより厳格なプロセス管理が必要です。

ワークフローの概要

1. Acquia Gitリポジトリが唯一のソース:

   • 全ての開発は直接AcquiaのGitリポジトリに対して行われます。

2. 開発ワークフロー:

   • ブランチ戦略: AcquiaのGitリポジトリ内でブランチを切って開発を行います。
   • コードレビュー: AcquiaのGUI上にはPR/MR機能がないため、以下のいずれかの方法でコードレビューを行います。
     • ペアプログラミング: 2人の開発者が一緒にコードを書き、リアルタイムでレビューを行います。
     • ローカルでのレビュー: 開発者が自分のブランチをプッシュする前に、他の開発者がそのローカルリポジトリをプルしてレビューしたり、変更差分をファイルとしてエクスポートして共有したりします（非常に非効率的）。
     • 外部ツールとの連携（簡易版）:
       • Phabricatorのようなレビュー専用ツールを自社でホストして利用する。
       • または、Gitの変更差分を生成し、ChatOpsツール（Slackなど）やシンプルなファイル共有でレビュー依頼を行う。
     • JenkinsなどのCIツールでの可視化: JenkinsなどのCIツールで変更を検知し、その変更差分をJenkinsのWebUIで確認できるようにする（ただし、コメント機能などは限定的）。
   • マージ: レビューが完了し承認されたら、開発者が直接 develop ブランチなどにプッシュまたはマージします。この部分の手動管理が重要になります。

3. デプロイ:

   • AcquiaのGitリポジトリへのプッシュがトリガーとなり、Acquiaプラットフォームのデプロイメントパイプラインが起動します。

このアプローチのメリット

• シンプルなGitの場所: AcquiaのGitリポジトリが唯一のコードの場所になります。
• 外部サービスへの依存がない: セキュリティポリシーが厳しい場合に選択肢となります。

このアプローチのデメリット

• コードレビューの大きな課題: GUIベースのPR/MR機能がないため、コードレビューが非常に困難で非効率的になります。特に非同期でのレビューや詳細な議論が難しいです。
• 監査証跡の欠如: 誰が承認したか、どのような議論があったかの記録が残りにくいです。
• CI/CDの柔軟性の限界: Acquiaのパイプラインに依存するため、高度なカスタムCI/CDが難しい場合があります。
• 手動プロセスによるミス: レビューやマージが手動に頼る部分が多く、人為的ミスが発生しやすくなります。

日本と海外の一般的な傾向

• 海外の大規模プロジェクトやエンタープライズ事例:
  • ほとんどの場合、アプローチ1（外部Gitホスティングサービスとの併用） を採用しています。
  • 大規模なDrupalサイトの多くは、開発チームの分散化、厳格なコードレビュー、高度なCI/CDパイプラインを必要とするため、GitHub EnterpriseやGitLab Enterpriseのような機能を必須とします。Acquiaはデプロイの最終ターゲットとして利用し、開発は外部のGitサービスで行うのが標準です。
  • 特にオープンソースへの貢献文化が強い海外では、開発プロセスにGitHub/GitLabが深く根付いています。
• 日本の事例:
  • 日本でも同様にアプローチ1が主流になりつつあります。
  • かつてはアプローチ2のような手動レビューやペアプログラミング中心のチームもありましたが、効率性や品質、監査証跡の観点から、外部Gitサービスを併用するケースが増えています。
  • 特に、モダンな開発手法やDevOpsを取り入れている企業は、GitHub ActionsやGitLab CI/CDをフル活用しています。

結論と推奨

あなたがGitHubやGitLabに慣れているのであれば、アプローチ1（GitHubまたはGitLabを主要な開発リポジトリとして併用する） を採用することを強くお勧めします。

このアプローチは、初期設定の手間が少し増えますが、以下のような長期的なメリットがあります。

• チームの生産性と開発体験の向上: 慣れている強力なGUIでのレビューとコラボレーションが可能です。
• コード品質の向上: 厳格なコードレビューと自動テストを導入しやすくなります。
• デプロイメントの信頼性向上: CI/CDにより、本番環境へのデプロイが安全かつ自動化されます。

もし外部Gitサービスの使用に何らかの制約がある場合は、アプローチ2を検討することになりますが、その場合はコードレビュープロセスの手動化や、それに伴うリスクを十分に理解し、対策を講じる必要があります。