デプロイスクリプトはビルドのアーティファクトである必要がありますか？

これはJavaで書かれたWebプロジェクトです。

それで、ビルドとデプロイのスクリプトを書いています。ビルドを作成するために、antを使用しました。継続的なビルドはJenkinsで行われます。

ビルドは3つの異なる成果物を生成します。

1. 戦争ファイル
2. レイアウト付きのzip
3. 画像を含むzip

これまでのところ、これでいいのですが、今度はdeployスクリプトを記述する必要があります。

• サーバー1で実行されているTomcatに戦争（アーティファクト1）をデプロイします
• サーバー1のアーティファクト2を特定のディレクトリに配置します
• サーバー2のアーティファクト3を特定のディレクトリに配置します

そこで同僚と話していて、正しいサーバーに配置したときにこれらのアーティファクトをデプロイするアーティファクト（多分deploy.xml）も生成する必要があると彼は言いました。

したがって、別のスクリプトがあります。

• ジェンキンスのアーティファクトをダウンロードする
• 各サーバーにscpし、そこにdeploy.xmlを配置します
• deploy.xmlをリモートで呼び出す

私を少し不快にしているのは、build.xmlをビルドアーティファクトとして持つ行為です。この背後にある動機は、VCSリポジトリにアクセスする必要なしにデプロイできるため、ビルドは自己完結型になります。つまり、すべてのビルドはJenkinsによって生成されたものでのみ本番稼働できます。

配置スクリプトはどこに配置する必要がありますか？それらはVCSにのみあるべきですか、それともビルドアーティファクトであるべきですか？

私の経験では、自動化できるものはすべてあるべきです。ステップ1、ステップ2、...と説明できる場合は、スクリプトにする必要があります。ビルド固有の情報（リビジョンタグなど）を含めるようにスクリプトを自動生成できる場合は、それを行う必要があります。これは怠け者のためではなく、予測可能かつ再現可能にするためです。

注意してください：自動生成された展開スクリプトが狂ってしまい、本番サーバーにホースをかけた場合にチームの誰でも使用できる自動生成された復帰スクリプトも必要です。

ピーター・ロウェルが書いたすべては正しいです、さらに私はそうします：

展開スクリプトファイルの場合

• 誰かが作成した場合は、バージョン管理する必要があります。
• 生成され、再度生成できる場合、通常はバージョン管理に入れられません。

展開プロセスの場合：

• アーティファクトが自己完結型であり、簡単に実行できる場合、ファイルはビルドアーティファクトになる可能性があります。つまり、ファイルはビルド結果と一緒にパッケージ化され、展開に使用できるようになります。
• 一方、展開はますます複雑になるため、遅かれ早かれ展開を行う専用プログラム（コードを読む）が必要になり、Jenkinsビルドアーティファクトは自己完結型ではなくなります。

これはむしろ、プロセスと展開の処理方法に依存します。