8

CIにはjenkinsを使用しています。深夜のビルドを取得します。メールまたは通知を受け取ったらすぐにビルドのデプロイを自動化する方法はありますか?任意の提案をいただければ幸いです。

4

3 に答える 3

3

Jenkinsのビルドからデプロイするメカニズムの1つは、アーティファクトを使用して最新のバイナリを既知の場所に配置し、(秘密鍵で保護された)sshを使用する新しいジョブ(コンパイル/テストフェーズの成功時のみ)を開始することです。またはscpを使用してアーティファクトをテスト/本番マシンにコピーしてから、インストールを実行します。

私たちが行ういくつかの自動テストにも同様のメカニズムを使用しています。トリッキーな部分は、sshキーを処理するためのシェルコマンドを取得することです。そのため、次のようにします。

eval `ssh-agent -s`
ssh-add ~/.ssh/your_private_key_here

その秘密鍵がJenkinsサーバー上にあり、公開鍵がプッシュしようとしているサーバー上にある限り、スクリプトの残りの部分でコマンドを使用sshして、問題のサーバーで機能を実行できます。scp

ターゲットサーバー側からプロセスを完全に実行する場合は、サーバー上で実行される小さなスクリプトを作成して、Jenkinsサーバービルドのアーティファクトディレクトリ内の新しいファイルをチェックできます。パスのおかげで、latestこれを行うためにビルド番号を知る必要はありません。特定のパスを見つけるには、Jenkinsサーバーにログインして(少なくとも1つのアーティファクトを保存したら)、使用しているプロジェクトを見つけて、最後に成功したアーティファクトを確認します。これは、最後に成功したビルドへのURLになります。アーティファクトの。これらのURLは一定のままであり、常に最新の成功したビルドを指しているため、プロジェクト名またはサーバー名が変更されない限り、URLが変更されることを心配する必要はありません。

:ここには、テストする展開以外の目的でこれを行う場合にトラックを運転できるセキュリティホールがあります。最初のメカニズムの場合、ビルドサーバーにはssh、ターゲットへのアクセス(潜在的に破壊的)を与えるキーがあります。2番目のメカニズムの場合、Jenkinsサーバーが自分に適したバイナリのみを提供することを信頼しています。ただし、テスト環境、ステージへのプッシュなどの場合、これらの手法はうまく機能します。

于 2013-03-18T12:27:49.657 に答える