最近読んだ「入門 継続的デリバリー」がとても良かったので紹介しますね, というエントリーです.
「継続的デリバリー（Continuous Delivery）」とか「DevOps」ってどこから学ぶかわからんな！？
というのは割とあるあるだと思っています, そもそもめちゃくちゃ難しい話なので（ちゃんと学ぼうとすると）.
そんな中, 「入門 継続的デリバリー」がよく説明できてて良かったので感想と関連する書籍を紹介できればと思っています.
TL;DR
「入門 継続的デリバリー」は継続的デリバリーの大切さと概念, 手法を現実にありそうなシステムの事例からいい感じに学べる良著でした.
実例を交えて漫画が多いのは良いかなと, 結構おすすめです.
入門 継続的デリバリー
自分の感想を語る前に, オライリーのHPでの紹介文をご紹介します.
継続的デリバリーとは、コード変更を必要に応じて迅速かつ安全に、継続的にリリースできるようにするための開発手法です。本書は、初めて継続的デリバリーに取り組む読者向けに、必要な知識とベストプラクティスをていねいに紹介する入門書です。基本的な概念や技術、アプローチの解説はもとより、章ごとに事例を使用しながら、継続的デリバリーを実践する際に直面するさまざまなシナリオを取り上げ、その全体像・世界観を包括的に理解することができます。 ※オライリー社の書籍紹介ページからの引用
「本書は、初めて継続的デリバリーに取り組む読者向けに、必要な知識とベストプラクティスをていねいに紹介する入門書です。」の部分は本当にその通りで, 実際読みやすかったです.
我々はなぜCDをするのか?
（あえて乱暴な言い回しをしますが）「なぜ継続的デリバリーをしているか?」「GitHub ActionsやGitLab CI/CD使ってアプリケーションをデプロイする理由は?」っていう質問を投げかけたとして, 大抵の場合の答えは
- 全部手動でやると大変だからとにかく自動化したいから.
- イケてる企業・イケてるシステムがみんなやってるから.
- 開発者体験が良い企業*1がみんなやってるから.
- 自社サービス・ユーザー企業のエンジニアだとそういうイケてる事をしているから.
- ただなんとなく聞いたことあるから.
...などなど, そんな回答に収束するのが一般的なのかなと思っています, 少なくとも自分の体験・体感上は.
「とにかく自動化したい」「ただなんとなく」あたりはまだいい回答*2なのですが, 他の3つの回答は個人的には正直微妙だなと思っています.
個人的にはこの「なぜ継続的デリバリーをしているか?」「GitHub ActionsやGitLab CI/CD使ってアプリケーションをデプロイする理由は?」の回答は,
- チームが安心安全にアプリケーションおよび一部のインフラをデプロイできる状態を作るため.
- インシデント（不具合）やその他の理由で過去バージョンに切り戻す時に安心安全かつ容易にできること.
- 開発者（Dev）と運用者（Ops）のコミュニケーションが円滑もしくは役割の分担がない状態*3を作り, デプロイ回数を増やし, ソフトウェア・システムの付加価値を高めること*4.
とかなんとか答えるのですが, この「入門 継続的デリバリー」では以下の様に恐ろしくシンプルな回答をしています.
まず読者の方が気になるのは、継続的デリバリーについて学ぶことに時間をかける価値があるのか、また、仮にあるとしても、それを自分のプロジェクトに適用する手間をかける価値があるのか、ということでしょう。次のことがあなたにとって当てはまるのであれば、答えは即答でイエスです。
- ソフトウェアの制作を専門的に行っている。
- 複数の人がプロジェクトに参加している。
※「入門 継続的デリバリー」第1章「1.1継続的デリバリーは必要?」の序文より引用
「ソフトウェアの制作を専門的に行っている, 複数の人が参加するプロジェクト」ってほぼ全てのプロジェクトが当てはまるのでは🤔
正論だと思います, コンテナにクラウド, AIなどなど色んなモダンなアーキテクチャで出来ている昨今のソフトウェアでCDが無いと辛い！...というのをシンプルに表していて良いなと思いました.
そして「継続的デリバリーとは?」という問に対して,
継続的デリバリーとは、プロフェッショナルな品質のソフトウェアを書く複数のソフトウェアエンジニアが、思い通りのソフトウェアを作成できるようにするために必要なプロセスの集合体です。
※「入門 継続的デリバリー」第1章「1.1継続的デリバリーは必要?」のまとめより引用
模範解答の中の模範解答ですばら！ってなりました, この言語化だけでも読んだ価値ありました.
具体的なプラクティス
書籍自体が「必要な知識とベストプラクティスをていねいに紹介する入門書です。」と言ってることもあり,
- まずはソフトウェアをいつでもデリバリーできる状態にしましょう.
- バージョン管理
- リント（静的テスト）
- テストコードへの対処（ノイズの除去, テストスイートの速度改善）
- デリバリーを簡略化しましょう.
- バージョン管理（大切なので二度言う）
- ビルドの安定化（安全かつ信頼性あるビルドを回す）
- 自信をもってデプロイできる状態を作る
- CDのいい感じなデザイン
- 仕組みの選択
- スクリプトの管理
- etc...
以上の必要な要素を順番に説明してくれるのがいい感じでした, 全部を解説するとアレなので気になる方はぜひ読んでみてほしいです, 各章で本当に良いこと書いています.
また, 書籍全体を通して架空のWebサイト「Cat Picture Website」なる, 猫の写真を中心としたSNSの開発チームのエピソードを元に漫画化して紹介されてるのも良い感じです, 実にわかりやすいというか*5.
また,
- Argo Workflows
- CircleCI
- GitHub Actions
- Google Cloud Build
- Jenkins Pipline
- Tekton
といった具体的なソリューションについも付録でCDシステムとして紹介されています.
とりあえず順番に読めば理解は進みそうですし, これなら入門としてオススメできると思いました.
入門後に読むべき良著
以上が「入門 継続的デリバリー」の感想ですが, 個人的なオススメとして「実務やるならこの辺りも読むと良いかも」という書籍も紹介します.
Kubernetes CI/CDパイプラインの実装
Kubernetes上のシステムのCI/CDパイプラインをどうすれば?に対して実践的かつ実装可能なノウハウが詰まってる本です.
TektonやArgo, GitLabを使ってGKE（Google Kubernetes Engine）上に色々とCI/CDを仕込もう！という内容で, 「k8s使う事になったけどどうしよう」という時に役立ちそうです.
なお, 出版が2021年とちょっと古いのでいくつか読み替えたりする必要はありそうです（技術書の宿命として）.
継続的デリバリー
そもそも何故継続的デリバリーが必要か?やらないとどうなるか??を詳しく解説してくれる本です.
2017年発刊とあるのでだいぶ前の本ではありますが, 大切なことがしっかり乗っています.
「入門 継続的デリバリー」では「継続的デリバリーとは、プロフェッショナルな品質のソフトウェアを書く複数のソフトウェアエンジニアが、思い通りのソフトウェアを作成できるようにするために必要なプロセスの集合体です。」と言ってる部分をもっと専門的に説いた本, という内容になります（私の解釈では）.
チームトポロジー
チーム・組織側面における, 「いい感じにデリバリーを行うためには何が問題で何から手を付ければよいのか?」を紹介した書籍です.
こちらはこのブログでもちょこっと紹介しています.
「チームトポロジー」はコンウェイの法則を元にデリバリーの高速化・最適化という観点でまとめた正にボード・マネジメントの為の書籍です, これは面白くてあっという間に読み終えました.
コンウェイの法則の本っぽさはありますが, 実際読みやすいのと個人的にはマネジメント業をするときの参考になったりしています*6.
結び - 我思うCDとDevOps
「入門 継続的デリバリー」の紹介を通じてCDおよび, 関連書籍を紹介させてもらいました.
具体的な事は大人の事情で言えませんが, 自分が仕事やデリバリーをする際に大いに役立ってます.
気になる方は読むと良いのかなと思います.
また, このエントリーの冒頭に上げた問である,
- なぜ継続的デリバリーをしているか?
- GitHub ActionsやGitLab CI/CD使ってアプリケーションをデプロイする理由は?
エンジニアおよびエンジニアを束ねるチームのリードの人（マネージャーなど）はぜひ一度考えると良いのかなと思いました.
これ, 結構大切な問だと思うんですよね...ソフトウェアやサービスをどの様に考えているか?がわかるような話なので*7.
私が持ってる回答を再掲しますが,
我思うCDおよびDevOpsの価値はこれで, これをどうやって実装していくか？！...という話はまた別の機会にできると幸いです.
一人チームでここまでしてやってる理由も含めて.
最後までお読みいただきありがとうございました.
*1:いわゆる「いい感じのアーキテクチャと技術スタック, 開発者が好きにやれる開発環境」の事. これはこれで否定はしないのですが, ある程度のレベルのエンジニアであれば「開発者体験が良い会社・チーム」に行く以上に「開発者体験を生み出すための環境づくりとチーム作り」の方がよりエキサイトするしやりがいある仕事な気がします（個人の見解です）.
*2:自動化の件はそれなりの苦労を味わってるから, と言えるのと, ただなんとなく, は正直で逆に良いかなと.
*3:現実問題, 明にも暗にも役割分担されることが多いのでこれは理想論かもしれない説あります, 役割分担されていても多くの回数の意味あるデプロイが出来ていれば良いとは思いますが.
*4:より私らしい, 面倒くさい言い回しをすると 「意味あるfeatureを沢山デプロイして市場で検証し, 試行回数およびエンゲージメントの獲得を最大化すること」とかそんな感じです.
*5:CDやDevOpsみたいに難しい概念は漫画でストーリーにそって説明できると確かに良いなと思ったのと, スクラムの名著「SCRUM BOOT CAMP THE BOOK」以来に読みやすい漫画だと思いました.
*6:チームのパフォーマンスやデリバリーに何かしらの課題があるとき, 「作業を自動化しよう」とかいうシステムと手段のボトルネックではなく, 「チームの構成が悪いのか」「コミュニケーションに改善余地があるか」といった, チームや人にフォーカスしたWhy/Whatから解決する時に参考にしています.
*7:ソフトウェアやサービスの事を考えている（考えていない）がわかるだけでなく, エンジニアやチームの扱い, 何を大切にしているのか丸裸に出来そうな問ですよねって意味で
*8:コミュニケーション的もしくは組織として分断されてない状態, とも言える.
*9:がんがんデプロイして失敗して学ぼうぜ！, を大人に言い回すとこうなる.
