チームのリリース プロセス
DevOps プラクティスを設定する最初のステップは、現在のプロセスを評価することです。 これは、次の分析を行うことを意味します。
- 展開パッケージや NuGet などの既存の成果物、およびコンテナー リポジトリ。
- 既存のテスト管理ツール。
- 既存の作業管理ツール。
- 移行と統合の戦略の推奨。
Tailspin チームでこれを行って、DevOps がどのように役立つかを見てみましょう。
プロダクト マネージャーの Irwin が立ち去った後、Amita は次のように言います。「ヘルプが必要です。 これらの修正の期限がいつになるかはわかりませんが、すぐに必要になることはわかっています。 迅速な改善を行うための準備ができていません。 それに、新しい Space Game の Web サイトの運用は、この混乱が解決されるまで待たなければなりません。ですが、このゲームが登場するのはもうすぐです。」
Andy は Mara の顔を見ます。 「入社して最初の数週間に大変な仕事に取り組むことになりましたね。」
「大丈夫です。」と Mara は答えます。 「ここでの仕事のやり方について説明していただけますか。 ゲームはどのように開発環境から運用環境に移行しますか。」
「良い質問ですね」と Andy は言います。 「簡単に答えられるかどうかわかりませんが、やってみましょう。」
チームはコーヒー ショップに行って、リラックスして非公式な話し合いを持つことにしました。 彼らは、これほど多くの問題を抱えている理由を一緒に解明しようとしています。
コーヒーを飲みながら、Mara は話を聞いて、メモを取ろうと努めます。 大量の情報があり、整理されていません。 チームについての彼女の全体的な考えは次のとおりです。
- 彼らはウォーターフォール方式を採用している。 経営陣によって優先順位が設定されている。 開発者はコードを書き、ビルドを QA に渡す。 QA はテストを行い、デプロイのために ops (運用) に引き渡す。
- ウォーターフォール方式は小規模なチームでも許容される可能性があるが、ここでは目標が必ずしも明確ではなく、頻繁に変更されているように見える。
- テストの実行がプロセスの後半まで遅れる。 つまり、バグを修正して変更を加えることがさらに難しくなり、よりコストがかかる。
- "完了" の意味が明確に定義されていない。 それぞれのチーム メンバーが独自の考えを持っている。 全員が同意する全体的なビジネス目標がない。
- 一部のコードは、集中管理されたバージョン管理システムに含まれている。 多くのツールとスクリプトが、ネットワーク ファイル共有にのみ存在する。
- 多くの手動プロセスがある。
- コミュニケーションは場当たり的で、電子メール、Word 文書、スプレッドシートが使用されている。
- フィードバックもめったに行われず、一貫性がない。
- プラス面では、チームの仲は良さそうで、状況を改善したいと思っている。
Mara は、書き留めた大量のメモを見て、このすべての情報を整理する必要があることに気付きます。 これらの情報を整理することで、プロセスの評価がより容易になります。 彼女は、DevOps のアプローチがチームの問題の多くを解決すると確信していますが、自分の主張をチームに提示する方法が必要です。
DevOps のプラクティスは、多くの場合、既存のプロセスを理解することから始まります。 そこから、何がうまくいっていて、何がうまくいっていないかを評価し、最初に修正すべきことに重点的に取り組むことができます。
Mara は、「皆さんの中で "バリュー ストリーム マッピング" の演習を行ったことがある人はいますか?」と尋ねます。
Andy はあきれて天を仰ぎ、Amita はため息をつき、Tim は「これ以上の書類仕事は必要ない」と言います。
Mara は、「分かりました。 では、私が担当します。」と言います。
新人に任せることができたことに満足し、皆は仕事に戻ります。