ソフトウェアデリバリーガイド

継続的インテグレーションは、チームの各メンバーが少なくとも毎日、自分の変更を同僚の変更と一緒にコードベースにマージするソフトウェア開発手法です。これらの統合のそれぞれは、統合エラーをできるだけ早く検出するために、自動化されたビルド（テストを含む）によって検証されます。チームは、このアプローチがデリバリーの遅延のリスクを減らし、統合の労力を軽減し、新しい機能による迅速な機能強化のための健全なコードベースを促進する実践を可能にすることを発見します。

アジャイルソフトウェア開発は、要件分析、テスト、開発の間のサイロの一部を解消しました。デプロイ、運用、保守は、ソフトウェア開発プロセスの他の部分から同様の分離を被ってきた他の活動です。DevOps運動は、これらのサイロを取り除き、開発と運用の間のコラボレーションを促進することを目的としています。

継続的デリバリーは、ソフトウェアをいつでも本番環境にリリースできるようにソフトウェアを構築するソフトウェア開発規律です。

以下の場合は、継続的デリバリーを行っています

• ソフトウェアはライフサイクル全体を通してデプロイ可能です
• チームは、新しい機能に取り組むよりも、ソフトウェアをデプロイ可能な状態に保つことを優先します
• 誰かがシステムに変更を加えるたびに、誰もがシステムの製造準備について迅速な自動フィードバックを得ることができます
• ソフトウェアの任意のバージョンをオンデマンドで任意の環境にプッシュボタンでデプロイできます

継続的インテグレーションは、ソフトウェア開発で人気のある手法です。カンファレンスでは、多くの開発者がどのようにそれを使用しているかについて話し、継続的インテグレーションツールはほとんどの開発組織で一般的です。しかし、私たちは皆、適切な手法には認定プログラムが必要であることを知っています。幸いなことに、認定プログラムは存在します。継続的デリバリーとDevOpsの第一人者によって開発されたこのプログラムは、管理が非常に迅速でありながら、結果について非常に洞察力に富んでいることで知られています。かなり成熟していますが、知られているべきほど知られていないため、この手法のファンとして、この認定プログラムを読者と共有することが重要だと思います。継続的インテグレーションの認定を受ける準備はできていますか？そして、テストを受けることで明らかになる衝撃的な事実にどう対処しますか？

自動化されたビルドおよびテスト環境の課題の1つは、高速なフィードバックを得るためにビルドを高速化したいということですが、包括的なテストの実行には時間がかかるということです。デプロイメントパイプラインは、ビルドを段階的に分割することで、これに対処する方法です。各段階は、通常は追加の時間と引き換えに、ますます高い信頼性を提供します。初期段階では、ほとんどの問題をより迅速にフィードバックして見つけることができますが、後の段階では、より遅く、より徹底的な調査を提供します。デプロイメントパイプラインは、継続的デリバリーの中心的な部分です。

従来、QAはソフトウェアを本番環境にリリースする前に、そのリリース準備ができているかどうかを確認するためにテストすることに重点を置いています。しかし、ますます、現代のQA組織は、本番環境で実行されているソフトウェアにも注意を向けています。ログやその他の監視ツールを分析することで、彼らは開発組織に強調すべき品質問題を特定します。このアプローチは、継続的デリバリーを使用して新しいバージョンのソフトウェアを迅速かつ確実に本番環境に投入する組織で特にうまく機能します。

コードを迅速かつ安全に本番環境に投入するために必要な実践を概説する、継続的デリバリーに関する決定版の書籍。重要な側面は、リリースプロセスに関わるすべての人の間のコラボレーションと、そのプロセスの可能な限り多くの側面を自動化することです。この本では、構成管理、自動化されたテスト、継続的インテグレーションの基礎を説明しており、それに基づいて、統合されたテスト済みのコードをライブにするデプロイメントパイプラインを構築する方法を示しています。この本では、デリバリーエコシステム、インフラストラクチャ、環境、およびデータの管理について詳しく説明しています。

継続的デリバリーは、効果的なソフトウェアデリバリー組織にとって中心的な実践になりつつあります。この講演では、その仕組みの基本、デプロイメントパイプラインの役割、継続的デリバリーと継続的デプロイメントの違い、およびいくつかの重要な要素について説明します。また、継続的デリバリーの3つの主な利点である、デプロイメントリスクの軽減、信頼できる進捗状況、およびユーザーフィードバックについても説明します。

フィーチャートグル（フィーチャーフラグとも呼ばれることが多い）は、コードを変更することなくシステム動作を変更できる強力な手法です。それらはさまざまな使用カテゴリに分類され、トグルを実装および管理するときにはその分類を考慮することが重要です。トグルは複雑さを導入します。スマートトグル実装プラクティスとトグル構成を管理するための適切なツールを使用することで、その複雑さを抑制できますが、システム内のトグルの数を制限することを目指す必要もあります。

最新のソース管理システムは、ソースコードにブランチを簡単に作成できる強力なツールを提供します。しかし、最終的にはこれらのブランチを再びマージする必要があり、多くのチームがブランチの絡み合った茂みに対応するために過度の時間を費やしています。複数の開発者の作業を統合し、本番リリースへのパスを整理することを中心に、チームがブランチを効果的に使用できるようにするいくつかのパターンがあります。包括的なテーマは、ブランチを頻繁に統合する必要があり、最小限の労力で本番環境にデプロイできる健全なメインラインに焦点を当てる必要があるということです。

同僚と私がクライアントに強く推奨する目標の1つは、完全に自動化されたデプロイメントプロセスです。デプロイメントを自動化すると、ソフトウェアが「完了」してから価値を実現するまでの間に発生する摩擦と遅延を減らすのに役立ちます。Dave FarleyとJez Humbleは、このトピックに関する本である継続的デリバリーを完成させようとしています。これは、継続的インテグレーションに関連付けられている多くのアイデアに基づいており、ソフトウェアを迅速に本番環境に投入して何かを実行するこの能力をより推進しています。ブルーグリーンデプロイメントに関する彼らのセクションは、あまり使用されていない手法の1つとして私の目に留まったので、ここで簡単に概要を説明しようと思いました。

「抽象化によるブランチ」は、変更が進行中でもシステムを定期的にリリースできるように、ソフトウェアシステムに大規模な変更を段階的に行うための手法です。

Ship / Show / Ask は、プルリクエストの機能と変更を継続的に出荷する機能を組み合わせたブランチ戦略です。変更は、Ship（レビューなしでメインラインにマージ）、Show（レビューのためにプルリクエストを開きますが、メインラインにすぐにマージ）、またはAsk（マージする前に議論のためにプルリクエストを開きます）として分類されます。

合成監視（セマンティック監視とも呼ばれます）は、アプリケーションの自動テストのサブセットを、定期的に本番稼働中のシステムに対して実行します。その結果は監視サービスにプッシュされ、障害が発生した場合にアラートがトリガーされます。この手法は、自動テストと監視を組み合わせて、本番環境でのビジネス要件の失敗を検出します。

ソフトウェアシステムにおける可観測性は常に価値があり、クラウドとマイクロサービスの時代においてはさらに重要になっています。しかし、システムに追加する可観測性は、技術的に低レベルな性質になりがちで、多くの場合、さまざまなロギング、計装、分析フレームワークへの、古くて冗長な呼び出しでコードベースを散らかす必要があるように思われます。この記事では、この混乱を解消し、ビジネスに関連する可観測性をクリーンでテスト可能な方法で追加できるパターンについて説明します。

カナリアリリースとは、新しいソフトウェアバージョンを本番環境に導入するリスクを軽減するための手法であり、変更をインフラストラクチャ全体に展開してすべての人に利用可能にする前に、少数のユーザーに対して徐々に展開します。

私のお気に入りのサウンドバイトの1つは、苦痛を感じるなら、もっと頻繁にやれです。表面上はナンセンスに見えるという嬉しい特性を持っていますが、深く掘り下げるといくつかの貴重な意味が得られます。

機能のダークローンチとは、ユーザーが呼び出されていることを知ることができない状態で、新しいまたは変更されたバックエンドの動作を既存のユーザーから呼び出すことです。これは、新しい機能の公開発表を行う前に、システムへの追加の負荷とパフォーマンスの影響を評価するために行われます。

ソフトウェア開発チームは、可能な限り頻繁に作業を統合すれば、作業がはるかに簡単になることに気づきます。また、頻繁に本番環境にリリースすることも有益であると考えています。しかし、チームは開発途中の機能をユーザーに公開したくありません。この緊張に対処するための有効な手法は、すべてのバックエンドコードを構築して統合しますが、ユーザーインターフェイスは構築しないことです。機能は統合してテストできますが、UIは、キーストーンのように、機能の完成のために最後に追加されるまで保留され、ユーザーに公開されます。

他の専門職と同様に、ソフトウェア開発には、通常は無視されるが、間違った瞬間に反撃する癖がある、忘れられがちなアクティビティがあります。その1つがデータ移行です。

継続的インテグレーションのファンが抱く一般的な前提の1つは、ビルドが再現可能である必要があるということです。これは、作業中のシステムの古いバージョンを取得し、当時とまったく同じ方法でソースからビルドできる必要があることを意味します。

最新のアプリケーションサーバーでよく宣伝される機能の1つは、クラスターでのフェイルオーバーを提供することです。クラスター化はアプリケーションの信頼性を向上させます。サーバーの1つがダウンした場合、顧客にサービスを提供するサーバーがいくつか残っています。フェイルオーバーは、インタラクション中にサーバーがダウンした場合、クラスターがそのインタラクションを別のサーバーに移動できるため、さらに信頼性を高めることができます。

ただし、これは問題になる可能性があります。

インフラストラクチャコードとは、ソフトウェアシステムと同様に扱うことができるソースコードを通じて、コンピューティングおよびネットワークインフラストラクチャを定義するアプローチです。このようなコードは、監査可能性と再現可能なビルドを可能にするためにソース管理に保持でき、テストプラクティスと継続的デリバリーの完全な規律に従います。これは、過去10年間に成長するクラウドコンピューティングプラットフォームに対処するために使用されてきたアプローチであり、今後、コンピューティングインフラストラクチャを処理する主要な方法になるでしょう。

自動構成ツール（CFEngine、Puppet、またはChefなど）を使用すると、サーバー要素の構成を記述するレシピを提供することで、スノーフレークサーバーを回避できます。構成同期は、定期的なスケジュールまたは変更があった場合に、これらの仕様をサーバーインスタンスのライフサイクル全体に継続的に適用します。ツール外でサーバーに変更を加えた場合、次回サーバーが同期されるときに、中央で指定された構成に戻されます。構成の変更が必要な場合は、構成仕様（レシピ、マニフェスト、または特定の構成ツールが呼び出すもの）で行われ、インフラストラクチャ全体で関連するすべてのサーバーに適用されます。

自動構成ツール（CFEngine、Puppet、またはChefなど）を使用すると、サーバーの構成方法を指定し、新規および既存のマシンを準拠させることができます。これにより、脆弱なスノーフレークサーバーの問題を回避できます。このようなツールは、自由に破棄および再構築できるフェニックスサーバーを作成できます。イミュータブルサーバーは、このアプローチの論理的な結論であり、一度デプロイされると変更されることなく、新しい更新されたインスタンスに置き換えられるだけのサーバーです。

ここ数年、「クラウド」は非常に誇張された用語になっています。誇張された言葉の特徴の1つは、それらにほとんどまたはまったく定義がないことです（はい、NosqlDefinition、私はあなたを見ています）。

結局のところ、NISTからのクラウドコンピューティングの優れた定義があります。これは、素晴らしく短くて理解しやすい標準ドキュメントで入手できます（いいえ、私は冗談を言っていません）。

本番サーバーを稼働させ続けるのは、面倒な作業になる可能性があります。オペレーティングシステムやその他の依存ソフトウェアが適切にパッチ適用され、最新の状態に保たれていることを確認する必要があります。ホストされたアプリケーションは定期的にアップグレードする必要があります。環境を効率的に実行し、他のシステムと適切に通信できるようにするために、構成変更が定期的に必要です。これには、コマンドライン呼び出し、GUI画面間のジャンプ、およびテキストファイルの編集の組み合わせが必要です。

その結果、ユニークなスノーフレークになります - スキーリゾートには良いですが、データセンターには悪いのです。

ある日、私は運用向けの認証サービスを開始するという幻想を抱きました。認証評価は、同僚と私が企業のデータセンターに現れ、野球のバット、チェーンソー、水鉄砲で重要な本番サーバーを攻撃することから構成されます。評価は、運用チームがすべてのアプリケーションを再び稼働させるのにかかる時間に基づいて行われます。