はじめに
十分に確立され完了したプロセスは私たちには向いていません！ すべてがすでに設定されており、時計のように機能するのは退屈ですが、これを探す必要があります。 そしてその後、行われた作業に喜びを感じ、すべてがうまく機能する方法をもう一度確認してください...
どのコードが生産的な操作に入るかは非常に重要です。 その安定性と予測可能性は重要です。 厳格な品質管理規制を使用する場合、新しい機能の導入速度は確実に低下します。
この点で、最小限のテストの後、かなり粗雑な「開発」コードが顧客に提供される場合が頻繁にあります。 これには多くの問題が伴います。
N.N.U
プロジェクトの通常の状況を想像してください。 プロジェクトはすでに6か月前で、まだ若く、特に機能的ではありません。 変更は、分散チームによって毎分行われます。 お客様は、実装後すぐに新しい機能を必要とします。
継続的インテグレーションを使用することは魅力的です。これは、メインの開発ブランチのコードでお客様のサーバーを更新することで表現されます。
仮定1：メイン開発ブランチのコードは不安定です
この場合、顧客でコードを更新するアプローチは問題のみをもたらします。 バージョンで表現されたコードスライスを修正し、お客様のバージョンのコードのみをインストールする必要があります。
もちろん、mainブランチのコードが安定していると仮定することに反対することができます1。 はい、これは単体テストで十分なカバレッジがあり、広範な機能テストと統合テストが実行されている場合に可能です。 QA部門は非常に厳しいです。 コードはブランチで開発され、慎重なテストの後にのみメインブランチに転送されます。
多くのプロジェクトには、品質管理とテスト部門がありません。多くの場合、テストはありません。 すべての開発はメインブランチで実行されます。 ここでは、そのようなプロジェクトについて、仮定1が表明されています。
リリース版
コードはほとんどコンパイルされていません。致命的なエラーではなく、多くのエラーがあります。顧客はシステムのタイプと動作から灰色に変わり始めますか？ バージョンをリリース！
この下位製品のバージョンをリリースします。 バージョンを顧客に発表し、次のリリースのリリース予定日を概説します。 それは魔法のように振る舞います。 顧客は製品の新しいバージョンを望んでおり、開発者は顧客から大声で叫んだり、管理者からの圧力をかけたりすることなく、コードを記述してエラーを修正するための完全な反復を行います。
やる気
最初のバージョンのリリースについてです。 最も重要なのは、製品全体がそれに基づいて構築されるためです。 それがなければ、成功した製品の他のバージョンはありません。 そして、チームは仕事に対して冷静になっています。 もちろん、最初のバージョンをリリースした後、ペースを忘れないようにし、できるだけ早く、より安定して顧客が望む製品の2番目のバージョンをリリースすることが重要です。
長所
バージョンのリリースの肯定的な側面のうち、次の点を区別できます。
- 製品の「基準点」の作成;
- 顧客への新しい機能の取得を規制。
- 製品の安定性と品質の向上。
- チームの通常のリズム。
- 広範な製品開発計画の機会。
- 開発の「制御可能性」。
- 新しいエラーを追加することなく、エラーを簡単に修正できます。
短所
プロジェクトの初期段階で最初のバージョンをリリースすることの欠点もあります。
- お客様による「トレーサー射撃」 。 誰もがこれに対応できるわけではありません。
- リリースバージョンの新作。
- 反復のために、顧客への新しい機能の提供を遅らせる。
各読者が最初の粗野なバージョンのリリースのいくつかのプラスとマイナスを引用できる可能性を排除しません。
おわりに
ほとんどの企業では、ビルドマスターの地位にある人を見つけることができません。 そのような人であれば、リリースプロセスははるかに簡単です。 しかし、それがなくても、製品のバージョンをリリースできます。 まあ、非常に最初のバージョン、これは長いプログラムライフの始まりにすぎません。
さらに、このバージョンのリリースにより、チームに興味深い面白い伝統が生まれます。 一番簡単なのは、バーに行くこと、イブニングボードゲーム、映画セッション、ネットワークゲームをチームとして行うことです。
NNU-初期条件がゼロ。