… 目標として、あらゆるコミットを1時間以内に本番環境にデプロイ可能にするといったものを追い求めることを、私はよくおすすめしています。(訳: OpsBR)

この単純な原則を適応するだけで、皆さんのデプロイプロセスは様々な観点で最適化することになって、特により質の高いソフトウェアのリリースといった、たくさんの利点を得られます。まずは手早く利点を見てみましょう。続くニュースレターではどのように実現するかについてお話していきます。

ソフトウェア開発のパフォーマンスを計測する

“Modern Software Engineering“ によれば、そして私達も完全に賛同しますが、ソフトウェア開発のパフォーマンスには2つの鍵となる計測項目があり、それぞれに2つの指標が紐づいています:

1. 安定性

   1. 変更による障害の発生率

   2. 障害からの回復時間

2. スループット

   1. リードタイム

   2. 頻度

これらは信じられない程に単純で、しかしソフトウェア開発のパフォーマンスという曖昧な計測を可視化するのには十分に手頃です。もしあなたの開発プロセスがこのたった2つの計測で高いスコアを記録しているだけで、そのパフォーマンスは高いということになります。

例えば、より安定性が高いということは、デプロイするソフトウェアの質がより高くて、つまりデプロイによって負の価値を提供しにくくなっていることを意味します。すると、デプロイについて無用に怖がる必要がなくなり、創造的な仕事に集中することができます。

また、より良いスループットはデプロイによってより多くの価値を提供していることを意味します。高速なパイプラインを使ってより多くの機能をリリースでき、それによってお客さんは低いスループットのプロセスよりもたくさんの価値を受け取ることができます。

ただ、両者は互いに繋がっており、直交するものでもトレードオフでもありません。より安定していれば、デプロイを速くもっと頻繁にやることにより自信が持てます。より良いスループットは安定性改善のデプロイをより高速にしてくれ、例えばすぐにロールバックできるようになります。

1時間でデプロイ可能にすることはすべての計測に影響

“1時間でデプロイ可能“の原則は”リードタイム”の指標とは直接的に繋がっていることは明白です。そして、上で述べた様に、これは”リードタイム”以外にも影響を及ぼします。1時間でデプロイ可能にするために、例えば、デプロイ後のシステム監視を良くする必要があり、そうすることで新しいコードに関連する障害を素早く検知して、自動的にロールバックを実行するなどして、より良い安定性と高い頻度のデプロイに自信を与えることができるようになります。

まとめ

ソフトウェア開発のパフォーマンスは2つの簡潔な計測で測ることができます: 安定性とスループットです。双方は互いに関連しており、高いパフォーマンスのチームは両方の計測で高いスコアを持っています。”1時間でデプロイ可能”の原則は、恐ろしく単純ですが、両方の計測に対して様々な面から良い効果をもたらしてくれます。

English version:

OpsBR Magazine

Ep 3: Continuous Delivery - Make any commit deployable within one hour

We recently read “Modern Software Engineering“ by David Farley and the most important key takeaway we got was this: … As a target, I generally recommend aiming to have something that you could deploy into production in less than one hour from the commit of any change…

Read more

3 years ago · 1 like · Ryosuke Iwanaga

OpsBR Magazine (日本語版)

Ep 1: 継続的デリバリー - デプロイ可能とはどういう意味か？

ようこそ、OpsBR Magazine へ！このニュースレターでは、ソフトウェアシステムや組織に関する様々なトピックを定期的にお届けします。 これは最初のニュースレターで、継続的デリバリーに関する最初のトピックをお話したいと思います。 継続的デリバリーは運用の中心 継続的デリバリー、通称CD は、新しいコードの変更を継続的に本番環境にデプロイ可能にする考え方とその実践です。CD プロセス、つまりCD パイプラインによって、新しい変更を本番環境へデプロイする際に自信をもって行うことができます。 デプロイに対して自信を持てば持つ程、そのデプロイが原因で失敗する可能性が理想的には低くなるので、より良い運用になります。CD パイプラインが無ければ、デプロイ後に何が起こるかが分からないということになります。…

Read more

3 years ago · 2 likes · Ryosuke Iwanaga

ただ、コード変更をデプロイ可能にする方法にはほかのやり方があります。Feature flags と呼ばれる優れたテクニックについてお話ししましょう。

アクティベーションなしに新しいコードをデプロイ

多くの人は、コードをデプロイすることと、新しい機能のリリースや振る舞いの変更を同じものと考えてしまいがちです。しかし、デプロイと有効化は同時に起こる必要はありません。以下の様なFeature flags を使うことで、新しいコードをアクティベーションなしにデプロイすることができます:

function main() {
  const featureFlags = fetchFeatureFlags();
  ...
  if (featureFlags.enableCoolFeature) {
    executeCoolFeature(); // The new code
  }
  ...
}

Feature flag はアプリケーションの実行環境で利用可能な小さい設定です。典型的には上のコードの様に動的に注入されるので、Feature flag の値を変更するのにコードをデプロイする必要がありません。上の様なflag は通常 false がデフォルト値になるので、Feature flag の値を変更するまでは新しいコードは実行されることがないので、このコードは生まれつきデプロイ可能です！

Feature flags はデプロイとリリースを隔離する

運用という観点で、Feature flag はたくさんの利点をもたらしてくれます。いつ新しい機能を有効化するかはデプロイせずに制御できるので、デプロイ自体はリグレッションに耐性があります。どのデプロイも新しい振る舞いを持ち込まないので、理想的にはデプロイ前のコードと同一です。

これは継続的デプロイ、通称(もう一つの)CD を簡単にして、ロールバックがめったに必要なくなります。これは、大規模なコードのアプリケーションにおいては、あなたのコード変更が他のチームの変更とともに、高い確率で問題なく本番環境にデプロイされることを意味します。Feature flags 無しだと、他のチームによって持ち込まれたバグによってあなたの変更が一緒にロールバックされたり、またはその反対が起こりえます。

対照的に、Feature flags は両チームがそれぞれの新しい機能を独立に有効化できるようにしてくれます。もしいずれかのチームが自分の新しい機能による問題に気づいた時には、簡単に自分たちの機能だけを排他的にロールバックすることができます。この隔離は特に大きい組織において非常に有効です。

新しい機能を徐々にリリースすることもできます。例えば、最初に1% のユーザだけ有効化してその挙動を計測することで、正しく動作しているかを検証できます。確認ができたら、100% になるまで毎日少しずつ割合を上げていくことができます。

しかし、Feature flags は銀の弾丸ではありません

CD という意味でFeature flags は完璧なものに見えますが、全ての変更をFeature flags の下でデプロイすることはできません。例えば、依存ライブラリのアップデートはFeature flags の下に隠すのは簡単ではありません。

Feature flags の他の欠点としては、複数のFeature flags の組み合わせがとんでもない数になってしまうことです。理論的には、どの組み合わせも実行時には異なる挙動をする可能性がありますが、全ての組み合わせを検証するのは大変困難です。そのため、既存のFeatuer flags の希少な組み合わせによって引き起こされる、テストでカバーできなかった不可解な挙動に遭遇する可能性があります。

そのため、どの機能をFeature flags の下に置くかは気をつけて選択する必要があり、さらにその利用状況を定期的に監視しておく必要があります。もし、あるFeature flag が長い間全てのユーザで有効化されているなら、そのFeature flag は消しても大丈夫ですし、合わせてもう使われていない古いコードも消すことができます。

最後に、たとえ新機能がFeature flag の下にあっても、インテグレーションテストなどで既知のリグレッションが起こらないことを検証する同じステップを実行する必要があります。例え呼び出さなくても、新しいライブラリを読み込むだけでアプリケーションの挙動が変わることはあります、例えば、関数呼び出しがなくても巨大なオブジェクトをメモリに読み込んでしまうかもしれません。

まとめ

Feature flags は新しいコードを即座にデプロイ可能にする強力なツールです。新しいコードは既存の挙動を変えることなくデプロイ可能で、その後Feature flag を切り替えることで有効化できます。これによって、複数チームの機能リリースを互いに隔離でき、不要なロールバックがめったに起こらなくなります。しかし、それは銀の弾丸ではなく、気をつけて使って、その利用状況を監視し、そしてインテグレーションテストの様な検証ステップは引き続き実行する必要があります。

English version

OpsBR Magazine

Ep2: Continuous Delivery - Feature flags, another way to make code changes deployable

In the previous episode, we described what deployable means in terms of Continuous Delivery: However, there is another way to make code changes deployable. Let’s talk about an elegant technique called Feature flags. Deploy a new code without activation…

Read more

3 years ago · 1 like · Ryosuke Iwanaga

これは最初のニュースレターで、継続的デリバリーに関する最初のトピックをお話したいと思います。

継続的デリバリーは運用の中心

継続的デリバリー、通称CD は、新しいコードの変更を継続的に本番環境にデプロイ可能にする考え方とその実践です。CD プロセス、つまりCD パイプラインによって、新しい変更を本番環境へデプロイする際に自信をもって行うことができます。

デプロイに対して自信を持てば持つ程、そのデプロイが原因で失敗する可能性が理想的には低くなるので、より良い運用になります。CD パイプラインが無ければ、デプロイ後に何が起こるかが分からないということになります。

デプロイ可能とはどういう意味？

ただ、デプロイ可能とはどういう意味でしょうか？新しいコードが自動的にDocker イメージになったら、それでデプロイ可能でしょうか？いいえ。成果物をデプロイ可能にするには、深く検証されている必要があります。

実際、この様なデプロイ用の成果物を準備するのは、継続的インテグレーション、通称CI のプロセスです。通常、コードマージで発火して成果物を作成し、併せてユニットテストも実行して新しいコードが期待した動作をしていることを確認します。

しかし、それだけで自動的に本番環境にデプロイ可能を意味することにはなりません。ユニットテストはインテグレーションせずにコードを検証することしかできません。ビジネスロジックの実装の検証には有益ですが、他のマイクロサービスといった管理外の依存とのやり取りは省略されてしまいがちです。

本番環境へのデプロイ前には、こうしたインテグレーションが検証され、そのやり取りによって発生する問題を把握する必要があります。そのためCD パイプラインは、例えばステージング等の本番環境前の環境への自動的なデプロイのプロセスを持ち、そこでインテグレーションテストを実行していると良いでしょう。すべてのインテグレーションテストを合格したら、その新しい成果物を本番環境へデプロイする自信を持つことができます。これが新しいコードがデプロイ可能であるという意味です。

まとめ

継続的デリバリー、通称CD は、新しいコードが本番環境へデプロイ可能であることを自動的に確認してくれるので、運用の中心になります。継続的インテグレーション、通称CI だけでは、通常ユニットテストしか実行しないので、新しいコードをデプロイ可能にするには不足しています。デプロイ可能にするためには、CD パイプラインは、CI プロセスが生成した新しい成果物を使ってインテグレーションテストを実行すると良いでしょう。

続くニュースレターでも、継続的デリバリーについてのお話を続ける予定です。以下のボタンからぜひこのニュースレターを購読してください:

Subscribe now

English version:

OpsBR Magazine

Ep 1: Continuous Delivery - What does deployable mean?

Welcome to OpsBR Magazine! We’ll publish short newsletters regularly to talk about various topics around operations on software systems and organizations. This is the first newsletter and we’d like to talk about the first topic about Continuous Delivery…

Read more

3 years ago · 3 likes · Ryosuke Iwanaga