デプロイスクリプトはビルドのアーティファクトにする必要がありますか？
これはJavaで書かれたWebプロジェクトです。
だから、私はビルドとデプロイスクリプトを書いています。ビルドを作成するために、私はアリを使用しました。継続的なビルドはJenkinsで行われます。
ビルドは3つの異なる成果物を生成します。
- 戦争ファイル
- レイアウト付きZip
- 画像付きZip
これまでのところ、とても良いですが、今度はデプロイスクリプトを記述する必要があります。
- War（アーティファクト1）をserver 1で実行されているTomcatにデプロイします。
- アーティファクト2をserver 1に特定のディレクトリに配置します
- アーティファクトをserver 2に特定のディレクトリに配置します
だから私は同僚と話していて、正しい場所に配置されたときにこれらのアーティファクトをデプロイするアーティファクト（多分deploy.xml）も生成する必要があると彼は言ったサーバ。
したがって、次のような別のスクリプトがあります。
- ジェンキンスアーティファクトをダウンロードする
- 各サーバーにscpし、deploy.xmlをそこに配置します。
- リモートでdeploy.xmlを呼び出す
私に少し不快なのは、deploy.xmlをビルドアーティファクトとして持つことです。これの背後にある動機は、VCSリポジトリへのアクセス権を必要とせずにデプロイを実行できるようにすることです。そのため、ビルドは自己完結型になります。
配置スクリプトはどこに配置する必要がありますか？ VCSでonlyにする必要がありますか、それともビルドアーティファクトにする必要がありますか？
私の経験では、canを自動化できるものはすべてそうあるべきです。 step 1、step 2、....と記述できる場合は、スクリプトにする必要があります。ビルド固有の情報（リビジョンタグなど）を含めるようにスクリプトを自動生成できる場合は、それを行う必要があります。これは怠惰であるためではなく、predictableおよびreproducibleであるためです。
注意してください：自動生成されたデプロイスクリプトがおかしくなり、運用サーバーにホースを送った場合に、チームの誰でも使用できる自動生成revertスクリプトも必要です。
ピーター・ローウェルが書いたことはすべて正しいです。
デプロイスクリプトファイルの場合
- 誰かが書いた場合は、バージョン管理が必要です。
- それが生成され、再び生成できる場合、通常はバージョン管理に移行しません。
デプロイプロセスの場合：
- アーティファクトを自己完結させて簡単に作成できる場合、ファイルはビルドアーティファクトである可能性があります。つまり、ファイルはビルド結果とともにパッケージ化されており、展開に使用できるようになっています。
- 一方、デプロイメントはますます複雑になるため、遅かれ早かれ、デプロイメントを実行する専用プログラム（コードを読み取る）が必要になり、Jenkinsビルドアーティファクトはもはや自己完結型ではなくなります。
これは、プロセスと、デプロイメントの処理方法によって異なります。