web-dev-qa-db-ja.com

SVNブランチとデプロイメント環境でJenkinsを整理する

現在の設定

現在、約15の異なるJava Webアプリケーションのデプロイメントを自動化する1つのJenkinsサーバーがあります。各アプリケーションには、別々のLinuxボックス上に3つのデプロイメント環境があります。

  1. 開発
  2. テスト
  3. 製造

Jenkinsでは、すべてのアプリケーションに独自の「ビュー」があります。すべてのビューの中に、すべてのブランチの仕事があります。これらのジョブは単にwarファイルを作成し、それをJenkinsサーバーに配置します。次に、DevOps担当者をデプロイするには、特定のアプリケーションのデプロイメント環境（dev、test、prodにかかわらず）にSSHで接続し、Jenkinsサーバーからデプロイメント環境に（通常はTomcat webappsフォルダーに）warファイルを移動するSCPスクリプトを実行します。展開用）。

問題

明らかにこれは非常にばかげたプロセスです。実際にアプリケーションをデプロイするJenkinsデプロイメントプロセスが必要です（そのため、SSHでボックスにログインし、SCPスクリプトシェルスクリプトを実行する必要はありません）。小さなアプリケーションのいくつかでこのプロセスが機能しているのですが、2つの問題が発生しています。

  1. 仕事を整理する最善の方法がわかりません
  2. 一部の同僚は、これがプロダクションビルドを誤ってプッシュするのがいかに簡単かを心配しています。

さらに説明

問題＃1で-明らかな総当たりの方法は、各デプロイメント環境のジョブを作成することです。ただし、その場合、「デプロイメント環境のテスト」ジョブがデプロイしたいブランチをパラメーターとして取り込めるようにする方法がわかりません。新しいブランチごとに（デプロイメント環境ごとに1つ）3つのジョブを作成する必要はありません。さらに、すべてのブランチのジョブを作成できますが、展開環境をパラメーターとして送信する方法がわかりません。これらのジョブをビルドごとに再構成する必要はありません。これは、これまでに見つけた唯一の方法です。

問題＃2で-悪意のある本番デプロイメントから保護するために使用されるプラグインのタイプまたは一般的な戦略はありますか？この質問は、質問1に対する私の回答に大きく基づいているのではないかと思います。特にプロダクションビルド用に別のアカウントを持っていると、これを防ぐための効率的な方法ですか？

javadeploymentautomationjenkins
2
Chris Maggiulli

もう少し複雑ですが、はるかに柔軟なシステムに移行することをお勧めします。基本的に、環境にリンクされているSVNブランチから離れることをお勧めします。これを数年間使用しましたが、深刻な問題はありませんでした。

  • まだない場合は、Nexusなどのリポジトリ製品をインストールします。
  • 番号付きバージョンをNexusにデプロイするが、DEV、UAT、またはPRODホストにはデプロイしないJenkinsのデプロイメントジョブを記述します。このジョブは、すべてのファイルにバージョン番号のタグを付け、バージョン化された.warファイルをNexusに入れます。ビルドツールとしてMavenまたはGradleを使用していると仮定すると、これはJenkinsの標準機能です。
  • ユーザーにバージョン番号とターゲットホストを要求するJenkinsのデプロイメントジョブを記述します。これらは単に、Jenkinsが実行するbashスクリプトによって拡張されたSVNチェックアウトを使用するジョブです。生活を楽にするためにいくつかのJenkinsプラグインを追加する必要があります（たとえば、ジョブ全体に表示される変数を設定するSetenv）
  • DEVOPSを使用するための2番目のJenkinsインスタンスをインストールします。これにより、特定のバージョンを上位の環境にデプロイするジョブがホストされます。これは主に、開発者が一部の環境へのデプロイメントを許可されていない場合のセキュリティのためです。
  • SVNの使用方法が変わります。開発にはトランクを使用し、デプロイされたバージョンごとにブランチを使用しました。必要に応じてバージョンブランチを作成するだけです（タグからのブランチ）。また、通常、新しい機能を試すために、時々ブランチを作成します。
  • ホワイトボードを目立つ位置に置き、各環境に現在どのバージョンがあるかを示します。

それでこれはあなたに何を与えるでしょうか？

  • ブランチは環境にリンクされなくなったため、環境間を移動するときにコードをマージする必要はありません。
  • 環境を別のバージョンにすばやく後退させることができます。これは、あいまいなバグを追跡するのに最適です。
  • 欠陥レポートにはバージョン番号が含まれていると主張します。これにより、いつ欠陥が最初に検出されたかを追跡できます。

いくつかの釣り針があります。

  • 同じ.warファイルがどの環境でも実行できるようにコードを記述する必要があります。つまり、すべての構成データは、環境変数またはJNDI変数、あるいはその両方として保存する必要があります。個別に制御およびバージョン管理された構成ファイルを使用することもできます（通常はDEVOPSによって）。これらのファイルの実際の場所は、環境またはJNDI変数によって指定されます。
  • Jenkinsとターゲットデプロイメントマシンの間に証明書ベースの信頼をセットアップする必要があります。これは、SSHを使用してファイルをターゲットホストに移動し、ターゲットホストでコマンドを実行するために必要です。SSHは、スクリプトからのユーザー名/パスワード認証をサポートしていません。

これはあなたのチームにとってかなりの変更になるかもしれないと思いますので、頑張ってください！

2
kiwiron