2

コンテキスト: 私は伝統的に研究タイプの仕事を行ってきた小さなソフトウェア会社で働いており、商業分野での経験はあまりありません。私たちは現在、商業の世界に進出しようとしています。私たちの起源は研究にあるため、プロジェクトの適切なバージョンを維持するという点で、非常に迅速な開発サイクルと非常に小さな構造に慣れています。

問題: すべての開発者がコード ベースに対してわずかに異なる見方をしているため、構造の欠如が多少の障害になっていることが判明しています。ある開発者が発見した問題は、別の開発者が再現することはできず、あるビルドで見つかった問題は次のビルドで消える可能性があります (または、さらに悪いことに、新しい問題が発生する可能性があります)。これは、すべてのプロジェクトを統合し、品質とパフォーマンスの基準が満たされていることを確認する責任がある人、つまり私自身にとって非常に苛立たしい経験になります。

考えられる解決策: 個人的には、固定のバージョン番号と定期的なリリースを通じて、より良い構造を強制する必要があると確信しています。適切なバージョン管理が私たちの問題の多くにどのように役立つかは自明のことですが、もちろん問題がないわけではありません - 開発者はリリースを実行してテストするために余分な作業を行う必要があり、最新バージョンのすべての。

質問: 要するに、リリースに必要なプロセスと労力をできるだけスムーズに行うために、どのような戦略をお勧めしますか? バージョン管理にはgit、ビルドシステムにはmavenを使用しており、バグ追跡と継続的インテグレーションシステムを実行しているため、ツールはそこにあると思います. 適切なリリースプロセスがどのように見えるべきかについて、私は単に確信が持てません.

4

4 に答える 4

3

バージョン管理、Maven と継続的ビルド サーバーを介したワンクリック ビルド、およびバグ追跡という 3 つの主要な機能が整っています。皆さんはアジャイルな方法論に引き寄せられているようです。そのため、製品のトランク バージョンを常に成果物に近い状態に保つように努める必要があります。

最初のリリースを作成する場合は、そのリリースのトランク バージョンからブランチを作成します。ラベル付けスキームを決定し、必ずブランチ バージョンにラベル付けしてください。たとえば、最初のリリースが 1.0.4530 の場合、1 は最初のバージョンを意味し、0 は最初のリリース候補であることを意味し、4530 はバージョン管理変更番号です。このリリース ブランチをテストし、重要なバグを修正します。しばらくして、1.1.4807 などの別のリリース候補を発行します。このプロセスがさらに数回繰り返され (たとえば)、リリースが十分に良くなり、バージョン 1.3.5167 が出荷されます。

その間、新しい開発はトランク バージョンでのみ行われ、1.x リリース ブランチからのバグ修正をトランクにマージする必要がある場合があります。後で、トランクから 2.x ブランチを分割して、2 番目のリリースのプロセスを繰り返します。通常、いくつかのアクティブなブランチ (およびトランク) があり、開発はトランクに限定され、各ブランチは元のままで開発から独立した状態に保たれます。

皆さんは物事のコツをつかみ、開発者の調整の問題が少なくなります。しかし、これらの問題はほとんどすべて、リリース ブランチではなく、トランクに限定されます。

于 2009-06-05T05:09:20.830 に答える
2

ある開発者が発見した問題は、別の開発者が再現することはできず、あるビルドで見つかった問題は次のビルドで消える可能性があります (または、さらに悪いことに、新しい問題が発生する可能性があります)。これは、すべてのプロジェクトを統合し、品質とパフォーマンスの基準が満たされていることを確認する責任がある人、つまり私自身にとって非常に苛立たしい経験になります。

考えられる解決策: 個人的には、固定のバージョン番号と定期的なリリースを通じて、より良い構造を強制する必要があると確信しています。

内部で調整するためだけに頻繁にリリースする必要はないと思います。バージョン管理を通じてそれを行うことができます。問題を報告するときに、特定の git リビジョンについて話してもらうだけです。また、外部の依存関係/ライブラリも調整する必要があることに注意してください。これには、ある種のベンダー ブランチが役立ちます。

于 2009-06-05T04:43:26.103 に答える
1

開発者は「テストブランチ」を使用し、「安定/本番ブランチ」をもう少し尊重する必要があるようです。

「このブランチで西部開拓時代の仕事をする」というコンセプトで販売し、結果に満足したら、それをこの「退屈な安定した生産ブランチ」にマージします.... (またはそのようなもの)

于 2009-06-05T05:06:18.433 に答える
0

一般的なトピックについて書かれた本があります。Amazon の検索では、「git を使用したバージョン管理」に特化した 3 つのタイトルも返されます。

コード ベースの正規ビューを定義することでメリットが得られると思います。それをテストと呼びます。問題は、テストに表示される場合は問題です。問題が開発者の見解に現れない場合、何が重要な違いであるかを理解するのはその開発者次第です。同様に、開発者のビューには表示されますが、テストには表示されない問題についても同様です。

慣習の 1 つは、Test を毎晩ソースから再構築することです。更新のたびに Test を再構築するという、より厳しい慣習があります。チームが小規模 (5 人以下) で、遠く離れていたり、複数のタイムゾーンに分散していない場合、合理的な最初の概算は、ツールチェーンがいくつかの cron ジョブと共にインストールされているサーバーで git ワークスペースをテストすることです。毎晩更新および再構築されます (通常)。

于 2009-06-05T05:01:59.327 に答える