長期運用のためのDrupal開発入門

DrupalCon Nara で発表しました。

Transcript

1. 長期運用のための Drupal開発入門 村田 和子
2. 本日のセッションは・・・ 以下の方を対象としています Drupalで開発を始めようと思っている方 Drupal以外のアプリケーション開発経験がある このスライドはハッシュタグ #DrupalConNara をつけて配布予定 2
3. 自己紹介 村田和子 (@kazunoko_m) Drupal Meetup Tokyo 運営者のひとり 2015年からDrupal開発メイン Drupalのアーキテクチャ設計/モジュール開発が好 き 3
4. なぜ Drupalをおすすめしたいか 4
5. コミュニティが充実しているから 5
6. 充実していると思う理由 Drupalコミュニティが活発 Core だけではなく、Contribモジュールが多いのは貢献する人が多い 貢献する人が多い → 新規機能追加やメンテナンスが行われやすい 10年前と比べて2025年現在、(英語ですが)ドキュメントが豊富 コミュニティが意識的に育ててくれたドキュメントがある アクイア認定試験(Acquia Certification) が体系的にDrupalを知ること ができる [1] https://www.acquia.com/jp/support/training-certification/acquia-certification 6
7. セキュリティチームの存在 セキュリティチーム が存在し、CoreだけでなくContribモジュー ルもチェックする仕組みがある 通常だと日本時間 木曜早朝に通知あり セキュリティ通知の受け取り方 drupal.orgのアカウントを作成 My account の Edit タブ > My newsletters Security announcements にチェックをつけて保存 [1] https://www.drupal.org/security 7
8. リリーススケジュールが提示されている Coreに関してはアップグレード時の修正期間が考慮されたリリース サイクルが提示されている 全ての変更はissuesに存在し、Coreの大きな変更はチェンジレコ ードが存在する メジャーアップデートチェック用モジュールが存在し、アップデー トに手厚い [1] https://www.drupal.org/about/core/policies/core-release-cycles/schedule [2] https://www.drupal.org/about/core/policies/core-release-cycles/release-process-overview [3] https://www.drupal.org/list-changes/drupal [4] https://www.drupal.org/project/upgrade_status 8
9. まずコミュニティを追いかけよう Drupalを使うなら コミュニティが発信してくれる情報を追いかけよう 9
10. 今日のアジェンダ 1.Drupalアップデート戦略 計画の立て方、実際のアップデート内容 2.Drupal 長期運用向け構築トピック集 Composer管理、サイト構成管理、モジュール選定、CI/CD 10
11. 1.Drupalアップデート戦略 11
12. Coreのリリーススケジュール まず基盤であるCoreのリリーススケジュールを抑える必要がある バージョンに意味があるので、 先にセマンティックバージョニングを解説します 12
13. セマンティックバージョニング バージョン番号を MAJOR . MINOR . PATCH で表すルール MAJOR（メジャー）: 後方互換性を壊す変更 10 → 11 MINOR（マイナー）: 後方互換性を保ったまま新機能を追加 10.2 → 10.3 PATCH（パッチ） バグ修正やセキュリティ修正（10.2.5 → 10.2.6） 13
14. Drupal Core リリースの大枠 メジャーバージョンのリリース ・・・ 2年に1回 (偶数年) マイナーバージョンのリリース ・・・ 半年に1回 (6月, 12月) 新マイナーバージョンリリースされると、2つ前のバージョンがEOL [1] https://www.drupal.org/about/core/policies/core-release-cycles/release-process-overview 14
15. リリース参考 例: 2025/11/16 現在、サポートバージョン 10系 ・・・ 10.4, 10.5 11系 ・・・ 11.1, 11.2 10.6 と 11.3 がリリースされたら、10.4 と 11.1 は EOL 15
17. アップデート計画 最低でも1年に一回はマイナーバージョンアップが必要 可能であれば半年に1回 2年に一回はメジャーバージョンアップが必要 Contribモジュールだけでなく、PHPバージョンも足切りにあうので工数が 増加しがち PHPのバージョンのEOLに気をつける 10系で利用できるPHP8.1は2025年末にEOL 現在10系を使っている場合は11系を見越して先にPHP8.3までアップデー トが必要 17
18. バージョンアップ マイナーバージョンアップについては、新規開発・改修と並行して できる(気がする) 後半のテーマである環境が整っていればが前提 メジャーバージョンアップはまず調査が必要 18
19. でも大丈夫 強力な助っ人モジュールがある! 19
20. Upgrade Status モジュール Upgrade Status はDrupalに関するメジャーアップデートができる かどうか判定してくれるモジュール このモジュールを入れてNG項目を解消した上で、本格的なアップデー ト作業をすることをおすすめします [1] https://www.drupal.org/project/upgrade_status 20
21. Upgrade Status が素晴らしい理由 メジャーアップデート前に必要な作業が管理画面で確認できる 環境含む必須要件チェック PHP、DB、Drush など 未インストールモジュールリストアップ Contribモジュール・テーマの対応状況&issue カスタムモジュール・テーマの静的解析 Contribモジュール、テーマに対して実行することも可能 21
24. メジャーアップデートの壁 多くのContribモジュールを利用している場合、最新版がなかなか出 ないことがある Contribモジュールの最新対応版が出ない場合 数が多い場合はリスケも検討する 新バージョンが出たらとりあえずUpgrade Statusで調査 24
25. つづき 数は少ない・期限が迫ってきている場合、対処してアップデートす る issueのパッチを適用する dev版コミットID指定で導入 composer-drupal-lenientプラグイン でcomposerでバージョン依存チ ェックをスキップ [1] https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-drupal/core-version-compatibility-fixes- for-modules-with-unmerged-changes#s-usethe-composer-drupal-lenientpackage 25
26. アップデートの壁がなくなったら マイナーバージョンのアップグレード、通常の開発フローにのせるこ とができる [1] https://www.drupal.org/docs/updating-drupal/updating-drupal-core-via-composer 26
27. 通常の開発フローとは まず環境を整える必要がある 27
28. 2.Drupal 長期運用向け構築Tips 28
29. アジェンダ ローカル開発環境DDEV Composer モジュール選定 Configuration Management 静的解析/自動テスト CI/CD 29
32. ローカル開発環境 DDEV 自由に壊して戻せる開発環境を持つとお試ししやすい 2025年の今、ローカル環境はDDEV がおすすめ Docker、Docker Composeベース アドオンが豊富、Docker Compose ライクにコンテナ追加も可能 MailPit でメール捕捉が可能 Composer、Node コマンドがコンテナ内で実行可能 ローカルマシンにPHP、Nodeインストールしなくていい [1] https://ddev.com/ 32
33. DDEV インストール DDEV公式ドキュメントを元にローカルマシンにインストール [1] https://ddev.com/get-started/ 33
34. DDEVでのDrupalの環境作成 # composerでソース取得 composer create-project drupal/recommended-project my-project cd my-project # DDEVセットアップ・スタート ddev config ddev start # 環境情報確認 ddev status Drupal公式: https://www.drupal.org/docs/getting-started/installing-drupal/install-drupal-using-ddev-for-local- development 34
35. .ddev/config.yaml サンプル name: drupal-example-2025 type: drupal11 docroot: ./docroot php_version: "8.4" webserver_type: nginx-fpm xdebug_enabled: false additional_hostnames: [] additional_fqdns: [] database: type: mariadb version: "10.11" use_dns_when_possible: true composer_version: "2" web_environment: [] corepack_enable: true 35
36. DDEVの導入意義 環境差分を減らすことができる 差分 = バグに繋がりやすい 本番に近いミドルウェアを用意できる 複数人での開発環境をそろえやすくなる 標準構成なら定義ファイルは .ddev/config.yaml のみ プロジェクトをGitで管理して開発者の環境をそろえることができる 36
37. Composer Composer とはPHPの依存管理ツール。 Drupal自体もさまざまなパッケージが組み合わさってアプリケーショ ンとして成り立っているため、Composerによる管理が必須。 Drupal CMSにあるパッケージマネージャー経由でモジュールをアッ プデートした時もComposerの管理下で更新される。 [1] https://getcomposer.org/ [2] https://www.drupal.org/docs/develop/using-composer 37
38. Composer 重要なファイル composer.json 追加済みパッケージの大まかなバージョン指定とメタデータ(変数設定値) composer.lock 確定版情報、パッケージとバージョンの固定リスト 次のスライドから composer.json 内のポイントを解説します 38
39. composer.json その1 repositories には、メインリポジトリ Packagist 以外から配信さ れているパッケージ元のURLを定義 "repositories": [ { "type": "composer", "url": "https://packages.drupal.org/8" } ], 参考 https://github.com/drupal/recommended-project/blob/11.x/composer.json [1] https://packagist.org/ 39
40. composer.json その2 require は、追加したパッケージが存在 バージョン幅ありで指定可能 "require": { "composer/installers": "^2.3", "drupal/core-composer-scaffold": "^11", "drupal/core-recipe-unpack": "^11", "drupal/core-project-message": "^11", "drupal/core-recommended": "^11" }, 40
41. 再掲:セマンティックバージョニング バージョン番号を MAJOR.MINOR.PATCH で表すルール MAJOR（メジャー）: 後方互換性を壊す変更 10 → 11 MINOR（マイナー）: 後方互換性を保ったまま新機能を追加 10.2 → 10.3 PATCH（パッチ） バグ修正やセキュリティ修正（10.2.5 → 10.2.6） [1] https://semver.org/lang/ja/ [2] https://www.drupal.org/docs/getting-started/understanding-drupal/understanding-drupal-version-numbers 41
42. バージョン範囲指定 バージョンアップデートしたい時の挙動がバージョン先頭の ^ と ~ で変わることに注意 ^ (キャレット) 次のメジャー未満で更新 ^10.4.0 は、同じメジャー、マイナー/パッチバージョンが更新 composer update で 10.5系最新まで上がる可能性あり ~ (チルダ) : 同じマイナー、パッチバージョンだけ更新 ~10.4.0 は、10.4系内までバージョンアップ可能 composer update で 10.4系最新まで上がる可能性あり 42
43. バージョン指定 個人的おすすめ Drupal Core のパッケージ(drupal/core-から始まるパッケージ)は ~ をつけて管理。急なセキュリティによるバージョンアップが楽。 "require": { "drupal/core-composer-scaffold": "~11.2.3", "drupal/core-recipe-unpack": "~11.2.3", "drupal/core-recommended": "~11.2.3", "drush/drush": "^13.6" }, Coreのセキュリティアップデート時 ddev composer update "drupal/core-*" 43
44. composer.json その3 require-dev には、本番環境に不要な開発ツールパッケージが存在 "require-dev": { "drupal/core-dev": "~11.2.3" }, conflict には 追加を拒否するパッケージを指定 "conflict": { "drupal/drupal": "*" }, 44
45. composer 主なコマンド DDEV版 1 パッケージ追加 ddev composer require 'drupal/pathauto:^1.13' require-devに追加 ddev composer require --dev 'drupal/core-dev:~11.2.3' 45
46. composer 主なコマンド DDEV版 2 パッケージのアップデート ※パッケージ指定なしは全部アップデート ddev composer update "drupal/core-*" composer.jsonを手動でメタデータ変更後のcomposer.lock更新 ddev composer update --lock 46
47. composer 主なコマンド DDEV版 3 composer.lock に基づくインストール dev版 ddev composer install composer.lock に基づくインストール 本番向け ddev composer install --no-dev 47
48. Drupalで重要なComposerのプラグイン drupal/core-composer-scaffold cweagans/composer-patches drupal/core-dev (あとで紹介) 48
49. drupal/core-composer-scaffold composer install、composer update などのパッケージ更新時に 動作するComposerプラグイン Composerパッケージは原則 vendor ディレクトリに配置されるた め、Drupalが想定しているファイル構成へ置き換えてくれる ドキュメントルート (web、docroot) の中に index.php や coreデ ィレクトリを配置 49
50. core-composer-scaffold 設定値 "drupal-scaffold": { "locations": { "web-root": "docroot/" } }, "installer-paths": { "docroot/core": [ "type:drupal-core" ], "docroot/modules/contrib/{$name}": [ "type:drupal-module" ], 参考 https://www.drupal.org/docs/develop/using-composer/using-drupals-composer-scaffold 50
51. cweagans/composer-patches Composerの操作でパッチを自動適用するプラグイン Drupal.org の issueでまだマージされていない修正をパッチとして 反映するのに便利 51
52. パッチ追加例 "patches": { "drupal/core": { "#3530597": "./patches/core/date-field-default-value.patch", } } > 参考: https://www.bulblub.com/2018/08/composer_patch_pulugin/ パッチファイルはURL参照も可能。 ただしGitLabのマージリクエストでの修正の場合、パッチファイルを ダウンロードした上で適用した方がいい。 52
53. コントロールしたいパッケージはルートで管理 Composerは参照があればすべての依存パッケージを追加してくれる が、依存が深くなればなるほどバージョン競合解決が難しい 厳密にバージョンを管理したいパッケージはルートのcomposer.json に存在するように管理する Drupal Core Contribモジュール、テーマ core-recipe-unpack ができた経緯 https://www.drupal.org/node/3355485 53
54. Node 今回は割愛します。 迷ったらcoreのpackage.jsonやyarn.lock を参考にします。 [1] https://git.drupalcode.org/project/drupal/-/tree/11.x/core?ref_type=heads 54
55. Contribモジュール選定 結論 迷ったらDrupal CMSのレシピで採用されているモジュール 利用率の高いモジュールが多い メンテナンスの優先度が高いと思われる 55
56. それ以外の選び方 以下を見て判断する モジュールプロジェクトの状態 issues/リリース頻度 モジュールのソースコード 参考 https://www.acquia.com/jp/blog/evaluating-drupal-community-modules 56
57. モジュールプロジェクトの状態 モジュールのページのProject informationを確認 57
58. issues/リリース頻度 過去にDrupal Core のメジャーバージョンアップ対応がされている かどうか バグフィックスのパッチ提供、修正の頻度 利用数が多く提供期間が長いモジュールであれば気にしない 58
59. モジュールのソースコード 直接ソースコードを見る ソースコードのボリューム hook の数 プラグイン、サブスクライバー、サービス、ルーティングの数 AIに機能を解説してもらって、実際動かしてみるのも有効 59
60. Configuration Management とは 管理画面で設定したサイト構造や動作に関わる情報 = サイト構成 (Configuration) をファイル管理して、各環境で同期する機能 インフラ構成のコード化して管理・自動化する Infrastructure as Code（IaC）に近い思想 [1] https://www.drupal.org/docs/administering-a-drupal-site/configuration-management 60
61. サイト構成 具体例 管理メニューの「サイト構築」 「環境設定」に関する設定 例えば モジュール/テーマの有効化状態 コンテンツタイプ、ボキャブラリー、メディアタイプ フィールド Views ブロックレイアウト 61
62. Configuration Management の流れ 1. エクスポート Drushコマンドで構成をYAMLファイルとして出力 2. Gitバージョン管理 YAMLファイルをGit管理 3. インポート 各環境でインポート この手順で環境間の同期を実現する 62
63. サイト構成の同期 settings.phpにファイル出力ディレクトリを定義 $settings['config_sync_directory'] = '../config/default'; サイト構成のエクスポート ddev drush config:export サイト構成のインポート ddev drush config:import 63
64. サイト構成の同期のポイント サイト構成のエクスポート結果はレビューして必要な差分だけ残す 余分な差分は戻す 環境最新化の際にサイト構成のインポートを忘れないこと GitでPULL、ブランチ変更したらサイト構成のインポートを実行 最新化の手順の固定化、コマンド・シェルスクリプトでの一括実行がおすす め composer install、drush crなどと合わせて実行 64
65. 環境ごとに異なるサイト構成は？ API接続情報など環境ごとに変更したいサイト構成は次の手段で解決 する Configuration Split モジュール Config Ignore モジュール settings.php 65
66. Configuration Split Configuration Split モジュール はサイト構成の一部を分割して、 サブセットを作成できる メインのサイト構成セット + 有効化指定したサブセットでエクスポー ト/インポートできる [1] https://www.drupal.org/project/config_split 66
67. Configuration Split 使い方 1. サブセットを作成する ローカル用、開発環境用、検証環境用、本番環境用など 2. settings.php に有効化するサブセットを指定する // サンプル if (開発環境の場合) { $config['config_split.config_split.dev']['status'] = TRUE; } if (本番環境の場合) { $config['config_split.config_split.live']['status'] = TRUE; } 67
68. サブセットの作り方 参考ドキュメントを見てください ドキュメント https://www.drupal.org/docs/contributed-modules/configuration-split ブログ https://scrapbox.io/kazunoko/Drupalでの構成管理を強化するConfig_IgnoreとConfiguration_Split 68
69. Configuration Split 使い方のポイント モジュールの有効化を環境ごとに分けたい場合、 メインは無効化 + サブで有効化 Database Logging は基本無効化 + 開発環境用だけ有効化 サブセットのステータスはOFFで設定 サブセットのconfigにステータスがあるが無効化する 有効化は settings.php のみで指定する 69
70. Config Ignore Config Ignore モジュール は指定したサイト構成の同期を無効化で きる [1] https://www.drupal.org/project/config_ignore 70
71. Config Ignore 使い方 管理画面から無視したいサイト構成のIDを設定する ワイルドカードで広範囲に指定ができる webform.webform.* サイト構成のある値だけ無視する指定も可能 system.site:page.front 71
72. settings.php サイト構成をキーごとに上書きしたい場合、settings.php が有効 // バックトレース情報付きログを出力 if (開発環境の場合) { $config['system.logging']['error_level'] = 'verbose'; } 72
73. ここまで頑張ると composerでパッケージ管理 Configuration Managementでサイト構成を管理 → 環境最新化が自動化ができる 73
75. カスタムモジュールを支える静的解析、テスト PHP CodeSniffer PHPStan PHPUnit 75
76. drupal/core-dev パッケージ 静的解析、テストコード実行をしたいなら drupal/core-dev パッケージを導入すると簡単 ddev composer require --dev drupal/core-dev:~11.2.1 -W バージョンは drupal/core のバージョンと合わせる require-dev として扱う [1] https://packagist.org/packages/drupal/core-dev 76
77. PHP CodeSniffer とは コーディングスタンダードに沿って静的解析を実行しコードのクリー ンさと一貫性を維持するツール Drupalのコーディングスタンダード に沿ったルールセットが存在し drupal/core-devに内包されている [1] https://github.com/PHPCSStandards/PHP_CodeSniffer/ [2] https://www.drupal.org/docs/develop/standards [3] https://www.drupal.org/project/coder 77
78. PHP CodeSniffer セットアップ プロジェクトルートに phpcs.xml を作成 <?xml version="1.0" encoding="UTF-8"?> <ruleset name="Custom"> <description>Drupal コーディング標準用の PHP_CodeSniffer 設定</description> <arg name="extensions" value="engine,inc,install,module,php,profile,test,theme,yml"/> <rule ref="Drupal"/> <file>docroot/modules/custom</file> <file>docroot/themes/custom</file> </ruleset> 実行 ddev exec phpcs 78
79. PHP CodeSniffer エラー例 FILE: /var/www/html/docroot/modules/custom/site_notice/tests/src/Unit/SiteNoticeBlockTest.php ------------------------------------------------------------------------------------------------------------------------------- FOUND 3 ERRORS AND 1 WARNING AFFECTING 14 LINES ------------------------------------------------------------------------------------------------------------------------------- 13 | ERROR | [x] Missing class doc comment 16 | ERROR | [x] Missing function doc comment 19 | ERROR | [x] Inline comments must end in full-stops, exclamation marks, question marks, colons, or closing parentheses 132 | WARNING | [ ] Line exceeds 80 characters; contains 83 characters ------------------------------------------------------------------------------------------------------------------------------- PHPCBF CAN FIX THE 3 MARKED SNIFF VIOLATIONS AUTOMATICALLY ------------------------------------------------------------------------------------------------------------------------------- Time: 63ms; Memory: 6MB Failed to execute command `phpcs`: exit status 2 79
80. PHP CodeSniffer の自動修正 ある程度は phpcbf コマンドで修正可能 実行 ddev exec phpcbf 80
81. PHPStan 静的解析でPHPのバグを発見するコンセプトのツール Drupalに特化したルールが存在する [1] https://github.com/phpstan/phpstan [2] https://www.drupal.org/docs/develop/development-tools/phpstan 81
82. PHPStan セットアップ プロジェクトルートに phpstan.neon を作成 parameters: phpVersion: 80300 # PHP8.3 level: 5 paths: - docroot/modules/custom ignoreErrors: - "#^Unsafe usage of new static#" 実行 ddev exec phpstan 82
83. PHPStan エラー例 Note: Using configuration file /var/www/html/phpstan.neon. 3/3 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100% ------ -------------------------------------------------------------------------------------------------------------------------------------- Line site_notice/tests/src/Unit/SiteNoticeBlockTest.php ------ -------------------------------------------------------------------------------------------------------------------------------------- 80 Call to method PHPUnit\Framework\Assert::assertIsArray() with array will always evaluate to true. method.alreadyNarrowedType Because the type is coming from a PHPDoc, you can turn off this check by setting treatPhpDocTypesAsCertain: false in your phpstan .neon. ------ -------------------------------------------------------------------------------------------------------------------------------------- [ERROR] Found 1 error Failed to execute command `phpstan`: exit status 1 83
84. PHPStan 導入ポイント レベルは0から始めて最大5までがおすすめ レベル6とDrupalのRender Array定義が相性が悪い Rule Levels 補足 :Drupal11.3でレンダリング要素をオブジェクトで作成できる機 能が登場 します。オブジェクトでの実装が浸透して、メソッドの引 数もオブジェクトになったらこの問題は解消します。 [1] https://www.drupal.org/node/3532720 84
85. PHPUnit PHPのユニットテストフレームワークで、Drupal拡張が存在する [1] https://www.drupal.org/docs/develop/automated-testing/phpunit-in-drupal 85
86. PHPUnit セットアップ core/phpunit.xml.distをプロジェクトルートにコピー 設定値変更 bootstrapのパス ・・・ docroot/core/bootstrap.php や web/core/bootstrap.php など SIMPLETEST_BASE_URL ・・・ http://localhost SIMPLETEST_DB の変更 ・・・ DDEV例: mysql://db:db@db/test テスト対象の設定　<testsuites></testsuites> のカスタマイズ [1] https://github.com/kazukomurata/drupal-example-2025/blob/main/phpunit.xml 86
87. PHPUnit 実行 実行 ddev exec phpunit 87
88. PHPUnit エラー例 PHPUnit 11.5.34 by Sebastian Bergmann and contributors. Runtime: PHP 8.4.10 Configuration: /var/www/html/phpunit.xml F.. 3 / 3 (100%) Time: 00:00.017, Memory: 6.00 MB There was 1 failure: 1) Drupal\Tests\site_notice\Unit\SiteNoticeBlockTest::testBuildBeforeStartReturnsEmptyWithCacheUntilStart Failed asserting that Array &0 [] is null. /var/www/html/docroot/modules/custom/site_notice/tests/src/Unit/SiteNoticeBlockTest.php:80 FAILURES! Tests: 3, Assertions: 11, Failures: 1. Failed to execute command `phpunit docroot/modules/custom/`: exit status 1 88
89. PHPUnit in Drupal 種類 種類 おすすめ Unit Drupalに依存しない機能のテスト Kernel Drupalのサービスに依存する機能のテスト Functional ブラウザ風テスト FunctionalJavascript JavaScriptの動作確認テスト 89
90. PHPUnit Tips 最初に追加するなら実行までの難易度低めのKernelテスト サービスやメソッド呼び出しでエラーにならないことのテストを用意するの がおすすめ DrupalのアップグレードでAPIの変更、非推奨APIを検知できる サイト構成、Content Entityの用意はCreationTraitを使うのがお すすめ Nodeなら ContentTypeCreationTrait、NodeCreationTrait 90
91. CI/CDとは ソースコードに変更があった時に静的解析や自動テストを実行した り、検証・本番環境にデプロイしたりする仕組み 現在、Gitリポジトリのイベントで実行するものが主流 プルリクエスト、マージリクエスト コードの静的解析、自動テスト ブランチへのプッシュ ブランチに紐づく環境にデプロイ タグ作成時 対象環境にデプロイ 91
92. CI/CD 選択肢 GitHub Actions GitLab CI/CD CircleCI Travis CI etc.. 92
93. PaaS 提供CI/CDを使う Acquia Cloud Platform Pantheon Platform.sh amazee.io etc.. 93
94. GitHub Actions 今回は GitHub Actions の一例を紹介します。 ひととおり無料枠で全部できます。 94
95. GitHub Actions GitHub Actions のワークフローを用意すると実行可能 95
96. GitHub Actions 静的解析と自動テスト内容 GitHubのホストでコンテナ起動し、指定したコマンドが実行される 実行タイミング: プルリクエスト イメージ: ubuntu-latest 実行内容 composer install 各コマンド実行 96
97. GitHub Actions 静的解析と自動テスト サンプル : /.github/workflow リポジトリ https://github.com/kazukomurata/drupal-example-2025 97
98. GitHub Actions の CodeQL Settings > Advanced Security で Code scanning を設定、 CodeQL による静的解析が可能 [1] https://docs.github.com/ja/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning- with-codeql 98
99. GitHub Actions デプロイ AWS EC2のようなサーバにデプロイ サーバにGitHubセルフホステッドランナー設定 (SSHで接続ではない) 実行先をサーバーにする AWS ECSのようなコンテナサービス Dockerイメージをビルド、リポジトリに登録 コンテナ更新指示を実行する 99
100. GitHub Actions セルフホステッドランナー の場合 GitHub の Settings > Actions > Runners で 新規追加で表示さ れる指示に従ってランナー追加 & サービス常時起動 [1] https://docs.github.com/ja/actions/how-tos/manage-runners/self-hosted-runners/add-runners 100
101. .github/workflows/deploy.yml 作成 name: Deploy on: push: branches: - main permissions: contents: read jobs: deploy: runs-on: self-hosted defaults: run: shell: bash working-directory: ${{ vars.APP_ROOT }} steps: - name: "Update" run: | git pull origin main composer install --no-dev vendor/bin/drush cr vendor/bin/drush cim -y vendor/bin/drush cr vendor/bin/drush updb -y 101
102. コレできる 気がする！ 102
103. 長期運用を目指すには 環境を整えて (新規開発・改修を進めつつも) 定期的にCoreバージョンアップデートを実行しよう Drupalコミュニティについていこう 103
104. ご清聴ありがとうございました 104