問題タブ [continuous-delivery]

複数のコアで node.js アプリを実行するためにnaught ( https://github.com/andrewrk/naught ) を使用していますが、1 台のマシンだけでゼロ ダウンタイムのデプロイができるものもありません。

スーパーテスト( https://github.com/visionmedia/supertest ) を使用して、個々のノードを起動する前にテストします。基本的な統合テストでは、そのノードにプールへの「OK」を与えます (その前に、ノードは process.send('online')) を実行できます。

スーパーテスト テストが個々のノードの一部である場合、それ自体で要求と応答のサイクルを閉じるか (良い)、それともプール全体に http 要求を送信するだけか (悪い) ?

そうでない場合 - これを行う他の方法はありますか?

ありがとう ！！！

ビルド パイプライン プラグインを使用して、Jenkins で継続的デリバリー パイプラインを設定しています。

デプロイ手順では独自のデプロイ ツール (jenkins からの HTTP リクエストによってトリガーされる) を使用しますが、デプロイされたプロジェクトで受け入れテストを行うには、追加の Jenkins ステップが必要です。したがって、デプロイ ツールは最後のパイプライン ステップをトリガーする必要があります。

このためのジェンキンスの設定は明らかです：

手動トリガー ダウンストリーム ビルド ステップの場合: 手動トリガーを待機するビルド ステップを追加するには:

• Build Pipeline Plugin を選択し、Manually Execute Downstream Project チェックボックスをオンにします。
• [ダウンストリーム プロジェクト名] フィールドにダウンストリーム プロジェクトの名前を入力します。(nb "abc, def" のように、カンマを使用して複数のプロジェクトを指定できます。)

ソース: Build Pipeline Plugin

問題は、URL を介してこのダウンストリーム ビルドをトリガーする方法が見つからないようです。

実際、デプロイ ジョブには URL が必要なので、それをコールバック URL としてデプロイ ツールに送信できます。誰でも助けることができますか？

オープンソース アプリケーションの継続的デリバリー サイクルを設定したいと考えています。Linux の Filesystem in Userspace (FUSE) に基づいています。CloudBees の Jenkinsにセットアップしようとしましたが、これはまともな無料アカウントを提供していましたが、ルート アクセス権がありませんでした。私のプロジェクトには多くの依存関係があるため、これは問題です。依存関係をインストールするためのルート アクセス権があるため、内部 API のテストに最適なTravis CIを使用しました。ただし、FUSE はサポートしていないため、ファイルシステムで直接テストを実行することはできません。Travis CI での私の経験によると、継続的デリバリー アプローチは、多くのバグがリリースされるのを防ぎ、問題をより迅速に特定するのに役立つ可能性があります。

Github と統合し、root アクセスを許可し、FUSE をサポートする、Travis CI に似たサービスはありますか?

[編集]
ヴィ。FUSE をエミュレートするために、Travis-ci マシンで User Mode Linux を実行することをお勧めします。Vi.s ヘルプで達成された進歩を要約すると、次のようになります。

1. より多くのメモリ、ネットワーク アクセス、およびファイル システムへのアクセスを使用して UML をセットアップするには、次のコマンドを実行します。

   /li>

ユーザー スクリプト内で、次のように呼び出します。

2. gcc を使用する場合は、PATH 変数を設定します。

   /li>

3. procfs が必要な場合は、UML 内でこれを実行します。

   /li>

4. Python の場合、UML 内で仮想環境を有効にする必要があります。

   /li>

へのパスはactivate、UML を開始する前に次のコマンドを発行することによって見つけることができます。

それでも FUSE を実行できません:

要するに：

個人開発者にとっての CI の利点の観察 個人開発者にとって継続的インテグレーションは重要ですか?

ソロ開発者に適した CI サーバーはありますか?

これらは通常、大量の RAM を消費し、サーバー エージェント ベースです。

-軽量（RAM） -シンプル -GitHubと互換性がある

引用していただけますか？

多くのソフトウェア企業は、新しい機能を製品に迅速に段階的にリリースしていると自慢しています。大企業 X での私のバックエンド プロジェクトでは、大きなリリース (四半期に 1 回のリリース) があります。スクラムを使用して、2 週間のスプリントとシステム統合テストを、隣接するチームとクライアントの間で、本番環境にリリースする前の最終段階として行います (独自のテスト パックがあります)。私たちのチームは、バックエンド サービス (それぞれのテストのパック) に対してのみ、夜間の回帰テストとの継続的な統合を使用しています。また、Jira、git、nexus、コード レビュー用の stash、spock、junit、teamcity などの最新のアジャイル ツールも使用しています。

チームが忙しいため、チーム間で頻繁に統合テストを行う余裕はありません。QA 開発者によって記述された回帰テストには、最大で 10 時間かかります (テラビュートのデータを含むデータベースに対してチェックされる多くの機能があります)。私たちのすべてのバックエンド サービスは、何百もの消費者がいて 24 時間 365 日働くビジネスの観点から重要です。本番環境に移行するには、すべての消費者も統合テストを実行する必要があります。これには多くの調整と時間が必要です。私たちは常に週末の非稼働時間にリリースします。

したがって、迅速なリリースは非常にリスクが高く、時間がかかります。サクセスストーリーとクイックリリースを達成する方法を知りたいですか? これは本当に実行可能ですか？

コミュニティが改善できるように、オープンソースにしたい Web サイト (Ruby on Rails アプリケーション) を作成しました。ソース コードは、GitHub で既に公開されています。ただし、プル リクエストを受け入れると、コードが自動的に運用環境にデプロイされるようにサーバーをセットアップしたいと考えています。

そのようなことを考えたのは私が初めてだとは思えないので、これを処理するためのツールが既に存在している可能性があります。現在、Capistrano を使用してアプリケーションをデプロイしています。この種の動作を追加できるプラグインがあるかもしれません。また、現在サーバー上にのみ存在する本番 API キーの公開も避けたいと考えています。

ツール/プラグインがまだ存在しない場合、このタイプの動作を実装するにはどうすればよいですか?

Puppet 用に 2 つの異なるモジュールをコーディングしました。1 つは Tomcat7 がインストールされて実行されていることを確認するモジュールで、もう 1 つは Web アプリケーションを Tomcat webapps フォルダーにデプロイするモジュールです。

ただし、これら 2 つのモジュールを使用して puppet をデーモンとして実行すると、puppetmaster と puppet が同期するたびにアプリケーションがデプロイされるため、次のようにする必要があると思います。

1. そのようなノードによって実行されるマニフェストのリストに tomcat モジュールを追加します。このようにして、Tomcat が 30 分ごとに稼働していることを確認します。

その後：

A. 以下のコマンドを使用して puppet エージェントでノーデーモン化ワンタイム タスクを呼び出し、タグを使用してデプロイ アプリケーション モジュールのみを実行するように指定します。

puppet エージェント --server MYSERVER --no-daemonize --onetime --tags deploy_app

B. 何らかの方法でデプロイ アプリケーション モジュールを変更します。たとえば、artifact でアプリケーションのバージョンを指定して、puppet エージェントを呼び出す代わりに puppetmaster から自動的にデプロイするようにします。

正しいアプローチは何ですか？この種のタスクを Puppet で実行するために、企業は通常何をしていますか?

puppetmaster からデプロイする場合、アプリケーションがいつ正確にデプロイされたかを知るのは難しいと思います。そのため、デプロイ プロセスを制御できなくなります。これは良くないと思います。