問題タブ [incremental-build]

プロジェクトの Maven のような依存関係管理のための何らかのサポートを構築しようとしています。このために、ビルドスクリプトのクラスパス依存関係として継承したい pom を追加します。私は、ファイルを入力として受け取り、それを解析し、その pom からの依存関係をマップに入れるタスク「継承」を追加するプラグインを作成しました。タスクは、クラスパスから pom を取得するプラグインの apply メソッドで開始されます。

プラグインの適用メソッドで、タスクを追加し、それに依存するようにコンパイルします。

別の時点で、依存関係をループし、pom から取得したバージョンに従ってバージョンを変更します。

これはすべてうまくいくようです。しかし、compileJava は決して最新ではありません。常に再コンパイルする必要があります。私は何か間違ったことをしていますか、それともgradleはクラスパスファイルが変更されていないことを確認できませんか?

よろしく、アルネ

ビルド サーバーでコンパイル時間を改善する方法を探しているときに、インクリメンタル コンパイラによって追加されるオーバーヘッドに関するこの問題に遭遇しました。私たちのビルド サーバーはソースの新しいコピーをチェックアウトし、毎回ゼロからビルドするため、インクリメンタル コンパイラを完全に無効にして、使用しないものに料金を支払う必要がないようにすると便利です。これは可能ですか？

IDE を使用して Visual Studio 2012 で C++ プロジェクトを構築しています。プラットフォームが x64 に設定された Debug と Release の 2 つの構成があります。

プロジェクトで .cpp ファイルに触れ、デバッグ構成でビルドすると、その .cpp ファイルだけが .obj ファイルに再コンパイルされます。つまり、他の .cpp ファイルは再コンパイルされません。これは私が期待する動作です。

ただし、リリース構成では、.cpp ファイルに触れると、プロジェクト内のすべての .cpp ファイルが再度コンパイルされます。

関連のない .cpp ファイルを 1 つだけ変更した場合に、他の .cpp ファイルのコンパイルを停止するフラグまたは設定がリリース構成に表示されません。これを機能させるために変更する必要がある設定を誰かが知っていますか?

編集:申し訳ありませんが、リリース ビルドで [プロパティ] -> [全般] -> [プログラム全体の最適化] が [プログラム全体の最適化なし]に設定されておらず、ビルドごとにすべての .cpp ファイルが再コンパイルされていたことに気付きました。

ありがとう。

私は継続的インテグレーションの概念実証を行っており、開発チームが自動ビルドと自動デプロイによって人的エラーを削減できるかどうかを確認しています。私はすでにプロセスをかなり進めてきましたが、コード変更のない依存関係の再構築を回避するためにインクリメンタル ビルドを構成する方法についていくつか質問があります。さらに、配置ツールで、コード変更の結果として再構築されたアセンブリのみを識別して配置できるようにしたいと考えています。

ソース管理には TFS、開発には Visual Studio、継続的インテグレーション ビルドには Team Foundation Build などの Microsoft 製品を既に使用しています。現在、Team Foundation Build とうまく統合されているように見えるので、展開用に InRelease に傾いています。

しかし、まず、これが現在のセットアップです...

1. 200 以上の C# ソリューション ファイルがあり、それぞれに 1 つ以上のプロジェクトが含まれています。これらのプロジェクトをより少ないソリューションに結合することは、環境では実際的ではありません。つまり、設計によるものです。ソリューション内のプロジェクトは、プロジェクト参照を使用して依存関係を解決し、他のソリューション内のプロジェクトへのファイル参照を解決します。私の知る限り、これは大量のプロジェクトを扱う場合に Microsoft が推奨するアプローチです。

2. 「機能ごとのブランチ」戦略を使用します。たとえば、完了時に安定したメイン ブランチにマージされる並行機能ブランチでの分離された開発です。リリースの時期になると、リリースはメインから分岐され、ホットフィックスと展開のために分離されます。フィーチャー ブランチとメイン ブランチには、コード チェックインによってトリガーされる CI ビルドがあります。リリースは、ほとんどの場合、選択したリリース ブランチに対して InRelease から手動で実行するのが好きです。リリースは、統合/テスト、UAT を含むさまざまな環境を通じて展開され、最終的にすべてのクライアントに展開されます。分岐戦略の詳細はまだ具体化中ですが、それはまた別の機会に。

解決すべき現在の問題:

1.コードの変更がない依存関係の再構築を避ける...

新しい機能やパッチをクライアントに展開するときは、最小限のファイルをプッシュする必要があります。私たちの会社には非常に大規模な顧客ベース (数千の顧客) がいて、インターネット接続が遅い場合があるため、すべてのアセンブリ (200 以上) をすべての顧客に完全に展開することは選択肢ではありません。コードの変更が行われていない場合でも、変更されたプロジェクトのみを正しく再構築するだけでなく、すべての依存プロジェクトも再構築する増分ビルドを設定することで、問題を部分的に解決しました。これにより、変更されたアセンブリと依存関係の両方が新しいタイムスタンプを持つことになります。タイムスタンプの変更を使用して展開するアセンブリを特定すると、機能的に変更されていないアセンブリが展開されることになります。

例えば：

ソリューション B にはプロジェクト B というプロジェクトがあります ソリューション A にはプロジェクト A というプロジェクトがあります

プロジェクト B -> プロジェクト A (プロジェクト A はプロジェクト B にファイル依存関係があります)

プロジェクト A で破壊的でない変更が行われた場合、たとえばメソッドの内部に変更が加えられた場合、期待される結果は次のとおりです。A のみがビルドされ、展開の候補になります。プロジェクト Aで重大な変更が行われると、プロジェクト B が壊れます。期待される結果は次のとおりです。A と B の両方がビルドされ、展開の候補になります。現在、MSBuild は関係なくすべての依存関係を再構築しますが、これは私たちが望んでいるものではありません。

2. 展開する必要があるアセンブリを自動的に識別します...

問題の部分的な解決策があります。ビルドが実行されると、ビルド プロセス テンプレートは、特定の順序でビルドするソリューションのリストを含む MSBuild スクリプトを実行するように構成されます。この操作は、ビルド エージェントのワークスペースで実行されます。新しいビルドが実行されるたびに、ビルド プロセス テンプレートは、次の形式で一意のドロップ フォルダーを作成します。バイナリをビルド エージェント ワークスペースからドロップ フォルダーにコピーします。これは、標準のビルド プロセス テンプレートによって処理されるすぐに使える機能です。ビルドはビルド エージェント ワークスペースをクリアしないように構成されているため、最初に実行するとソリューション内のすべてのプロジェクトがビルドされますが、その後のビルドでは、コードが変更されているか、他のプロジェクトに依存しているプロジェクト (インクリメンタル ビルド?) のみがビルドされます。したがって、変更されていないアセンブリには元のタイム スタンプが付けられ、変更されたアセンブリには新しいタイム スタンプが付けられます。ドロップ フォルダー間のフォルダー比較を実行し、結果を txt ファイルに出力できるツールがあります。これにより、最後の展開以降に追加/変更/削除されたバイナリを特定できます。また、実際のアーティファクトのリストを、開発者が定義した予期されるアーティファクトのマニフェストと比較できるという追加の利点も得られます。これにより、指定されておらず、単体テスト済みであることが証明されていないアセンブリがデプロイされないようになります。

問題は、ドロップ フォルダー内のすべてのファイルではなく、上記の例のように必要なファイルのみを展開するために、InRelease をどのように活用できるかということです。

私は gradle を使用しており、jenkins でインクリメンタル ビルドを実行したいと考えています。どのように進めればよいかわかりません。適切なドキュメントや適切な進め方を教えてください。

どうもありがとう

Windows Phone 8 テンプレートを使用して 1 つの Windows Phone プロジェクトを作成しました。

初めてデバイスにデプロイすると、VS 出力ウィンドウに次のログが表示されます。

• デバイスに接続中...
• デバイスの最適化中...
• アプリケーションをインストールしています...
• インストールされたファイルに関連する情報を更新しています...

これはうまくいきます。今、私はアプリのローカル db (sqlite データベース) でいくつかのデータを更新しています。再びソリューションをクリーンアップし、VS 出力ウィンドウに次のログが表示されているアプリを再構築します。

• デバイスに接続中...
• デバイスの最適化中...
• アプリケーションはすでにデバイスにインストールされています。増分展開が可能かどうかを確認しています...
• プロジェクトがクリーンアップされ、再構築されたため、完全な展開を行っています...
• アプリケーションをアンインストールしています...
• アプリケーションをインストールしています...
• インストールされたファイルに関連する情報を更新しています...

この最近のインストールは、既存のアプリ データ (sqlite db データ) を上書きしますが、「アプリケーションをアンインストールしています... 」はしたくありません。私はアプリを更新しただけです。 更新前にアプリをアンインストールしたくありません。

何が問題だったのか教えてください。いくつかの更新で新しいアプリを更新しながら、既存のデータ データベースとローカル キャッシュを維持するにはどうすればよいですか。

Visual Studio 2013、プロジェクト タイプ: Windows Phone、テンプレート: Windows Phone アプリを使用しています。

ヘルプ/提案/コメントをいただければ幸いです。

ありがとう、

sbt 13.5 を使用してビルドする scala プロジェクトがあります。

shapeless を使用してモジュールを実装したので、sbt がプロジェクトをインクリメンタルにコンパイルしようとするたびに、必要な暗黙の解決に失敗します。

[...] パラメータマッパーの暗黙的な値が見つかりませんでした [...]

[...] パラメータ フォルダの暗黙的な値が見つかりませんでした [...]

等々。

sbt clean問題は解決しsbt compileますが、プロジェクトはかなり大きく、新しいビルドには数分かかることがあるため、コンパイル時間と生産性が大幅に低下しています。

ここで何が起こっているのか分かりますか?

追加情報

というわけで、いろいろ考えた結果、仮説を立ててみました。この問題は shapeless レコードを使用している場合に発生し、生成されたファイルを見ると、レコード キーごとにシングルトン タイプを生成するマクロに問題がある可能性があると思います。

私のモジュールは次のようHListにColParser[T, K]宣言されています:

そのため、コンパイラはマクロを使用してWitnessfor eachを生成しColParser、何を再コンパイルするかを決定する際に sbt が生成されたマクロを追跡できなくなるのではないかと心配していますが、これは大ざっぱな仮説にすぎません。

実際のところ、モジュールを呼び出すコードで何かを変更するたびに (たとえば、 に a を追加/削除するColParser) HList、上記のエラーが発生します。モジュールの再コンパイルを強制すると (生成された を削除することにより.class)、問題が修正されます。

おそらく200以上のプロジェクトを含むプロジェクトがあります。老鳥です。ローカル ビルドを高速化するために、診断ビルドを実行しました。アセンブリとプロジェクトの参照を解決するには、msbuild に時間がかかるようです。VSはこれを高速に実行しているようですが、MSBuildでこれらの参照にキャッシュを使用する方法、または何らかの方法でより高速に解決する方法はありますか?

MSBuild は、インクリメンタル ビルドでこれほど頻繁にアセンブリ参照を解決する必要はないようですよね？

MSBuild に内部依存関係ツリーを報告させる方法はありますか?

Jenkins と git のセットアップでは、マスターは Windows で、スレーブは Linux です。(今後数か月のうちに、Linux all に変更される予定です)。

ジョブで Poll SCM を設定すると、ジョブが実行されるように構成されているスレーブではなく、マスターでポーリング アクションが実行されます。とにかく..サーバー構成に問題があり、そこでgitを実行できず、SSHを介して別のマシンのリポジトリに到達できません。

net、サーバーが修正されるまで、poll scm を使用できません。

ただし、追加のテストのためにアプリケーションを自動デプロイするために使用されるアーティファクトをビルドするため、変更があるたびに実行する必要があるビルド ジョブがあります。Build Regularly を使用できますが、30 分ごと (例として)、毎晩、週末にビルドされ、ほとんどの場合、これは時間の無駄です。

そのため、前回から変更があるかどうかを確認するために何かをチェックする、時間指定されたジョブを作成したいと思います。ビルドは、特定のブランチのコンテンツに対してのみ発生します。

rev-list を使用して最後のコミットを取得できると「思います」が、特定のブランチでのコミットのみが必要です。次に、これをファイルに保存して、この副業の次の作業を再確認できます。

リビジョンが一致しない場合は、他のジョブをトリガーします。

誰にもより良いガイダンスがありますか？