Subversion を使用する上でのベスト プラクティスに関する多くの情報が含まれている、オンラインの Subversion ブックを一読することをお勧めします。
Practical Perforceという本もお勧めします。Perforce は別のバージョン管理システムですが、Subversion と非常によく似ており、この本には分岐とコーディングの方法に関する優れたアイデアがいくつか記載されています。それはすべてSubversionに非常に当てはまります。
Jira に関しては、シンプルに保つことをお勧めします。本当に、本当にシンプルです。Jira は、企業組織全体ではなく、開発者に最適です。ワークフローはシンプルに保つ必要があります。
Jira に関する優れた本はありませんが、Jira を使用したことがない場合は、特定のフィールドには非常に特別な意味があることを理解し、その意味を尊重する必要があります。
- 解決策は、課題をオープンまたはクローズ (状態ではなく) としてマークするために使用されます。問題に解決策がある場合、それはクローズされています。限目。これは多くの組み込みレポートで使用されるため、尊重する必要があります。
- 各 Jira プロジェクトの核心はバージョン番号です。これは、もう 1 つの非常に特別な概念です。不具合は、報告されたバージョンと修正されたバージョンによって追跡されます。
- ステータス フィールドは、別の状態に遷移する場合を除き、変更できません。したがって、問題を以前の状態にリセットできるバックフローを用意することをお勧めします。誰かが間違った課題をトランジションしようとしており、あなたはそれを修正する必要があります。
- Jenkinsや Bambooなどの継続的インテグレーション システムを使用します。Jenkins と Bamboo は Jira と非常にうまく統合されています。実際、これは Subversion から Jira への直接の統合よりもはるかに重要な統合であると主張します。Jira から直接ソース コードを調べようとする人はほとんどいませんでしたが、QA 担当者は、Jira の問題を見て、どのビルドで修正されたかを確認できるという事実を気に入っていました。
- Atlassian 製品を検討している場合は、Fisheye を検討してください。Web 経由でコードを参照し、差分を表示する方法を提供します。これは、Bamboo および Jenkins とうまく統合されます。これは、開発者が通常、コードの差分などを確認する場所です。Fisheye の適切な代替手段はSventonです。Jira は Sventon と統合されており、Jenkins も同様です。バンブーかどうかはわかりません。
- Subversion ユーザーのメーリング リストに参加してください。そこでの議論が役に立ちます。さらに、そのリストに載っている人は非常に役立つ傾向があります。