継続的デリバリーがなければアジャイルと呼べない理由

各スプリントの終了ごとのリリースが実現可能です。その方法を紹介します。

Ian Buchanan Ian Buchanan

アジャイルなプラクティスは、レシピとセンサーの 2 つの方法で表示できます。ソフトウェア経験が豊富な人々は、最も生産的になるようなプラクティスを書き留めてきました。さらに、それらのプラクティスは、発生する問題を増幅させることで非生産的になっている方法を明らかにしています。

継続的なデリバリーは、アジャイル レシピの一部であり非効率性を暴く優れモノでもあります。さらに、アジャイルのメリットを活かすために、ソフトウェア開発ライフサイクルのすべての段階でアジャイルである必要があります。関係者や顧客がそれらを見る前に、ユーザー ストーリーとバグ修正がリポジトリ内で何週間も延々と放置されると、反復計画と開発はその価値を発揮しなくなります。

あなたは頻繁に、そして劇的な出来事がなくリリースできる程度にはアジャイルです。

アジャイルの本質は「検査と調整」です。さて、チームの俊敏性を妨げているのかそれを助けているのか評価するために、ビルドしてデプロイするシステムを詳細に検査する必要はないでしょう。そして、あなたがこの記事を読んでいるということは、すでにシステムが「妨げている」というカテゴリに入っている良い兆候です。調整するなら今です。

絶え間ないフラストレーションを抱えた生活

私が「継続的なフラストレーション」と呼ぶソフトウェアの一般的な状態があります。これは、いかなる継続的なインテグレーションや継続的なデリバリー プラクティスが欠如している状態です。こんな感じです...

  • main にコミットして、誰かに責められるかもしれないと心配しながら待っている。
  • メイン コード行が不安定である。
  • バグは非常に多くのコード変更のもつれの中に隠れており、そのコードの領域における作業が済んでからかなり長い時間が経過しているため、バグを見つける (その修正はもちろん) ための努力を前に呆然としている。
  • テスト担当者は機能をテストする際に、現在のステータスを把握して作業ビルドを見つけるために、すべての開発者を悩ませる必要がある。
  • リリースにはコード フリーズが必要である。リリースを安定させられるように、誰かをコード変更への人工的なボトルネックにします。一方、実際には誰も作業を停止しません。コード変更のコミットをやめるだけです。つまり、実証されていないコードの大洪水は、フリーズが解除されるとすぐに大量の未処理の下水のようにリポジトリから溢れ出ます。

エラー | Atlassian CI/CD

その物語が記憶に残るほど馴染み深いなら、希望があることを知ってください。

「検査と調整」で計画プロセスがどのように改善されたかを検討して、それを開発プロセスとデリバリー プロセスに援用します。あなたが行ったすべてのコミットで問題を検出できるとしましょう。コミットする前であっても、ローカル ワークステーションで問題を検出できるとします。あなたが想像した内容は、開発者には迅速なフィードバックが必要だという、アジャイルが継続的なデリバリーを必要とする理由の核心を突いています。

継続的なデリバリーへのジャーニーに出ることの素晴らしい点は、それがあなたから始まることです。誰かに売ったり、むしろ Etsy (ハンドメイド アイテム販売サイト) に近いはずとチームを納得させたりする必要もありません。また、継続的なデリバリーの基本原則、プラクティス、ツールが適用されないほど独自にテクノロジーを使用している人は皆無です。人生をより良くするために、今すぐできる簡単なことがあります。

スクリプトとサーバーから始める

過去には Make の一手しかなく、多くの開発者は空白のバグに手をこまねきました。その後、Ant は代わりに山括弧の空白を代用しました。これで、これらの旧世代をスキップできます。確かに、まだ Maven や Ant さえ使っているオープンソース プロジェクトがたくさんあります。きっと単に昔から使っているからでしょう。しかし、フォールバック オプションとして XML ベースのビルド言語を利用できます。

最新世代のビルド言語は、群を抜いて分かりやすく使いやすいです。ほとんどの場合、アプリケーションのビルドに使用しているのと同じ言語で書かれたビルド言語を使用できて、あなた (とそのチーム) ですべてがやりやすくなります。

コード言語と対応する推奨ツールのチャート | Atlassian CI/CD

継続的なデリバリーの「継続的」という部分は、コミットごとにフィードバックを得ることを意味します。ビルド サーバーは自動でリポジトリをリッスンして何かが変更されたときにビルドをトリガーするのは、そのためです。継続的であることは、ビルドが壊れたときに修正することも意味します。開発者として、変更の隔離のメリットを受けます。バグ修正が複雑で扱いにくくならないようにする最善の方法は、何よりもバグ修正が積み重ならないようにすることです。Bamboo のようなビルド サーバーは、簡単にインストールできます。最初は、単にクリーンな環境でビルド スクリプトを実行することが目的です。ある意味では、ビルド サーバーが最初に行うことは、ビルド スクリプトで問題を検出する際に役に立つことです。

問題を自動で検出し始める

ご想像のとおり、ビルド サーバーはビルド スクリプトよりも遥かに多くの問題を検出できます。(言語によっては) コンパイラの警告をオンにするような簡単なことや、自動テストのようなあらゆるアジャイル コーチが挑戦する難しいことがあります。これは、手動のみのテストが継続的なデリバリーのボトルネックであるためです。自動テストを始めたばかりの場合は、最も迅速なフィードバックを提供する階層 (ユニット、統合、承認、UI) を見つけます。

議論に決着を付けましょう、自動テストは手動テスト担当者にとって脅威ではありません。

実際、テスト担当者は、自動化すべきもの (またすべきでないもの) を決める際に素晴らしいガイドを作ります。スマート自動化戦略は、「最も検出する価値のある問題の種類は何ですか?」という疑問に左右されます。それに答えるには、ソフトウェア品質を専門とする経験豊富な人材が必要です。

継続的なデリバリーの種

誰でも始められます。しかし、あなたなら、誰しもがそれを継続的なデリバリーとして認識しません。次のステップは、これらのビルディング ブロックをチームにもたらすことです。

継続的なインテグレーションとアジャイル テストに関する書籍や記事からインスピレーションを得ましょう。後で、デプロイの準備をすることが役立つ理由がもっとわかります。その後、継続的なデリバリーと継続的なデプロイからインスピレーションを得られます。

全員の出発点は非常にありふれたものですが、最終的にはあなたの製品やビジネス特有のものになります。