1.1　CI/CDって？

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

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

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

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

　４．道具と具材、配送手段を用意する

　５．カレーを作る手順を進める

　６．できたものを味見する

　７．うまくいかないところを直す

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

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

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

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

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

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

　４．開発環境と運用環境を構築する

　５．コーディングをする

　６．作ったものをテストする

　７．うまくいかないところを直す

　８．完成したテーマやモジュールを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:VIEW¹というソフトウェアによって各章の原稿を執筆し、各人が共通のGitリポジトリーに原稿データをpushし、CIツールでビルド可能かどうかのチェックを行い、最終的にマージしてビルドすることにより最終稿を作る、というプロセスで執筆しています。

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

CI/CD 環境の選択肢

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

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

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

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

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

　GitLabの使用環境としては

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

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

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

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

　１．Free($0)

　２．Premium(1ユーザーあたり $19/月額)

　３．Ultimate(1ユーザーあたり $99/月額)

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

　まずは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 Flow⁷になっていますが、そこは細かい話でプロジェクトの進め方にも依存する部分であるため、今は気にしなくて大丈夫です。

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

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

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

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

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