【Drupal】Acquiaを利用しつつ、GitHubまたはGitLabを「主要な開発リポジトリ」として併用するアプローチ

2025.06.09
この記事は約11分で読めます。

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) でプロジェクトをセットアップする

  1. 新しいプライベートリポジトリの作成:

    • GitHub.com にログインし、「New repository」を作成します。
    • リポジトリ名を決定し、必ず「Private」を選択します。
    • Add a README file、.gitignore (PHP用またはDrupal用)、Choose a license は任意で追加しても構いませんが、既存のプロジェクトを移行する場合は後で調整できます。

  2. 既存のDrupalプロジェクトを新しいGitHubリポジトリにプッシュ:

    • ローカルのDrupalプロジェクトディレクトリに移動します。
    • もし既にローカルでGit管理されているなら、新しいGitHubリポジトリをリモートに追加し、プッシュします。
    cd /path/to/your/my-drupal-project
git remote set-url origin https://github.com/your-username/your-repo-name.git # 既存のリモートを新しいGitHub URLに設定
# あるいは、既存のリモート名がacquiaなど特定のもので、新しいものを追加する場合
# git remote add github https://github.com/your-username/your-repo-name.git
git push -u origin main # mainブランチをGitHubにプッシュし、追跡設定
    • もしローカルでまだGit管理されていないなら、以下の手順で初期化します。
    cd /path/to/your/my-drupal-project
git init
git add .
git commit -m "Initial commit of Drupal project"
git branch -M main # メインブランチ名を 'main' に設定
git remote add origin https://github.com/your-username/your-repo-name.git
git push -u origin main
    • 重要: この時点で、.gitignore ファイルが適切に設定されていることを再確認してください。vendor/、web/core/、web/modules/contrib/、web/themes/contrib/、web/sites/*/files/ など、Composerで管理されるものやユーザーアップロードファイルはGitリポジトリに含まれないようにします。

3. Gitワークフローの確立 (GitHub/GitLab上)

少人数チームでも、一貫したワークフローは必須です。

  1. ブランチ戦略の採用:

    • GitHub Flow: 最もシンプルで、迅速なデプロイに適しています。main ブランチのみが存在し、機能開発はすべてフィーチャーブランチで行い、main に直接PR/MRでマージします。
    • Gitflow: より厳格なリリースサイクルを持つ場合に適しています。main と develop の2つの主要ブランチがあり、フィーチャーブランチは develop から派生します。
    • 推奨: 少人数チームなら、まずはシンプルな GitHub Flow またはそれに近い形から始めるのが良いでしょう。

  2. プルリクエスト (Pull Request: PR) / マージリクエスト (Merge Request: MR) の活用:

    • 「フィーチャーブランチ」の作成: 新しい機能開発やバグ修正を行う際は、必ずmain（またはdevelop）から新しいブランチ（例: feature/add-contact-form）を作成します。 
      git checkout main
git pull origin main # 最新の状態に更新
git checkout -b feature/add-contact-form
    • コードの変更とコミット: 必要なコード変更を行い、ローカルでコミットします。
    • プッシュ: 自分のフィーチャーブランチをGitHubにプッシュします。 
      git push origin feature/add-contact-form
    • プルリクエストの作成: 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を連携させる肝となる部分です。

  1. GitHub Actions (またはGitLab CI/CD) の設定:

    • GitHubリポジトリのルートに .github/workflows ディレクトリを作成し、その中にYAMLファイル（例: deploy-to-acquia.yml）を作成します。
    • このYAMLファイルにCI/CDパイプラインの定義を記述します。

  2. パイプラインで自動化すること（例）:

    • トリガー: 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ワークフローから利用します。
      • 例: 
        name: Deploy to Acquia

on:
  push:
    branches:
      - main # mainブランチへのプッシュをトリガー

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2' # 使用するPHPバージョン
          tools: composer
          coverage: none

      - name: Install Composer dependencies
        run: composer install --no-dev --prefer-dist

      - name: Add Acquia SSH Key
        uses: webfactory/ssh-agent@v0.8.0
        with:
          ssh-private-key: ${{ secrets.ACQUIA_SSH_PRIVATE_KEY }}

      - name: Configure Git for Acquia
        run: |
          git config --global user.email "github-actions@example.com"
          git config --global user.name "GitHub Actions"

      - name: Add Acquia Git remote
        run: git remote add acquia ssh://<your_acquia_username>@<your_acquia_repo_url>/<your_acquia_repo_name>.git

      - name: Push to Acquia Git (Main branch to master)
        run: |
          git fetch acquia master:master # Acquiaのmasterブランチをローカルにフェッチ
          git push acquia main:master --force # 強制プッシュでAcquiaのmasterを更新
          # --forceは注意して使うべきですが、CI/CDでの自動同期では使われることがあります。
          # もしAcquiaのmasterブランチに直接コミットする人がいない場合のみ安全です。
          # 理想的には、git push acquia HEAD:master とし、競合がないことを確認します。

        注意: 上記の例はあくまで雛形です。実際のAcquiaのGit URL、SSHキーの設定、デプロイブランチの指定（例: GitHubのmainをAcquiaのmasterへ、GitHubのdevelopをAcquiaのdevelopへなど）は、あなたのAcquiaプロジェクトの構成に合わせて調整してください。--force オプションの使用は慎重に検討し、チーム内で合意を取ってください。

5. 環境とデプロイメント

  1. DDEV / Lando を活用:

    • 開発者はローカル環境でDDEVまたはLandoを使用し、GitHub/GitLabからクローンしたコードで開発を行います。
    • データベースダンプはAcquiaから取得し、DDEV/Landoにインポートします。
    • ddev drush updb や ddev drush cim は、ローカル環境でコード変更と設定変更を適用するために頻繁に利用します。

  2. Acquiaの役割:

    • 環境管理: 開発、ステージング、本番などの環境を提供します。
    • デプロイメント: AcquiaのGitリポジトリへのプッシュを検知し、設定されたブランチに基づいて自動的にデプロイを実行します。
    • データベース同期: AcquiaのGUIやDrushコマンドを使って、環境間のデータベースのコピーや同期を行います。

まとめ

このアプローチは、GitHub/GitLabの優れたコラボレーション機能を活用しつつ、AcquiaのDrupalに最適化されたホスティングとデプロイメントパイプラインを利用するという、Drupalエンタープライズ開発における一般的な「分業体制」 です。

初期設定は少し手間がかかりますが、一度構築してしまえば、

  • コードレビューと品質管理が格段に向上する
  • チームメンバー間のコラボレーションがスムーズになる
  • デプロイプロセスが自動化され、ミスが減る

といった大きなメリットを享受できます。

ぜひ、このアプローチを検討してみてください。

タイトルとURLをコピーしました