ブログ

ryuzeeによるブログ記事。不定期更新
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料)

継続的デリバリーの8つの原則

みなさんこんにちは。@ryuzeeです。

継続的デリバリーに関する分かりやすい記事があったので抜粋・意訳にてご紹介します。

継続的デリバリーの8つの原則

1. ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。

このことは2つめの原則にたどり着く。

2. 全てを自動化する!

手動のデプロイは決して繰り返し可能で信頼性が高いことには成り得ない。 あなたは繰り返し行う全てのタスクを自動化することについて本気で投資する必要がある。そしてこうすることによって信頼性に繋がっていくのだ。

3. なにか難しかったり苦痛なことがあったら、それを何度もやってみる

表面的には、ばかげた話のように聞こえるかもしれない。しかし基本的にこれが意味していることは、苦痛であることを頻繁に行うことは、あなたがそれを改善し、多分自動化する方向に導いてくれるはずだ。そして最終的には苦痛がなくなり容易に行うことができるようになるだろう。 データベースのスキーマをデプロイすることを例にとってみてみよう。もしこれがトリッキーだったら、頻繁に実施しようとは思わずに先延ばしにして月に1回くらいにするだろう。本当にあなたがすべきことは、スキーマをデプロイするプロセスを改善して、それを行うことを得意にし、より頻繁ー例えば必要なら1日1回に行えるようにすることだ。 毎日同じことをやっているなら、月に1回しかやらない時よりも、より良いやり方にできるはずだ。

4. 全てをソースコード管理システムで管理する

このことは現代では当たり前に聞こえるかもしれない。ソースコード管理システムに全てを登録していないのは重大な問題だ。明らかにそんな人はいないだろう。そんな奴を知ってるかい?

5. 完了は「リリースされたこと」を意味する

このことは、ソフトウェアがユーザーの手に渡り正しく動作して初めてでき上がりだということだ。 「僕が知る限り僕のコードは動いたから完了だぜ」ってことはないのだ。 私は、チームが変更を行ったコードが本番環境に反映されて正しく動作することを確認しすることを望み、本番システムでの変更が正しく動作するかをモニタリングしていたチームと一緒に働くという大変な幸運に恵まれていた。 一方で、自分たちの責任はVCS上でコードをチェックすればおしまいだ、という考えのチームと働いたこともあった。

6. 品質をつくり込む

品質メトリクスへ投資する時間を確保しよう。 よい目標のはっきりした品質メトリクス(ユニットテストのカバレージ、コーディングスタイル、規約違反、複雑度とかとか)をもつプロジェクトはだいたいにおいて、それらがないプロジェクトよりもマシなプロジェクトだし、長期間の稼働における保守も容易だろう。

7. すべての人にリリースプロセスに対しての責任がある

企業にとって開発者のノートPC上だけで動作するソフトウェアはなんのお金も産まない。 似たように、開発に関する計画のないプロジェクトは決してリリースすることはできないし、お金を産むこともない。 企業はプロダクトを顧客にリリースすることによってお金を産み、それゆえ、このリリースプロセスは社内の万人の関心事になるべきである。 開発者は、作ったものがどのようにデプロイされるかについて意識して開発に取り組まなければならない。 プロジェクトマネージャはデプロイメントに注意を払ってプロジェクトの計画をたてなければならない。 テスターはコードの問題に対しての注意と同じくらいデプロイメントに関する問題についてテストすべきである。(そしてデプロイメントは自動化され、開発タスクの1つとしてプロジェクトに組み込まれるべきである。)

8. 継続的に改善する

時代遅れとかメンテナンスができなくなるまで自分たちのシステムを放置してはいけない。 継続的な改善が意図するところは、あなたが関わっているシステムは常に進化し、そのためには必要ならいつでも簡単に変更できるようになってなければならないということだ。

これらの原則と関連して。。。

継続的デリバリーに関する4つのプラクティス

1. バイナリは一度だけビルドする

私が様々な環境で何度も再コンパイルする様をみた回数にあなたは愕然とするだろう。バイナリは1バージョンにつき1度だけコンパイルされるべきである。バイナリはどこかあなたのデプロイメカニズムがアクセス可能な場所に配置されるべきで、デプロイシステムはこのバイナリを複数のそれぞれの環境にデプロイするべきなのだ。

2. すべての環境にデプロイするのに完全に同一のメカニズムを使う

こんなの明らかに聞こえるだろうが、QAへのデプロイは自動化されていたのに、本番へのデプロイは手動だったというケースを本当に見たことがあるんだ。 他にも、QA環境も本番環境へもデプロイは自動化されていたが、それら2つが完全に違う言語で作られていたってこともあった。狂気の沙汰としか言いようがない。

3. デプロイメントでスモークテストを実施する

あなたのデプロイが大成功になるチャンスを放置してはいけない。スモークテストを書いてデプロイプロセスの中に含めよう。 それから、いくつかの単純な診断テストを含めることも望ましい。あるべき姿をテストするような感じで、例えば本番環境のサーバにおける想定しているファイルの一覧と実際のファイルの一覧を比較したりといったものだ。私はそれを診断テストと呼んでいるのは、問題が起こっている場合に真っ先に教えてくれるものだからだ。

4. 何か問題が起こったらラインを止める

途中で失敗したらやめにして、プロセスを再度最初からやりなおすこと。パッチをあてたりハックしたりしてはいけない。 問題が起こった場合、それがどの部位だろうと、デプロイを破棄(例えばロールバック)し、問題を適切に修正し、修正内容をソース管理システムに登録してからデプロイプロセスを再度開始すること。 多くの人は、稼働しているシステムへのデプロイにおいてちょっとした停止画面が出るような場合や、問題が起こったときに修正することができる人がいないような真夜中の本番環境の変更のような場合には特に、そんなの不可能だ、とコメントするだろう。 それに対しては、私は、論点が違うと言いたい。 1つは、たった1つの停止画面が出たような場合に、本番システムをハッキングすることはもっともやってはいけないことだ。なぜならあなたが他の環境も同じようにハックしないかぎり同じ問題が他でも起こるということだからだ。 2つめに、次回デプロイをする際に、同じ問題が再度起こるであろうからだ。 3つめに、真夜中に問題を修正してくれる人が誰もいない状況下でデプロイするということは、継続的デリバリーの7つめの原則 ー全員がリリースプロセスに対して責任を持っているーに対して十分な注意を払っていないということだ。周りのサポートが受けられない状況下においてはリリースすることは推奨できない。それは常識に反している。

  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック