問題タブ [release-management]

少し前まで、Microsoft VSS をバージョン管理ツールとして使用しており、すべてのリリースの終了後にコードのブランチを作成し、それをクライアントに展開していました。

今は SVN に移行し、最近タグ/ブランチについて多くの議論がありました。特定のリリースの開発後にコードにタグを付けたりブランチしたりする必要がありますか?

SVN は実際にそのような目的で「タグ」を推奨していますが、それ以上の変更を加えないことも推奨しています。このリリースで発生する凶悪なバグ修正はどこで行うのでしょうか?

他に行っていることは、タグとブランチの両方を作成し、タグをクライアントにデプロイし、バグが発生した場合に備えて、ブランチに修正を加えてから再度タグ付けすることです :-(

他の人は何をしますか？

私は、いくつかの役割でいくつかのサーバーを持っている本番環境のシステムを持っています。本番環境のすべてのサーバーに再デプロイすることなく、特定のサーバーにデプロイして新しいアプリサーバーをテストしたいと思います。Capistranoに特定のサーバーにデプロイするように依頼する方法はありますか？理想的には、次のようなものを実行できるようにしたいと思います

app2.example.comにデプロイしたいだけの場合。

ありがとう！

[更新]次を実行して、wulongによって提案された解決策を試しました。

しかし、capistranoは、アプリタスクに加えて、そのサーバー上の他の役割のタスクを実行しようとしているように見えました。たぶん、capのバージョンを更新する必要があります（v2.2.0を実行しています）？

アルファ、ベータ、および RC1 という用語が、ソフトウェア業界全体で使用されている用語なのか、MS だけで使用されている用語なのか知りたいです。

定義は何ですか？

マルコム

ホストされた Web アプリの新しいバージョンをリリースするための最良のアプローチは何ですか? また、通常はどのくらいの頻度でリリースしますか? 毎週、毎月など任意の日付を選択して、蓄積された一連の修正プログラムを展開しますか (おそらくJoel の出荷日へのアプローチと同様のアプローチを使用します)。それよりもはるかに長く待機すると、ホストされたアプリの主な利点の一部が損なわれるようです. 一方で、ユーザーを混乱させる可能性のある新機能を常にロールアウトすることは望ましくありません (つまり、ユーザーがログインするたびに何かが異なる場合)。

最近まで、私の経験は主にインストール済みのサーバーベースまたはデスクトップ アプリでした。ホスト型アプリで人々がどのようなタイプのリリース管理を使用しているかを知りたいです。

私の経験から言えば、Web 開発プロセス中に遭遇する大きな問題の 1 つは、さまざまなサーバー間でさまざまなセットアップを最新の状態に保ち、安全に保つことです。

私の会社には独自の CMS があり、現在 100 以上のサーバーにインストールされています。現時点では、ハックっぽい FTP ベースのアプローチを使用し、特定の場所でアップグレード スクリプトを組み合わせて、すべての CMS セットアップをアップグレードしています。これらのセットアップを効率的に管理することは、複数のカスタム モジュールが関係している場合、ますます困難でリスクが高くなります。

• Web アプリケーションの複数のセットアップを安全かつ最新の状態に保つ最善の方法は何ですか?
• どのようにしますか？
• クライアントに対する柔軟性を維持しながら、アプリケーションの複数の「ブランチ」を効率的に管理できるようにするために、アプリケーションのモジュール性に関する具体的なヒントはありますか?

いくつかのコンテキスト情報: 私たちは主に LAMP スタックで開発しています。CMS の販売に役立つ主な要因の 1 つは、クライアントが必要とするほとんどすべてのものをプラグインできることです。これは、10 行から 10,000 行のカスタム コードになる可能性があります。

多くのカスタム作業は、非常に小さなコードで構成されています。Subversion でこれらすべての小さなコードを管理するのは、非常に面倒で非効率的だと思います (毎週約 2 つの Web サイトを配信しているため、多くのブランチが発生することになります)。

何か見落としがある場合は、ぜひお聞かせください。

前もって感謝します。

まとめ:まず、すべての回答に感謝します。これらはすべて本当に役に立ちます。

私はおそらく SVN ベースのアプローチを使用します。これにより、benlumleyのソリューションが私が使用するものに最も近くなります。この質問への回答は、他のユースケースでは異なる可能性があるため、実行の最後に最も投票数の多い回答を受け入れます。

回答を調べて、最も付加価値があると思うものに投票してください。

私たちは、何十ものクライアント プロジェクトで成功裏に使用してきた非常にクールな小さな Web フレームワークを持っています。このソフトウェアをコミュニティにリリースする予定です。しかし、私は、新しいオープン ソース ソフトウェア プロジェクト ページに何を載せるべきか、何を載せるべきでないかについて、自分の手を絞っています。サイトに必要なものは何ですか？ドキュメント？ウィキ？ダウンロードへのリンク？ほかに何か？

また、関連しているがおそらく別の質問は、リリース番号のマークをどのように開始するかということです。内部で使用するのは SVN スタンプだけです。バージョン 0.9 と 1.0 および 1.1 などの呼び出しをいつ開始するかを判断する良い方法はありますか?

SVN のログを見ると、いつリリースが行われたかを示すマーカーが表示されたらいいのにと思います。PVCS やPerforceなどの他のバージョン管理システムでこれを見てきました。

これはSVNで行うことができますか? 少し調査しましたが、これまでのところ、この種のことはサポートされていないようです。

編集

リリースごとにソースを別のフォルダーにコピーする必要はありません。これにより、開発者のマシン上に膨大な量の不要なファイルが複製され 、各リリースのリビジョン番号の記録しか得られません。テキストドキュメントを使用してそれを行うことができます！

編集2

私の目標は、リリースの年表を示す単一のビューを作成することです。その間に、各リリース間で行われたすべてのコード変更を確認できます。これにより、リリース ノートの編集が容易になります。

Maven2 を使用して、開発環境から dev-server ディレクトリにコピーしたい構成ファイルとさまざまなドキュメントがあります。不思議なことに、Maven はこの作業が得意ではないようです。

オプションのいくつか:

• Mavenでコピータスクを簡単に使用

• Ant プラグインを使用して、Antからのコピーを実行します。

  • 通常はタイプjarのPOMの「メイン」アーティファクトとともに、タイプzipのアーティファクトを構築し、そのアーティファクトをリポジトリからターゲット・ディレクトリに解凍します。

  • 以下に示すように、maven-resourcesプラグイン。

  • Maven Assembly プラグイン - しかし、単純に「慣習的に」物事を行いたい場合、これには多くの手動定義が必要なようです。

  • このページには、コピーを行うためのプラグインの作成方法も示されています!

  • 以下に示すように、maven-uploadプラグイン。

  • 以下で説明するように、 copyを使用したmaven-dependency-plugin。

これらはすべて不必要にその場しのぎに思えます。Maven は、これらの標準的なタスクを大騒ぎせずに行うことに優れているはずです。

何かアドバイス？

これまでに提供されたリリース候補の会社に関与したことがないことに気付いたので、これについて疑問に思っています。最近、この用語がますます使用されているので、彼らのリリース候補についてもう少し明確にしたいと思います含意。

以前に RC を提供する会社で実際に働いたことがある人のために...リリース候補が実際に必要とするもの (RC とベータの違いなど) について、これ以上正式な仕様があるのでしょうか?それとも単なるポリシーですか?各企業が独自に決定するものですか？

この種の仕様を持っている会社で働いている場合は、バージョンを「リリース候補」に昇格させるガイドラインのいくつかの例を提供していただけませんか。