問題タブ [release-management]

私は、展開ドキュメントの構成に関して同僚と絶え間なく戦いを繰り広げています。

文書が必要であることに誰もが同意します。特に大規模なリリース、バグ修正、および機能強化を区別するために、どのレベルの詳細を含める必要があるかについて、誰もが共通の基盤を見つけることができるわけではありません。

何があなたにとって最も効果的であると思いましたか?

経験のある人がこれをもう少し説明できるかどうか疑問に思います。私は例を見てきました...

....（void）dealloc内。

違いは何ですか？一方は他方よりも優れていますか？最善の方法は何ですか？

個人的にretainCountテストを実行すると、nilが3から0にカウントを落とすのを見ましたが、releaseは3から2にしかカウントを落とさないのです。

Web アプリケーションに Zend Framework と Ruby On Rails のどちらを使用するかを決めようとしています。

ZF を使用する場合、次のものが必要です。

• RoR の移行機能 (001_something.sql、002_something_else.sql) と同様に、データベースへの変更を段階的に追跡する方法。
• ソフトウェアの次のリリース用に SQL を配置する場所。カスタム PHP ソリューションでは、リリース時に実行、アーカイブ、および消去される release.sql しかありません。

ZF には Zend_Db_Schema_Manager があり、これは同じことを行いますが、公式、完全、または維持されていないため、私は興味がありません。

私が説明したのと同様のことを行うために ZF が提供する公式のメカニズムはありますか?

EDIT私はRailsで行きました。比類なき。

異なる言語、構成ファイル、構成スクリプト、環境設定、およびデータベース移行スクリプトで記述された複数のコンポーネントを含む大規模なソフトウェア プロジェクトがある場合、本番環境へのデプロイの一般的な方法は何ですか?

考慮すべき困難は何ですか？Ant や Maven などのツールを使用してプロセスを簡素化できますか? ロールバックとデータベース管理はどのように処理できますか? 本番環境でバージョン管理を使用することは賢明ですか?

Pypiで維持している卵がいくつかありますが、これまでは常にPython2.5xに重点を置いてきました。Python2.5とPython2.6の両方で自動化された方法で卵をリリースしたいです。

1. テストの実行
2. ドキュメントの生成
3. 卵を準備する
4. Pypiへのアップロード

どうやってこれを達成しますか？

関連する質問：卵に「バージョンに依存しない」タグを付けるにはどうすればよいですか？Pythonのすべてのバージョンで動作しますか？

Ant プロジェクトを Maven プロジェクトに変換しています。このプロジェクトは、非常に頻繁に (通常は 1 日に 8 ～ 10 回) リリースされるため、私が通常変換したプロジェクトとは異なります。

リリースとは、結果の jar がパッケージ化され、運用環境に含まれていることを意味します。このプロジェクトはリーフプロジェクトであるため、API を発行せず、使用するだけです。また、多くても他の 2 つのプロジェクトのランタイム依存関係です。

次のようなバージョン管理スキームが必要です。

• 番号には意味がないため、開発者がプロ​​ジェクトに割り当てるバージョン番号について考える必要がなく、簡単に展開できます。
• このプロジェクトの最新バージョンを依存関係として含めるのは簡単で、依存関係のバージョンを頻繁に上げる必要はありません。

他のプロジェクトで使用して-SNAPSHOTいる と競合するため、依存関係のバージョンはおそらく ではありませんが、提案は受け付けています。maven-release-plugin

独立して開発されたいくつかのコンポーネントを含むプロジェクトがあります。それでも、さまざまなスケジュールのさまざまな製品として名前が付けられた多くのリリースがあります。コンポーネントに新しいバージョン (おそらくバグ修正に関連するもの) がある場合は、すぐにフィードバックを得たいと考えています。したがって、そのバージョンに依存するすべての製品も同様に更新されます。

もちろん、これは単純な例です。このシナリオ専用のプロジェクトがあるはずですが、見つかりませんでした。そのような状況に対処するために何をしますか？推奨される (簡単で強力な) 方法は何ですか?

「通常の」svnディレクトリ構造とは異なり、私は次の構造を使用しています。

ご覧のとおり、プロジェクトごとに個別のトリプル（トランク/ブランチ/タグ）はありません。

開発のために、必要なすべてのプロジェクトを含むトランクのチェックアウト（場合によってはスパースチェックアウト）を実行します（プロジェクト間には依存関係があり、一部のプロジェクトは単なるライブラリです）。

これに見られる利点は次のとおりです。

• すべてのプロジェクトに共通のルートディレクトリ（トランク）があるため、更新とチェックインは簡単です。1つは単純であるsvn updateか、svn commitそれをすべて行います。

• タグまたはブランチの作成は簡単です。これを行うために必要なのはトランクだけだからsvn copyです。（ブランチとタグには実際には必要以上のプロジェクトが含まれていますが、asvn copyは安価であり、必要に応じてブランチまたはタグでスパースチェックアウトを実行できます。）

• リソースはすべて同じリポジトリにあるため、あるプロジェクトから別のプロジェクトへのリソースの移動は簡単です。

• トランクのフルチェックアウトに取り組んでいるときは、プロジェクトを見逃さないようにすることができるため、グローバルリファクタリング（たとえば、一般的に使用されるクラスのパッケージの変更）は簡単です。

• あるプロジェクトから別のプロジェクトへのリファクタリングの移動があった場合でも、ブランチ全体を一度にマージできるため、マージは簡単です。

私はMavenに移行し、すべてのプロジェクトをトランクからMavenプロジェクトに分割するつもりです。Mavenの依存関係管理と利用可能なプラグインの恩恵を受けたいです（現在、巨大なカスタムantファイルを使用しています）。

今私の質問は次のとおりです。

• すべてのプロジェクトに独自のトリプル（トランク/ブランチ/タグ）を与えるためにsvnディレクトリ構造を変更する必要がありますか？答えは「はい」だと思います。

• 構造を変更した場合、上記の利点のどれが失われますか（つまり、Mavenでそれを行うとより複雑になることを意味します）？

• Mavenでそれを行うための同等の方法は何ですか？

ASP.NET Web サイト/Web アプリの展開に関する知識を増やす必要があります。私たちはますます大きくなり、トラフィックが増えており、より専門的なアプローチが必要です. 言うまでもなく、複数のデータベース/複数のバック エンド/複数のフロント エンド サーバーの展開にも移行しており、それを台無しにしたくありません。

どのタイプのスキルを探す必要がありますか?また、これらのスキルを持つ人々が使用する典型的な称号はありますか?

ありがとう、

実際、私たちは 2 つの回答で言及されている才能のほとんどを持っています。私たちが探しているのは、Dave が Web サーバーの第一人者と呼んでいるものだと思います。誰かに展開の側面を処理してもらいたいだけです。私たちが持っている開発者は、開発のベストプラクティスを理解しようとするのではなく、自分の目的のために取り組む必要があります。また、最終的には複数のプロジェクトとチームになる可能性があり、各チームに個別の担当者が独自のソリューションを導入することは、すべてのチームに 1 つの専用リソースほど効果的ではないと思います。

私の最後の雇用主は、進行中の開発に対処するためにSVNの上に座った精巧なシステムを開発しました:(変更管理）バグ/問題を調べ、バグID番号と（リリース管理）タグをタグ付けしてコミットを行うときにそれらをコミットに関連付けますバグ/問題追跡システムに基づく特定のリリースの一部としてのSVNのアイテム。この2番目の部分には、ユーザー/管理者からサインオフを取得するためのワークフローが関連付けられていました。次に、リリースを行うとき（通常は毎週木曜日の夜）に、コマンドを実行して、タグ付けされたすべてのコードをチェックアウトし、デプロイすることができます。

私の新しい会社ははるかに小規模であり、SVNと直接取引することを意味する場合でも、低コスト/低メンテナンスの同等品を見つけることに興味があります。特に、ゲームの後半でコミットがビルドを壊してしまうことがよくあり、含めることができるものを解きほぐすのは非常に困難になります。（SVNの管理に関する限り、私はブランチよりもタグのアイデアを好む傾向があります。これは、事前の考慮が少なくて済むためですが、そうでないことを確信できてうれしいです。）

リリースのコミットにタグを付け、その後のデプロイメントを行うために、人々は何を使用しますか？WebブラウザからSVNを参照し、リリースの問題/コミットにタグを付けることができるリリースサイクルを管理するための優れたオープンソースソリューションはありますか？私がこれまでに見た中で最高のものはJiraですが、それは非常に大きなツールのように見えます（構成/保守が難しいですか？）。Apache Foundationは、この目的のためにJiraをうまく利用しています（たとえば、Mahoutロードマップを参照してください）。

これを超える一歩を踏み出すと、この同じシステムに継続的インテグレーションも含まれるようになり、各コミットで単体テストを実行できるようになり、各バグ/問題にもこの情報が関連付けられます。

注：stackoverflowには少し関連性のある質問がいくつかありますが、デプロイサイクルとリリース管理のこの側面をカバーするものは何もありません（release-management-in-svn、manage-your-project-life-cycle、およびbestを参照してください）。 -way-to-handle-change-management）。