私が知っている多くの OS プロジェクト (私は PHP 開発者です) はバージョンをマイルストーンとして使用していますが、これが最善の方法ですか? マイルストーンは、プロジェクトのイテレーションの過程にあるもの (フル ネームを意味する) を意味する必要がありますか? 何かルールはありますか？それとも完全に主観的なものでしょうか？
5 に答える
4
古いことわざにあるように、「標準の素晴らしい点は、選択できるものが非常に多いことです。」PHP プロジェクトでどのように行うかはわかりませんが、私たちのショップ (.NET ショップ) で使用するアプローチについては言えます。
私たちはかなり伝統的な 4 部構成のバージョン管理システムを使用しており、バージョンの各部分は異なるものを表しています。例えば：
メジャー.マイナー.リビジョン.ビルド
明らかに、それらのそれぞれは数字になります。これらの 4 つの部分は、Microsoft によって事前に定められています。それぞれをどのように正当化するかについて、スタックをさかのぼって説明します。
- ビルド - 当店で自動的にインクリメントされます。このインジケーターは、コンパイラーによって提供されるため、ビルドの一意の識別子のようなものです。
- リビジョン - 互換性を損なわないリリースのためにこれを予約します。公開されたインターフェースは保持され、サードパーティの実装はおそらく変更なしでそのまま実行されます。
- マイナー - これは通常、新しい機能を導入し、既存の機能を変更し、互換性を損なうリスクが高いリリースです。
- メジャー - 大規模な書き換え、大規模な新機能セット、および以前のコードベースからの根本的な逸脱を含む大規模な変更。
マイルストーンはどこで使用されますか? それらは私たちのプロジェクトの目標です。マイルストーンは、プロジェクトの開始前に決定され、予想される進捗レベルを満たす必要があるポイントを表します。これは主に、リリース前にビジネス ユーザーに機能を紹介し、リリースの全体的な配信スケジュールを監視するために使用されます。さらに、何らかの理由で手動でビルドする必要がある場合にマイルストーンを簡単に識別できるように、各マイルストーンのバージョン管理にラベルを適用します。
当店ではマイルストーンの呼び名より内容を重視しています。なんで？複雑なマイルストーンは、それがマイルストーンである理由が複数ある場合、意味を伝える方法で簡単に名前を付けることができません。カレンダーと wiki にマイルストーンを設定し、その中で何が達成されると予想されるかを説明します。
先に述べたように、他の「基準」も得られると確信しています。目標は、あなたとあなたのチームにとって有効なプロセスを見つけ、それに固執することです。
于 2008-12-05T10:35:06.760 に答える
3
私たちの開発プロセスでは、バージョンとマイルストーンは別物です。私たちの標準的なマイルストーンの 1 つはリリースです。もちろん、それにはバージョンがあります。しかし、私にとって、マイルストーンは将来の何かであり、私が計画しなければならないものです. バージョンはリリースに結合されているため、過去のものです。
当社の標準マイルストーン スキームは、全社的なプロジェクト管理基準に基づいています。我々は持っています
- Sゲート：指定
- Aゲート：あり
- V-Gate:検証済み
- Rゲート：リリース
反復開発では、基本的にこのサイクルを繰り返します。A から V ゲートまでがアルファ フェーズ、V から R までがベータ フェーズです。大規模なプロジェクトの場合、特定の機能セットの完了に関連するマイルストーンを追加します。
私たちがそれを使用する主な理由は、すべてのプロジェクトがこのスキームに従って報告されるためであり、管理者が慣れ親しんだ方法で情報を提示することは常に良い習慣です;-)
于 2008-12-05T10:56:28.633 に答える
1
そうです、それはあなたがイテレーションで十分な作業を完了して何か有用なものをリリースしたことを意味します。マイルストーンとは、通常、イテレーションの終了よりも重要な何かを達成したことを意味します。はい、意味のある名前を使用します。
于 2008-12-05T10:28:20.017 に答える
1
あなたは少なくとも2つの無関係なことについて話している. ソース コード管理とプロジェクト マイルストーンがあります。それらは関連していますが、同じものではありません。さらに、ソース コードやプロジェクトのマイルストーンに関連するソフトウェア開発作業自体もありますが、それも異なります。
スクラムに基づくアプローチを次に示します。番号または名前を付けることができる 3 つの無関係なものがあります。
まず、ソフトウェア開発の仕事があります。
ものを構築するためのスプリントがあります。これらには番号を付けることができますが、通常は名前があります。「バルク ロード パート 1」、「ワークブック ライブラリのリファクタリング」、「セールス デモ データ フィクスチャの追加」などの名前。
ものをリリースするためのリリースがあります。これらには番号が付けられます (SVN リビジョンに基づいて、または内部の「互換性バージョン」に基づいて)、通常は名前が付いています。意味のある。
2 つ目は、ソース コード管理です。このため、スプリントやリリースとはほとんど関係のない内部バージョン/リビジョン追跡があります。
SVN にはリポジトリのバージョン番号があります。これは、チェックインごとに増加します。数週間、毎日チェックインがあります。数週間、「大きな」チェックインが数回しかありません。
互換性を示すために手動で更新するメジャー.マイナー バージョン番号があります。一部のアプリケーションは、小さな変更により 1.1 から 1.2 に移行しますが、データベースと API は同じです。他のアプリケーションは 2.3 から 3.1 に移行します。これは、データベースまたは API (またはその両方) が互換性のない方法で変更され、スキーマの移行を行う必要があり、場合によっては REST クライアント インターフェイスへの変更を顧客に通知する必要があるためです。
3 つ目は、プロジェクトの計画です。
プロジェクト計画のマイルストーンには、リリース スケジュールが含まれます。ただし、プロジェクトのマイルストーンには、ソフトウェアとはほとんど関係のない他のものが含まれています。マイルストーンには、「新しいホスティング契約への署名」や「顧客 X のテスト データの取得」などがあります。これらは、バージョンでもリリースでもスプリントでも何でもありません。
「ルールはありますか？」はい。適切なルール セットについては、スクラムを参照してください。
これは単一のことではありません。それは2つ（または3つ）のことです。
于 2008-12-05T11:15:05.913 に答える
0
バージョン番号は、2 つのバージョンのうちどちらが新しいかをすぐに確認できるので便利です。どの機能またはバグ修正がマイルストーンを構成するかを誰が言えるのでしょうか?
私が気に入っているスキームは xyz で、x はメジャー リリース番号、y はマイナー リリース番号、z はビルド番号です。メジャー リリースとは、書き直し、オーバーホール、または主要な新機能の導入のいずれかを意味します。マイナー リリースとは、重要なバグ修正、またはいくつかの小さな機能の改善やバグ修正を意味します。ビルド番号はまさにそれです-ビルドの数。
于 2008-12-05T10:29:28.563 に答える