問題タブ [automated-deploy]

NCrunch を TeamCity と統合するためのリソースやガイドを知っている人はいますか? 私の会社は、自動化の研究開発への投資を開始したばかりです。私は NCrunch を使用して自動テスト スイートの作成に取り組んでいますが、別の開発者は自動ビルドのデプロイ/テストと TeamCity の統合に取り組んでいます。

現在、ローカルで実行しているテストのみを実行していますが、NCrunch グリッドをセットアップし、最終的にこれを TeamCity と統合して、テストが定期的に、または新しいビルド時に実行されるようにしたいと考えています。

自動化されたビルド/タスクは私にとって新しいものであるため、これらすべてが概念的にどのように連携するかについて考えたいと思います。私はいくつかのグーグル検索を試みましたが、つなぎ合わせるのが難しいと感じています。

ビルドが行われる TeamCity 上のエージェントからローカル マシンに .exe と .varfile をコピーする必要がある製品の展開プロセスを自動化するために取り組んでいます。maven pomでスクリプトを記述して実行しようとしています。.xml。最初に localhost に接続し、ポートを定義することが組み込まれることを私は知っていますが、多くの試行の後、私はそれをうまく行うことができませんでした。初心者なので不明な点がありましたらコメントお願いします。

docker-compose を使用してリモート ホストにデプロイしています。これは私の設定がどのように見えるかです：

私は以下を使用して展開します：

これはローカルで完全に機能し、過去にこの方法でデプロイを成功させましたが、「web_server」サービスを構築するときにハングし、最終的にこの問題で説明するようにタイムアウト エラーが表示されます。

この問題は、接続が遅い (アルゼンチン -> 米国の DigitalOcean サーバー) ことと、ハブでホストされているイメージを使用する代わりにイメージを作成してプッシュしようとしていることが原因であると思います。

構成設定をサーバーに複製し、docker-composeそこで直接実行することで、展開を行うことができました。

問題は、このプロセスを自動化するより良い方法はないかということです。その場でイメージを構築するために docker-compose を使用することをお勧めしますか?

ソースをサーバーに複製して何かを実行するこのプロセスを自動化することを考えていましたがdocker-compose、この問題を解決するためのより良いツールがあるかもしれません。

github 組織の制限に達したことを除いて、会社の Azure Web アプリの自動デプロイをセットアップしています。私の知る限り、制限は 20 で、github には 20 個の Webhook があります。この制限を克服することについてのドキュメントには何も見つからないので、私の質問は次のとおりです。

a) 誰もこれに直面したことがありますか? b) 制限を増やしたり、削除したりする方法はありますか?

ありがとう！

継続的インテグレーション (CI) 環境にビルドしてデプロイし、開発、ステージング、ライブに自動デプロイするビルド サーバーがあります - すべて TFS ビルド定義を使用します。

ビルド サーバーでは、Dust でダウンロードしたユーティリティ (dustc) を使用して、(デプロイ手順の前に) Dust テンプレートをコンパイルする必要があります。Visual Studio 内でローカルに実行すると、Visual Studio (VS) がフォルダー node_modules に開始されると、Dust がダウンロードされますが、このフォルダーは通常チェックインされません (そうしないと、多数のクライアント側ライブラリとバージョンがすぐに管理オーバーヘッドになります)。

Dust は npm 経由でダウンロードされます (私は v3.5.2 を使用しています)。私が理解しているように、npm を使用してダウンロードするモジュールをダウンロードする標準的な方法は次のとおりです。

• ローカルに (VS 内で) NuGet 経由で npm をダウンロードします。これにより、プロジェクトに含まれてチェックインされた npm.cmd を含むプロジェクト (".bin") のルートにフォルダーが作成されます。
• 次に、ソリューション/プロジェクトの成果物がダウンロードされた後のビルド サーバーで、NuGet パッケージがダウンロードされます (npm を含む)。

• 最後に、次のコマンドを送信します (この場合、VS ビルド後のタスクに含まれていますが、NuGet パッケージがダウンロードされた後であれば、すべて問題ありません)。

  /li>

最終結果は、Dust がプロジェクト構造 (node_modules フォルダー内) にダウンロードされ、Dust テンプレートをコンパイルするコマンドを発行できるようになるはずです。

ただし、問題は npm が NuGet 経由でダウンロードされた場合、npm フォルダー構造が大量にネストされているため、Windows パスの 260 文字の制限を超えていることです ( https://github.com/nodejs/node-v0.x-archive/issues/6960 ) - その結果、ジョブが npm を実行して Dust をダウンロードする前に、ビルドが失敗します (注: TFS フォルダーの長さを短くしましたが、npm はビルド名、プロジェクトなどを分割する余地がほとんどありません。たとえば、 .../packages/Npm.3.5.2/node_modules/npm/node_modules/npm-install-checks/node_modules/npmlog/node_modules/are-we-there-yet/node_modules/readable-stream/node_modules/core-util -is/lib は約 170 文字です)

Node npm windows file paths are too long to install packagesを読んだことがありますが、verion 3.x の使用、または npm-flatten/dedupe の使用を示唆していますが、まだ問題があります - 主に失敗するのは NuGet ステップであるためです - npmで何でもできるようになる前に

解決策は、必要なファイルのみを選択することです (つまり、npm から、またはおそらくより簡単な [しかし柔軟性が劣る] ダスト ファイル [dustc など] のみ) をソース管理に含め、NuGet には npm を含めません。しかし、これは厄介です。チェックインしたファイルが更新された場合 (よくあることですが)、すべてがそのままで実行されていることを確認する必要があります。

よりクリーンな方法はありますか？