目次

まえがき

第1章 GitLab.comで手軽に始めるCI環境構築

1.1 CI/CDって?
1.2 SaaS環境でFreeプランを使用する
1.3 パイプラインを作る
1.4 まとめ

第2章 オンプレミスで自分だけのCI環境構築

2.1 Self-Managed環境でFreeプランを使用する
2.2 事前設定
2.3 GitLabのインストール
2.4 テスト用プロジェクトの作成
2.5 GitLab Runnerのインストール
2.6 GitLab Runner の設定
2.7 パイプラインを作る
2.8 Docker Executorを利用する
2.9 まとめ

第3章 モジュール開発でCI実践

3.1 事前準備
3.2 Hello Worldモジュールを作る
3.3 コーディング規約のチェックをCIに組み込む
3.4 アーティファクト
3.5 CDにつなげていく
3.6 コンテナを中心としたCI/CD環境の構築
3.7 まとめ

第4章 Drushとサイトエイリアスで楽々サイト管理

4.1 サイトエイリアスの使い方
4.2 ローカルで利用する
4.3 Dockerコンテナで利用する
4.4 リモートサイトへの適用
4.5 まとめ

第5章 Groupモジュールで会員限定サイトを構築

5.1 Groupモジュールとは
5.2 DEN Japanのユースケース
5.3 モジュールのインストール
5.4 各Drupal Meetupの定義
5.5 おわりに

第6章 JamstackでヘッドレスDrupalを爆速構築

6.1 ヘッドレスDrupalとは
6.2 Jamstackとは
6.3 実際にサイト作成してみよう
6.4 おわりに

第7章 Webformで簡単フォーム作成

7.1 Webformとは
7.2 Webformの基本操作
7.3 便利な機能
7.4 おわりに

第8章 MauticとDrupalで行う自動連携

8.1 Drupalの外部サービス連携について
8.2 Mautic環境の用意
8.3 Webform Mauticモジュールのインストール
8.4 Webformでフォームを作成
8.5 連携をテストする
8.6 おわりに

あとがき

まえがき

小松 高廣

 本書をお⼿に取ってくださり、ありがとうございます。2021年4月に出版させていただきました「Drupal 9 Web開発ことはじめ」に続いて、2冊目のDrupal商業誌の執筆となりました。前回の執筆後、各所で様々な反響をいただくことができ、執筆メンバーそれぞれの努力が報われたと感じており、とても嬉しく思っています。

 さて、今回もさらに一人でも多くの方々にDrupalの奥深さを知ってもらえる機会を作ろうと、内容に吟味を重ね、各メンバーが精一杯の執筆を行いました。
「こんなDrupalの使い方もあるのかぁ」
「これを応用すればDrupalであんなこともできそう!」
という、どこかでちょっぴり役に立つヒントが満載の1冊に仕上がったと思います。最後までゆっくりとお楽しみいただけたら幸いです。

本書の流れ

 本書は、Drupalをインストールして簡単なサイトを作ったことがあるDrupalビギナーを想定として、

 ・GitLab.comで手軽に始めるCI環境構築

 ・オンプレミスで自分だけのCI環境構築

 ・モジュール開発でCI実践

 ・Drushとサイトエイリアスで楽々サイト管理

 ・Groupモジュールで会員限定サイトを構築

 ・JamstackでヘッドレスDrupalを爆速構築

 ・Webformで簡単フォーム作成

 ・MauticとDrupalで行う自動連携

 といった、Drupalをもっと深く使っていくためのトピックスを取り上げています。

 各章の末尾には関連した4コマ漫画を載せていますので、肩に力をいれず、ぜひ楽しみながら内容の理解を深めていただけたらと思います。

 本書のタイトルが「Drupal 9 おいしいレシピ集」となっているように、各章は今すぐ使える実践的なテクニックをオムニバス形式として構成しています。すべての章を順番に読んでいただいても、お好きな章から読んでいただいても大丈夫です。著者それぞれに思い入れのあるトピックを選んで書き上げた渾身の一冊ですので、最終的にはぜひすべての章に目を通していただけたら幸いです。

前提とする知識

 本書を読むにあたり、次のような知識があるとより理解が深まります。

 ・Drupalの基礎知識

 ・Linux コマンドの基礎知識

 ・WordPress、concrete5、Joomlaなどの他CMSの利用経験

 ・Web開発の基礎知識

 まだDrupalを触ったことがないという場合には、ぜひ既刊書「Drupal 9 Web開発ことはじめ」(株式会社インプレスR&D)1と併せてお手に取っていただけましたら幸いです。Drupalの概要から基本まで丁寧に解説していますので、一緒に読んでいただけると、理解がより一層深まることと思います。

ソフトウェアバージョンおよび動作環境

 本書はDrupal 9.2.xにて動作確認を行っています。各章のトピックに固有なソフトウェアおよびハードウェアの要件については、章内の本文にてご確認ください。

謝辞

 Drupal Meetup 豊田支部として執筆した作品を手に取ってくださり、SNSやMeetupをはじめとして、各所でお寄せくださったご意見・ご感想が今回の執筆の原動力となっています。執筆を応援してくださった方々に、この場を借りて心より感謝を申し上げます。

 そして、これまでDrupalをよりよくするために様々な形で貢献してくださった世界中の方々に、心より感謝を申し上げます。こうして私たちがDrupalと出会い、Drupalの書籍を執筆できているのも、今までに貢献してくださった方々の足跡があってこそです。本当にどうもありがとうございます。

 本書の編集および出版には、山城敬様をはじめとして、株式会社インプレスR&Dの皆様に多大なご協力・ご尽力をいただきました。数少ない日本語Drupalの書籍として、このような形でより多くの方々に届けられる機会をいただけたことに、深く感謝を申し上げます。

 本書は、Drupal Meetupに集まっているコミュニティーメンバーで執筆し、相互に原稿のレビューを行いました。メンバーそれぞれ普段のお仕事がある中で、貴重な時間を捻出しながら執筆活動にコミットしてくださったことは、きっと今後のDrupalの発展に寄与するものと思います。末筆ではありますが、各執筆メンバーのDrupalに対する貢献という不断の努力に、心より感謝いたします。

底本について

 本書籍は、技術系同人誌即売会「技術書典11」で頒布されたものを底本としています。

1. https://www.amazon.co.jp/dp/B0922326NR

第1章 GitLab.comで手軽に始めるCI環境構築

本章では、テーマやモジュールの開発において、CIを行うための環境をGitLab.comで提供されているSaaS環境で構築する方法について解説します。

小松 高廣

1.1 CI/CDって?

 あなたがカレー屋さんをしていて、カレーを作り、注文してくれたお客さんの家まで届ける、という状況を考えてみます。そのときに考えること・やることは

 1.カレーを通してお客さんの空腹を満たして幸せにすることをゴールにする

 2.どんなカレーが世の中で求められているかを調べる

 3.どんな具材でカレーを作り、どうやって届けるかを決める

 4.道具と具材、配送手段を用意する

 5.カレーを作る手順を進める

 6.できたものを味見する

 7.うまくいかないところを直す

 8.できたカレーをお客さんの家まで届ける

というプロセスになるでしょう。

 本章をお読みくださっている方であれば、普段から何らかのプログラミング言語でコードを書き、日々開発に勤しんでおられるかもしれません。Drupalのカスタムテーマやカスタムモジュールを開発することは、Drupalというプラットフォーム上でひとつのPHPアプリケーションを書く行為といえます。この場合を考えてみると、先ほどのカレー作りと同じような、非常に多岐に渡るプロセスを経ることがわかります。

 1.テーマやモジュールを通して、ユーザーが実現したい機能の実装をゴールにする

 2.作りたいテーマやモジュールの要件を決める

 3.実現できそうな内容を仕様としてまとめ、どうやって運用するのかを決める

 4.開発環境と運用環境を構築する

 5.コーディングをする

 6.作ったものをテストする

 7.うまくいかないところを直す

 8.完成したテーマやモジュールをDrupalにインストールして運用する

仕事として何らかの製品やサービスを作る場合には、契約を交わしたり、決済をするなど、他にも細かいプロセスはたくさんありますが、「何かを作ってユーザーへ届ける」という部分だけに着目しても、いかに多岐に渡る作業を行っているかがわかると思います。

 何らかのコーディングをしたことがある人は、「性質の異なる作業を一度にやることは非効率である」ことを身に染みて理解しているのではないでしょうか。人間は多かれ少なかれ、必ずミスをする生き物です。

 たとえば、「メモ帳を使いながら1000行のPHPファイルを一気に書き、サーバーにアップロードして表示させてみよう」とするのはあまりに無謀です。どんなに集中力が高い人であっても、変数名や関数名のスペリングをミスしてしまったり、セミコロンや括弧などを誤字脱字してしまったりと、きっと何らかのエラーを出してしまい、Webブラウザーで表示される画面が真っ白になってしまうかもしれません。

 エラーコードを細かく読み込みながら、1000行のうちで間違えたところをひとつひとつ順番に修正していく、というのは、考えただけでも非常に骨の折れる作業です。すぐに思いつくよりよい方法は、「一度の作業で行う範囲をできるだけ狭くして、作業を分割する」ということです。「少しだけ書いて、表示を確認してみる」という、いわれてみれば「たったそれだけ?」と思えることであっても、デバッグする範囲が狭くなるので、開発全体のスピードは上がります。

 「CI/CD」とは「Continuous Integration / Continuous Deployment(Delivery)」の略で、日本語では「継続的インテグレーション / 継続的デプロイ(継続的デリバリー)」と訳されます。しかし、単にContinuousを継続的と訳しただけで、直訳すぎて少々意味がわかりにくいです。先ほどのカレーを作ったり、コードを書いたりする場合であれば、4.から8.に相当する部分がCI/CDを適用する範囲になります。

 全く味見をしないで料理を作り、完成したものをお皿にすべて盛り付けてから初めて食べてみる、ということをする人はあまりいないと思います。料理の途中で火の通り加減を確かめてみたり、味付けが濃いか薄いかを確かめたりすることで、いざできあがって口に入れたときに「思ってたんと違う……」という悲劇を避けることができます(自分だけが食べる料理であれば、作ったのは自分自身なので自分が我慢して食べるだけで済みますが、他の人に食べてもらう場合にそれを続けてしまうと、次回は食べてもらえないかもしれません……)。

 「何かをチェックする」作業はあまりに単純であることが多く、本来人間に向いていない作業です。また、人間が行うことで、チェックする人の習熟度や加減によってOKとする基準が曖昧になり、できあがるものの品質はバラバラになります。

 著者はCI/CDの本質を「取るに足らないくらい小さな改善点をいかに早い段階で見つけて修正し、それを次のプロセスに生かすか、という一連の流れを自動化する」ことと等価だと思っています。

 CI/CDは、新しく作ったものを今まで作ったものとうまく統合しながら、どうやってユーザーへ提供するか、という広範な方法論です。その適用範囲は、Drupalにおけるアプリ開発や、何らかのプログラミング言語を使ってソフトウェアを開発するだけに留まりません。

 本章では、残念ながら誌面の都合もあるため、Drupalのカスタムテーマやカスタムモジュールの開発のみに焦点を当てていますが、Drupalコアの開発、さらに広くソフトウェアの開発環境および運用環境といったインフラ自体も、CI/CDによって改善を加えながら、自動的に構築することができます。

 また、バージョン管理システム上で扱うことができるものであれば、法律や契約書といった文書の作成、ハードウェア開発などにも、応用することが可能です。たとえば、本書の執筆も各著者がRe:VIEW1というソフトウェアによって各章の原稿を執筆し、各人が共通のGitリポジトリーに原稿データをpushし、CIツールでビルド可能かどうかのチェックを行い、最終的にマージしてビルドすることにより最終稿を作る、というプロセスで執筆しています。

 このように、CI/CDは非常に強力なアイデアです。ぜひ本章のCI環境構築手法を参考にして、ご自身が何らかの製品やサービスといったプロダクトを作るプロセスにCI/CDを組み込み、開発のスピードアップ、品質向上に少しでも役立ててもらえたら嬉しいです。

CI/CD 環境の選択肢

 ソフトウェア開発ではバージョン管理システムにより、日々書いたコードの差分を管理していくことは、一般的になりつつあります。また、バージョン管理システムだけでなく、開発・運用を自動化するためのDevOpsツールには多くの選択肢があります。

 その中でも特にGitLab2は、各DevOpsツールがカバーしている広範な機能3を兼ね備えている、非常に便利で強力なソフトウェアです。

 今回は、バージョン管理システムとしてGitLabを使用します。そして、GitLabに対するアクションと連携してジョブを実行するためにGitLab Runnerを併用することで、CIを実現する環境を構築していきます。

 GitLabに関連するDrupalの話題としては、DrupalCon North America 2021のKeynoteスピーチ4(Drupalの創始者であるDries BuytaertによるKeyNoteなので、通称DriesNoteと呼ばれています)において、今後Drupalのソースコード管理はGitLab上で本格的に行われていく流れになるとの発表がありました。

 また、DrupalCon Europe 2021のDriesnoteにおいても、より多く人がDrupalに貢献できるようにコミュニティーとしてGitLab上でソースコードを共有しながら開発を継続するイニシアチブを続けているとの発表5がありました。これを機会にGitLabおよび周辺ソフトウェアへの造詣を深めておくのはいいチャンスだと、筆者個人としても思っています。

 GitLabの使用環境としては

 1.GitLab.comで提供されているものを使用する(SaaS環境)

 2.オンプレミスまたはクラウドにインストールして使用する(Self-Managed環境)

というふたつの選択肢があります。

 また、GitLabには、無償あるいは有償のプランとして、以下の3つがあります(本章執筆時2021年11月末の価格)。

 1.Free($0)

 2.Premium(1ユーザーあたり $19/月額)

 3.Ultimate(1ユーザーあたり $99/月額)

利用環境、無償あるいは有償プランの組み合わせによって、使える機能には差異6があります。

 まずはGitLabを手軽に始めてみたいという場合には、「SaaS環境でFreeプランを使用する」という選択肢がおすすめです。また、Self-Managed環境あるいは有償プランでしか使用できない高度な機能を利用したい場合には、最終的に「Self-Managed環境でUltimateプランを使用する」ことも視野に入れて検討をしてみてください。

 なお、SaaS環境でFreeプランを使用して、CI/CDを行いたい場合、アカウントの存在検証を行うためにGitLab.comに対してクレジットカードあるいはデビットカードの登録が必要になります。GitLab.comをGitリポジトリーとして使用するだけであれば、各種カードの登録は必要ありませんが、有償プランを利用しない場合であってもCI/CDを行いたい場合にはカードの登録が必要ですので、その点は注意してください。

CI/CDの全体像

 まずは、Drupalのテーマあるいはモジュールの開発において、GitLabとGitLab Runnerを利用してCI/CDを回す仕組みの全体像を見てみましょう(図1.1)。最初は全体像をぼんやり眺めて、ポイントを掴むだけで十分です。

 CI/CD環境を構成しているGitLabおよびGitLab Runnerを、本書ではまとめて「CI/CDサーバー」と呼ぶことにします。

 CI/CDサーバーの一部であるGitLabでは、テーマやモジュールといったアプリ開発で書いたコードのバージョン管理を行います。GitLabが管理しているひとつひとつの丸は、コードのバージョン履歴を表しています。いろんな枝分かれ(ブランチ)がありますが、最終的にいいものをまとめていき、理想に近づくものへと仕上げていきます。ここでは、GitLab上で開発環境、テスト環境、本番環境それぞれに対応したブランチを作るという戦略、いわゆるGitLab Flow7になっていますが、そこは細かい話でプロジェクトの進め方にも依存する部分であるため、今は気にしなくて大丈夫です。

 最も重要なポイントは「開発したコード(=データ)の流れが、下から上に上がっている」ことです。つまり、ローカル開発環境で書いたコードはpushにより、バージョン管理システムであるGitLabにいったん上がり、Gitリポジトリーに対するコミットをトリガーとしてGitLab Runnerで何らかのテストが行われ、成果物であるアーティファクトを作ります。そして、開発環境、テスト環境、本番環境、と順にアーティファクトを反映する(=デプロイする)という流れになっていることです。

 非常に小さなシステムの場合、この図はすごく大掛かりで回り道に感じてしまうかもしれません。確かに自分一人で運用できるサイズのシステムであれば、すべての手順をすっ飛ばして、本番環境やテスト環境へ直接ログインして、ローカル開発環境のコードを反映させたり、本番環境のコードを直接修正する、といった方法が手っ取り早いと感じるのも頷けます。

 ですが、多人数が開発に関わっている大規模システムでそれを行うと、ほぼ確実に事故ります。なぜなら、本番環境、テスト環境、開発環境を直接触ってしまうと、それぞれの環境に差異が生まれ、よほど手順書や管理記録をしっかりつけていても、だんだんと全体の「今の状態」を把握できる人がいなくなります。何かシステムに手を加えようとした際に、どこを触ればいいのか誰もわからなくなります。こうして、「いったんできあがったら、できればもう誰も触りたくない」という、作った瞬間こそがベスト!というシステムができあがってしまいます。

 一人で開発するときにも同じことが起こります。人は努力しても、忘れる生き物です。過去にどれだけコメントやドキュメントを丁寧に書き残していても、「今の開発コード」そして「今の運用状態」を把握するのが難しいという問題は、長く開発をやっていると誰もが直面することです。

 先ほど、CI/CDの本質を書きましたが、それが全く逆のアプローチであることに気がつくかもしれません。そう、CI/CDは「常によりよいものを目指して手を加え続ける」ために、その周辺にある面倒くさいことは可能な限り自動化するアプローチです。どうでしょう?その可能性に少しワクワクしてきましたか!?

図1.1: GitLabとGitLab Runnerを利用したCI/CDの流れ
試し読みはここまでです。
この続きは、製品版でお楽しみください。