ソフトウェアプロジェクトを管理/展開する方法の例を探しています
私の会社は、既成の製品の採用を評価しています [〜＃〜] alm [〜＃〜] 開発ライフサイクルを支援する製品。現在、独自のソリューションを使用して、要件の収集、仕様の文書化、テストなどを管理しています。私が抱えている問題の1つは、開発の段階間でコードを移動する方法を理解することです。パイプラインと呼ばれるものがあり、特定のストップで構成されています。
[ソース]-> [QC]-> [プロダクション]
最初に、開発者は要求された変更の解決策を考え出し、個別のテストを実行します。そのプロセスが完了すると（そしてピアレビューが実行されると）、ALMシステムは影響を受けるプログラムを[ソース]ランタイム環境から[QC]ランタイム環境に物理的に移動します。このコードの移動は、パイプラインのステージに一致するように変更要求のステータスを進めることによってトリガーされます。
私は数日間インターネットを検索して、プロセスが他の場所でどのように達成されるかを見つけようとしています-ビルド、自動テスト、さまざまなALM製品などについて少し読んだことがありますが、ビルドが初期とどのように相互作用するかについてはどこにも記載されていません変更要求、トリガーとは何か、依存関係の管理方法、さまざまな形式のテスト（単体テスト、統合テスト、回帰テストなど）への対応方法など。
誰かが特定のワークフローを詳述しているリソースを教えてくれたり、開発ライフサイクルを通じて変更を追跡して移動する方法を（一般的に）説明しようと試みることはできますか？とてもありがたいです。
注：理解しやすくするために、質問を整理しました。また、 この本 を参照している別の質問（今は見つかりません）を見つけました。これはまさに私が探しているもののようです-シェルアウトしたいかどうかはわかりませんしかし、それのための現金。
@ GlenH7の提案による追加の詳細：
当社の製品は、独自の言語と一連の翻訳ツールを使用して構築されています。最終的なランタイム環境は、クライアントアプリがアクセスするサーバー上に多数の「コード」ファイルがあるという点で、Webサイトのアーキテクチャに似ています。 -要求（GET要求とは異なります）してから、ユーザーエクスペリエンスを提供するように解釈します。モジュールのセット（ほとんどはオプション）で構成される統合製品を販売しています。各モジュールには、開発/バグの保守に専念する最大4人のプログラマーと2人のQCテスターのチームがいます。製品ラインごとに約30のモジュール（および3つの製品ライン）があります。一部のチームは、特定のモジュールに対して複数の製品ラインを維持しています。合計で、700人の従業員が開発に専念し、約200人のプログラマーがいます。確かに、新しいプロセスやシステムを採用するには、賛同などが必要になりますが、私は、物事についてインテリジェントに話すことができるように、コードがどのように管理されるかを単純に理解する必要があります。私の最初のタスクは、プロセスにバージョン管理を採用する方法を学ぶことでした（ほとんどの製品ラインではまだ正式なバージョン管理を使用しておらず、コードベース全体の複数のコピーを保持する代わりに依存しています）。
私たちはウォーターフォール方式にかなり厳密に従います（これは残念ですが、同社は1969年からソフトウェアを作成しているため、当時はおそらく自然に適合し、今までは何も変更する必要はありませんでした）。アジャイル手法のさまざまな提供に興味を持っている人もいますが、以下の@Chadで指摘されているように、そのような最終目標に向けて段階的なステップを踏む必要があります（ただし、ALMシステムを採用する場合はみんなに物事を行うためのまったく新しい方法を強制する時が来ました）。
現在のプロセスの具体例として、MISおよびITSモジュールを備えたHISという製品があるとします（これらが何であるか、または何であるかは重要ではありません。これらを単なるファイルのコレクションと考えてください）。現在のプロセスでは、誰かがITSの変更を要求すると、コーダーは開発サーバー上のいくつかのファイルを（効果的に）変更します。その変更をテストする必要がある場合、変更要求のステータスを「開発が必要」から「qcが必要」に移行すると、ツールがトリガーされ、影響を受けるファイルが開発サーバーからQCサーバーにコピーされます。これで、QCテスターがQCテスト環境にサインオンすると、変更の影響を確認できるようになります。変更を承認し、リクエストのステータスを「本番準備完了」に進めると、ツールはコードファイルを次のステージに再度コピーします。そこでサインオフすると、最終的なコピーが顧客への配送に使用される保管場所に作成されます。
メジャーリリース番号（例：6.0）、サービスリリース指定（例：5）、および「優先パック」番号（例：1）でリリースの配信を管理します。お客様は、優先パックの配信を行います。 6.0.5.1。上記のように、コードを複数のサーバー上の場所から場所にプッシュするだけなので、パイプライン全体のメジャーリリースとサービスリリースごとにプロジェクトフォルダーが作成され、各ppackの最終的な休憩場所が作成されます。例：
dev6.0
qc6.0
production6.0
dev6.0.5
qc6.0.5
production6.0.5
ship6.0.5.1
バージョン管理の下で、この種のスキームを次のようにシミュレートできると考えていました。
trunk
branches
--6.0.5
tags
--6.0.5.1
しかし、それは場所の半分しかカバーしていないようです。つまり、qcと生産ソースはどこにありますか？製品のメジャーリリースとマイナーリリースごとに個別のトランクを作成しますか？または、QCおよび生産停止で行われるテストで興味深いリビジョンを追跡するために、バージョン管理外の何か（ALMシステムなど）に依存しますか？それでも、それぞれにランタイム環境が必要ですが、バグ修正と機能が利用可能になると、オンデマンドで「構築」できます。これにより、これらのステージの特別な「コピー」を保持する必要がないという考えが強化されます。バージョン管理（トランクまたはブランチの改訂履歴への参照にすぎません）。
同僚がブランチに何も永続化してはならないというループに私を投げ込んだもう1つのことは、ブランチフォルダーは一時的なものであり、トランクに直接コミットできない大きな変更時にのみ使用する必要があります（ブランチが最終的にトランクにマージされるという期待）。彼のスキームでは、マイナーリリースでは、独自のトランク、ブランチ、タグのセットを備えた別のトップレベルが必要になります。例：
product6.0
trunk
branches
--silly_new_feature
tags
--6.0.5
product6.0.5
trunk
branches
--crazy_bug_fix
tags
--6.0.5.1
（これらの詳細の追加が遅れて申し訳ありません-一日中会議に引き込まれました）
私が見つけたアプローチは、開発とテストの2つのビルド環境でうまく機能します。開発ビルドは頻繁に発生し、統合の問題を解決し、変更（機能を含む）を標準ビルドでテストできます。
テストビルドはオンデマンドでトリガーされ、受け入れられた場合、ビルドは本番環境にプロモートされます。ビルドのテストは、特に計画されたリリースの近くで、別のブランチで行われる場合があります。ブランチでの変更は、開発に統合する必要があります。
このアプローチにはいくつかの仮定があります。
- メインラインの開発はトランク上で行われます。 （機能開発は次のリリース用であるか、非アクティブ状態でリリースできます。）
- 環境固有の情報はすべて、環境から取得されます。環境を変更する場合、ビルドは必要ありません。さまざまなメカニズムを使用できます。
- リリースは、機能とバグの変更の調整されたセットで構成されています。 （機能またはバグ修正の間に依存関係がある場合、1つをプルすると、変更のカスケードが発生する可能性があります。）
- リリースされた（またはリリースされた）バージョンへの修正を管理するために、別のブランチが作成されます。これには、追加の開発ビルド環境が含まれる場合があります。
- ビルドのタグ付けは、ビルドのテストで行われます。これにより、変更が必要な場合、またはコードを調査する必要がある場合に、そのコードを簡単にロードできます。
予算のウィッシュリストに載っていない傾向があるため、ALMソフトウェアは使用していません。上記のアプローチは、標準のビルドおよび構成管理ツールを使用して実装するのはかなり簡単です。
ALMで私が気づいたことの1つは、退職がうまく管理されていないことが多いということです。一時的な機能や修正されたバグが実際にコードから削除されることはめったにありません。これは、実装時に機能を閉じる変更追跡に一部起因する可能性があります。必要に応じて、退職金変更チケットを追加することをお勧めします。
編集：新しい環境に移動するためにビルドを必要とするテスト済みコードの失敗をいくつか見ました。環境構成のみがビルドに含まれ、他のデータが含まれていないことを確認することは困難です。
環境間で変化するものには、次のものが含まれます。
- データベース接続：私が通常使用するソリューションは、コンテナーに名前付き接続プールを提供させることです。環境が異なれば構成も異なりますが、これはデプロイされたアプリケーションに対して透過的です。
- ディレクトリ：必要に応じて、相対ディレクトリパスを使用すると適切に機能します。パスの一部として環境提供の変数を使用すると、他のほとんどの場合をカバーします。
プロパティ：これらは、データベース接続、ディレクトリ、およびその他のさまざまな設定の構成に役立ちます。 （おそらく協調して）使用できるいくつかの選択肢があります：
- 適切なプロパティを使用してコンテナを構成し、そこからプロパティを読み取ります。
- 環境ディレクトリに関連するディレクトリにプロパティファイルを提供します。
- データベース接続からプロパティを読み取ります。
一部の実装では、プロパティの1つが場所を指定します。これをインターフェースに表示して、使用されている環境をすばやく判別できます。ビルドバージョンも表示される場合がありますが、これはビルドアーティファクトの一部であり、環境仕様ではありません。
あなたがする必要があるのはあなたのソフトウェア開発リリースプロセスを定義することです。
既存のプロセスを形式化することから始めることができます。開発者にプロセスに関する意見を聞いてもらい、プロセスに発言権があるように感じてもらうことをお勧めします。学んだ教訓を踏まえて、プロセスを定期的に確認してください。何が機能していますか？私たちの問題点はどこにありますか？改善するために何ができるでしょうか？
チームの賛同を得て、プロセスを段階的に改善します。チームは専門家であり、実施されている統制の価値を理解していると思われます。
あなたがあなたの質問にリストしている本は、あなたのプロセスの最初の反復のためにあなたの手の届かない解決策を持っていると思います。これは、チームをそのソリューションに向けて導くことができないという意味ではありませんが、実証済みで効果的で一貫性のあるプロセスコンプライアンスは一夜にして実現しません。反復的なアプローチは、特にあなたが彼らの喉を詰め込もうとしているプロセスの経験を持つ人がいない場合、よりうまくいく傾向があります。インターネット上のSLDCには、かなりの数の方法論と記事があります。私は、あなたの環境で機能するかもしれないし、機能しないかもしれない高度なシステムにお金を使う前に、無料の記事から始めます。