問題タブ [continuous-delivery]

私のファブリック スクリプトには、次の問題があります。autodeploy と呼ばれる主なタスクがあります。このタスク内には、ローカルで一度だけ実行したいタスクがいくつかあります。すべてのリモート タスクは、ホスト リストの各ホストで実行する必要があります。

呼び出しは以下です。ロールを属性として渡したい。

Jenkins、Artifactory、3つの環境（開発、テスト、本番）があります。

開発者が開発環境から何かをコミットすると、それはテスト環境でコンパイルおよびテストされます。そして、そのビルドとアーティファクトはArtifactoryに保存されます。

次のステップに進み、puppetを使用して環境を管理し、Artifactoryから本番環境にアーティファクトをデプロイします。

しかし、始めるにはいくつかのヒントが必要です。

1. 人形を設置するのに最適な場所はどこですか？彼らが一緒に働くのと同じサーバー上でアーティファクトと同じですか？Puppetは環境も構成します。したがって、考慮しなければならないことがあるかどうかはわかりません。

2. puppetのインストール前またはインストール中に覚えておく必要のある構成はありますか？特にアーティファクトとジェンキンスのコンテキストで。

ヒント/ヘルプをありがとう。

クラウド ベースのソリューションを想像してみてください。デプロイされたコードのかなりの部分が社内で開発されています。私の質問は、いつでもソース コードから直接任意のバージョンをビルドできる内部コードにアーティファクト リポジトリを使用するポイントは何ですか?

つまり、Nexus のようなアーティファクト リポジトリを追加してビルド アーティファクトをデプロイメントにフィードするよりも、コードから目的のアーティファクト バージョンを簡単にビルドできるように、ビルド サーバーに時間を費やす方が理にかなっているのではないでしょうか?

開発者環境でwarパッケージをテスト、コンパイル、ビルドするプロジェクトがあります。今、私はこのパッケージをテスト環境で必要としています。このパッケージには他の構成が必要です。同じことが後で生産環境にも当てはまります。

だから私の質問：

他の構成でプロジェクトを再度コンパイルしてビルドする必要がありますか？

または、.warファイル内の構成ファイルを変更することはできますか？

「1回だけビルドする」という継続的デリバリーのコンテキストでこれを達成しようとしていますが、私が知っている/読んでいるように、.warパッケージのファイルを変更することはできません。したがって、ビルドを2回行わずにこれを解決する方法を少し混乱させます。

助けてくれてありがとう

本番環境への自動デプロイがpuppetでどのように機能するか知りたいです。

本番サーバーにパペットスレーブが必要ですか？その場合、それは安全ではなく、人形はそれでどのような権利を取得しますか？

ユースケースは、リポジトリマネージャからパッケージを取得し、それを本番サーバーにデプロイすることです。人形を使ったこの方法の主なステップは何ですか？

テストサーバーと本番環境へのデプロイを自動化しようとしています。

ci-server（ビルド、コンパイル、junit）とアーティファクトリポジトリマネージャー（デプロイ/公開するビルドを保存する）があります。

現在、スクリプトを使用してテストサーバー（ci-serverで実行）にデプロイできます。現在、ロールバック、db-backups、またはdb-updatesはありません。すべてのサーバーにSuse（Linux）があります。

ロールバック機能を使用して、展開するためのより良い方法があるかどうかを知りたいですか？多分他のフリーウェアツール？そうでなければ、いくつかのメモでさえ、ロールバックを作成してプロダクションを台無しにしないために私がしなければならないことを理解するのに役立ちます。

SVN、Jenkins、Maven を使用したデプロイ パイプラインを考えています。現時点では、通常はmvn release:perform作業コピーを呼び出すところに行き詰まっています。

展開パイプラインを考えるとき、すべてのコミットを使用してソフトウェアをテスト/本番環境にリリースできるパイプラインを作成したいと考えています。5 つのビルドがあり、ビルド 3 (リビジョン 3) を本番環境にリリースすることにしたとします。トランクにはすでに 2 つの新しいコミットがあります(現在はリビジョン 5 です)。

を使用しmaven-release-pluginてリビジョン 3 のリリースをチェックアウト/ビルド/タグ付け/コミットすることはできますか? maven-release-plugin がリリースを完了すると、通常、変更された POM がtrunkにコミットされます。

ここであらゆる種類の情報やアドバイスを喜んで提供しますので、お気軽に書籍を紹介してください ( http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912など)。ブログの投稿、Jenkins のドキュメント... 多分私は完全に間違った方向に進んでいます。

Acceptance Test Driven Development (ATDD) に関する質問があります。プロセスに従って、すべての機能を受け入れテスト (エンド ツー エンド テスト) から開始します。これらのテストをコミットしましたが、期待どおりに失敗しています。問題は、機能が完全ではないために失敗している受け入れテストと、なんらかのリグレッションのために失敗している受け入れテストをどうにかして区別する必要があることです。ATDD を使用して CI プロセスを編成するためのベスト プラクティスは何ですか?

バックグラウンド：

Production毎晩成果物を作成するためのJenkinsの仕事（）が1つあります。ProductionPush翌日、プロプライエタリプロトコルを介して成果物を本番マシンにプッシュする別の仕事（ ）があります。これは、一部の実稼働マシンが1日の特定の時間にのみ使用可能であるためです（これにより、土壇場でのビルドの中断を修正する機会も得られます）。 ジョブProductionPushによって作成された成果物にアクセスする必要があります（したがって、同じワークスペースにアクセスする必要があります）。Production複数のノードと同時ビルド（したがって予測できないワークスペース）があり、リソースがいくらか制限されているため、ジョブを固定ノード/ワークスペースに結び付けないことを好みます。

質問：

1. 両方のジョブが同じワークスペースを共有し、成功ProductionPushした場合にのみ翌日の決まった時間Productionに実行されるようにするには、両方のジョブを同じノード/ワークスペースで実行するように修正する必要はありませんか？パラメータ化されたトリガープラグインがこれの一部に役立つ可能性があることは知っていますが、時間遅延機能がないようで、12時間は静かな期間には長すぎるようです。

2. ワークスペースを共有するのは悪い考えですか？

相互に依存するいくつかのプロジェクトの展開パイプラインを構築しています。各ビルドは、Maven リポジトリにデプロイされる一意のバージョン番号を持つ新しいリリース ビルドを生成します。パイプラインの下流プロジェクトは、その新しいバージョンを依存関係としてトリガーされ、同様の方法でビルドされます。

プロジェクトをビルドする前に、pom.xml (またはマルチ モジュール プロジェクト内のすべての pom) のプロパティ値を変更する必要があります。たとえば、次のコードでは、「0.1.200」が「0.1.345」(または最新のビルド番号) に変更されます。更新された pom は Maven リポジトリにデプロイされるため、システム プロパティを使用することはできません。したがって、変更は永続的でなければなりません。

1 つのコマンド ライン命令でこれを行うための Maven プラグインはありますか? それ以外の場合は、プロジェクト内のすべての pom.xml ファイルを解析して変更する短いスクリプト (Ruby など) を作成する必要があります。