0

現在、C# (Sharepoint 上に構築) プロジェクトを実行しており、配信を支援する一連の自動化プロセスを実装しています。詳細は次のとおりです。

  1. 継続的統合。DEV 環境で頻繁にコンパイルおよび展開するための典型的な CI システム。
  2. 部分的なパッケージ。毎週、修正を伴う欠陥のリストが特定され、対応するアセンブリが完全なパッケージから取得されて、部分的なパッケージが形成されます。部分パッケージは、後続の環境で展開およびテストされます。

このパイプラインでは、2 つのパッケージが検証されています。部分的なパッケージ用の新しいシステム (Web サイト、スクリプト、プロセスなど) を構築するには、余分な労力が必要です。しかし、いくつかの要因がその改善を妨げています。

  1. ビルドとデプロイの時間が長すぎます。開発者のマシンでは、アセンブリに変更を加えるたびに、IIS での再展開に約 5 ～ 10 分かかります。さらに、ソリューション全体を再構築するには 15 分 (またはそれ以上) かかります。(この企画の一番の痛手)
  2. 地理的な違い。最終的なパッケージはすべて別のオフィスに配送されるため、手作業は避けられず、パッケージのサイズは小さいことが好まれます。

継続的デリバリーの実践を推進するために、ご意見をお聞かせいただければ幸いです。ありがとう！

4

2 に答える 2

0

この質問に答えがないのは、その範囲が広すぎるためだと思います。排除しなければならない変数が多すぎますが、私は助けようとします。あなたのスキルレベルもわからないので、基本的なことを前もってお詫びしますが、それらはあなたの質問を改善し、より焦点を合わせるのに役立つと思います.

問題の範囲をできるだけ狭くする

「長すぎる」は非常に主観的な用語です。ビルド時間を 15 分にしたい大規模なプロジェクトをいくつか知っています。あなたの質問を考えると、構成の問題またはインフラストラクチャの問題が発生しているかどうかを知る方法はありません。構成の問題の例としては、/m スイッチを並列にビルドすることで、プロジェクトが複数のコアを最大限に活用していますか? インフラストラクチャの問題の例としては、効果のないハードウェアまたは欠陥のあるハードウェアを使用して低速の回線で大量のデータを移動しようとしている場合があります。異なるマシンで同じ時間が表示されているように聞こえるので、構成に集中することをお勧めします。

ビルドを「タスク」に分割し、各タスクを可能な限り簡潔なステップに分割します

これは、構成を調整し、より適切に調整するために何が必要かを理解するのに最も役立ちます。CI サーバーを使用してソリューションを構築している場合は、msbuild.exe OurProduct.sln などのコマンドを使用して実行している可能性があります。これは、何かをすばやく起動して実行するための正しい方法であるため、フィードバックがあります。ただし、最適化するには、このソリューションを独立したプロジェクトに分割する必要があります。タイム シンクの大部分を引き起こしている 1 つのプロジェクトが見つかった場合、それは他の問題を示しているか、他のすべてが依存しているコア プロジェクトである可能性があります。ビルド ジョブの依存関係を処理する方法は、CI サーバーとソリューションによって異なります。このようにすると、より多くのオーケストレーションが作成されますが、変更があったプロジェクトのみをビルドしているため、それが必要な場合はより迅速なフィードバックが得られます。

「地理的な違い」についてあなたが何を意味しているのかわかりません。これはオフィスへの「プッシュ」ですか、それともオフィスからの「プル」ですか? これはまったく別の質問です。そこにファイルをどのように取得していますか？そして、なぜそれが手動のステップを必要とするのでしょうか?

範囲を狭めて複数の質問をすると、おそらくより良い (より短く簡潔な) 回答が得られるでしょう。

一番！

于 2013-10-01T18:18:04.453 に答える