ウォーターフォールとアジャイルの違いを説明するのに役立つリリース管理の側面はどれですか?


12

DevOpsを誰かに説明すると、次のような質問が出てきます。

アジャイル手法を使用したリリース管理は、ウォーターフォールとどのように異なりますか?

そのような聴衆にこれらの違いを説明するためにどのような基準を使用できますか?

回答:


11

IMO DevOpsは文化であり、アジャイルによく似ています(アジャイル手法を選択しません)。したがって、DevOpsを「実行」しないでください。

DevOpsカルチャーの一部として、継続的デリバリーと呼ばれるリリース方法を「実行」します。(完全な開示、以前CDをリリース方法論と呼んだことはないと思いますが、時差ぼけの状態では機能すると思います)

それを買うなら、同じタイトルで本を書いた人の一人、Jez HumbleからのContinuous Deliveryの定義がここにあります。

継続的デリバリーは、すべてのタイプの変更(新機能、構成変更、バグ修正、実験など)を、本番環境またはユーザーの手に、安全かつ迅速に持続可能な方法で取得する機能です。

私たちの目標は、大規模な分散システム、複雑な本番環境、組み込みシステム、アプリなど、オンデマンドで実行できる予測可能な日常業務を展開することです。

私たちは、毎日何千人もの開発者のチームが変更を加えている場合でも、コードが常に展開可能な状態であることを保証することにより、これらすべてを実現しています。したがって、従来は「開発完了」に続いていた統合、テスト、強化の各フェーズ、およびコードのフリーズを完全に排除します。

そのため、アジャイル手法で作業し、ビジネスにデモできるソフトウェアを用意し、適切な自動テストを行っていることを確認し、変更やウォーターフォールよりも優れているすべてのことに適切に対応します。多くの場合、実際に運用環境に展開できるというわけではありません

次のような結果になります。 cdなしでアジャイル

したがって、ソフトウェアは(おそらく)完了したら、何らかの反復的なアプローチがなかった場合に改善されますが、実際のユーザーはそれを見たことがないので、あなたは本当に知りません。

本当に欲しいのは、次のようなものです。

ここに画像の説明を入力してください

すべての反復で、何かが実稼働にデプロイされます。そのため、ソフトウェアが展開されます。ダウンロードを作成することを決定した場合、Webサーバーを開くか、ソフトウェアをリリースしたユーザーの手に渡します。

なんてこった!?DevOpsについて尋ねました!誰も連続配達について尋ねませんでした!!

それでは、DevOpsはこれと何の関係があるのでしょうか?

そのチームがDevOpsカルチャで働いていない限り、ソフトウェアをいつでも好きなときに展開できる状態にするのは非常に困難です(不可能に近づく)。システム管理者、DBA、SRE、セキュリティ担当者、開発者、QAなどがすべて単一のチームの一部であり、ハンドオフで組織の一部としてサイロ化されていない文化。

この回答に投稿されたコメントの一部については、次のようになりました。

「...いつでも好きなときに展開できる状態のソフトウェア」について:「自動パイロット」ソフトウェア(飛行機内)を思い出させます...それについての私のお気に入りの質問:「更新を想像してください」あなたがオンボードにしているが、このようなソフトウェアに適用される...どうやって...機内そう感じでしょうか?」。

私はその質問が大好きです(太字で、上記の引用で)!「本当に準備ができていますか?」という考え 私はいつものことをrantっています- ブログ。IMO CDを練習するためには、セキュリティ、パフォーマンス、その他の頻繁に行われる「二次」テストに自信があることが重要です。機能は完了した時点で完了しますが、ハッカーは常にそこにいます。


おもしろい視点/答え(そして光沢のある画像...)をありがとう。私は用語リリースについて聞いたことがない認めなければならない方法論リリースかかわらず、経営は私が(... 2十年以上のため)とかなりよく知っているものです。「...いつでも展開できる状態のソフトウェア」(「jetlagged」と組み合わせて)について:「自動パイロット」ソフトウェア(飛行機内)を思い出させます...私のお気に入りそれについての質問:「そのようなソフトウェアにアップデートが適用されると想像してください...機内でそうすることについてどのように感じますか?...機内にいる間に?
Pierre.Vriens

1
私はその質問が大好きです!「本当に準備ができていますか?」という考え 私はいつものことをrantっています- ブログ。IMO CDを練習するためには、セキュリティ、パフォーマンス、その他の頻繁に行われる「二次」テストに自信があることが重要です。機能は完了した時点で完了しますが、ハッカーは常にそこにいます。
ケンマグラージュ

1
「アップデートがそのようなソフトウェアに適用されると想像してみてください...機内でそうすることについてどう思いますか...機内にいる間に?」
ケンマグラージュ

編集してください、私はここにn00bです:)
ケンマグラージュ

提案された編集内容を確認して、興味深いコメントも統合してください。気に入らない場合は、以前のバージョンへのロールバック(リンクは「リビジョン」内にあります)を実行するか、必要に応じてさらに改善/拡張してください。推測すると、「許可」の一部が「飛行中」に変更されたようです...そのような提案された編集のために「承認」をまだ必要とするためにすでにここに多くの担当者がいるようです...幸運なことに、これは単なるSE-ソフトウェア(航空管制からの事前承認なしのフライトのあるルートへの推奨更新ではありません...)。Oeps 2(修正):光速で承認されました...
Pierre.Vriens

2

他にないかどうかはわかりませんが、私が使用する基準は次のとおりです。

+-------------------+-----------+-----------+
! Criteria          ! Agile     ! Waterfall !
+-------------------+-----------+-----------+
! Release Events    ! Frequent  ! Rare      !
! Risk              ! Less      ! High      !
! Required Effort   ! Smoother  ! Peaks     !
! Volume of changes ! Small     ! Huge      !
+-------------------+-----------+-----------+

そして、あるソフトウェアのユーザーとして自分自身でその違いを本当に体験したい場合は、(Linuxディストリビューションのような)いくつかのソフトウェアを使用することを考えてください。

  • " Rolling"リリース(==>アジャイル)。

  • " Long Term Support"リリース(==>ウォーターフォール)。


1
Linuxの例あまりインスピレーションにならないかもしれません:)個人的には、次の理由でローリングリリースが嫌いです。作業)。そのため、私は長い(最も長い)期間のもの(多くの場合EOLを過ぎたもの)を使用し、2〜3年ごとに1回だけメジャーアップデートに集中します。これは、加齢によって変化する広告を増やしているだけではありませんか?:)
ダンコルニレスク

@DanCornilescuこのLinuxの例を使用したのは、両方の方法で「a」リリースmgntアスペクト(つまりリリースの頻度)の極端な例だと思うからです。「個人的に」私はあなたが言ったのとまったく同じ理由で、あなたがローリングリリースを嫌うことに完全に同意します。
Pierre.Vriens
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.