私は、開発者として通常の開発プロセス内で継続的インテグレーションを使用することにかなり慣れていません。しかし、私は ci を私たちのソフトウェア チームに導入する仕事をしてきたので、これを達成するためにいくつかの試みを行ってきました。
現在、次のものがあります: 0. ソース リポジトリとしての BitBucket 1. Team City 2. ProGet サーバー 3. Octopus Deploy 4. 開発テスト VM 5. UAT テスト VM 6. 本番 VM
一般に、プロセスは次のようになります
- リスト項目
- BitBucket からソリューションを確認する
- 変更を加える。
- Bitbucket にコミットする
- チーム シティ ビルド
- Team City は成果物を nuget パッケージとして ProGet にプッシュします
- Team City は Octopus Deploy でリリースを作成し、Development Test vm への自動デプロイをトリガーします。
- UAT への手動 Octopus プッシュ
- Octopus による本番環境への手動プッシュ
私たち開発者を除くすべての人にとって、トップレベルのすべてが問題ないように見えます。
私たちの問題はコンセプトではなく、プロセスと共に生きることです。その理由は、2 番目のソリューションが ProGet サーバーからの最初のソリューションのナゲット パッケージを参照する 2 つのソリューションがあるためです。これが意味することは、依存ソリューションが最初のソリューションで変更を必要とするたびに、サイクルが発生するのを待ってから、2 番目のソリューションで nuget パッケージを更新して必要な変更を完了する必要があるということです。
必要な結果が得られるまでにこのサイクルが何度も発生する必要がある場合、これは非常にイライラします。
私が望むのは、ci が変更されたパッケージをビルドして公開するのを待たずに、開発者の PC で両方のソリューションを開発することです。これは、最初のソリューションの dll がローカルで参照されることを意味すると思いますが、これを変更して、最終的な参照が ProGet サーバーから CI ボックス上に構築されるようにするにはどうすればよいですか?
誰でもこれを行う方法を教えてもらえますか?