問題タブ [continuous-delivery]

Jez Humble 著「Continuous Delivery」の「構成情報」とは何を意味していますか?

Ubuntu マシンへのシステムのワンクリック展開に取り組んでいます。このために Puppet を使い始めました。外部モジュールを使用するには、次のようなものを使用して事前にインストールする必要があるようです

質問:

1. モジュールを使用するには、常にモジュールを事前にインストールする必要がありますか?
2. Puppet モジュールのインストールを自動化するにはどうすればよいですか?

これはスタンドアロンのパペット セットアップです (マスター スレーブではありません)。さまざまな顧客に対してこれを何度も繰り返さなければなりません。したがって、単一のボタンですべての作業を実行できると便利です。後の段階では、マスター/スレーブ設定の場所があります。ただし、顧客ごとに独立している必要があります。

Jenkins を使用して、一部のインフラストラクチャ プロジェクトで継続的デリバリーを実現しています。ATM マスター スレーブ Jenkins モデルは、ジョブが常にマスターではなくスレーブによって構築される場合に使用されます。私の意図は、LXC を使用してテスト キッチンおよびライプニッツ テストを構築および実行することです。すべての要件は vagrant-lxc、lxc ボックス、leibniz、および test-kitchen が構成されており、すべてが私の PC または他のチーム メンバーで正常に動作しますが、Jenkins のマスター スレーブを介してジョブを実行する場合は、環境に関するいくつかの問題、詳細:

1-ビルドステップの一部として実行すると、動作して正常"which lxc-create"に表示/usr/bin/lxc-createされますが、

2-実行時にkitchen test失敗して表示されます：

いくつかの環境変数が欠落しているか、何かが配線されているようです。スレーブに sshing して手動でビルドすると正常に動作するため、セットアップの問題ではなく、マスター/スレーブ環境の伝送の問題であるか、構成で重要なものが欠落していると言うことが重要です。 . 誰でも助けてもらえますか？

lxc バージョン: 1.0.0

vagrant-lxc: 0.8.0

ジェンキンス: 1.5.49

更新 1: これが私のキッチン構成です。

私のチームは、Visual Studio Online (「VSO」) を使用して ALM を管理しています。

ローカルの Git リポジトリから (リモートで) コードをビルドし、それを Azure 上の Microsoft Azure Web サイトにデプロイするためのプッシュ ボタン ビルド プロセスが既に用意されています。

これに加えて、ボタンを押すだけで構築および展開できるローカルの開発/テスト環境が必要です。

VSO の ALM エコシステム内から、自動化されたオンプレミスの開発テスト展開を開発パイプラインに統合する最良の方法は何ですか?

[私たちは TFS 2012 も所有しています。VSO からそれを活用して、VSO git リポジトリからオンプレミスのビルド展開を推進する方法はありますか?]

継続的インテグレーションと配信設定をすべて VCS に保持することの長所と短所は何ですか?

「コードとしてのインフラストラクチャ」と同様に、これにより、コード自体と同じように、すべての構成マトリックス、パイプラインなどを操作できるようになります。ビルド、テスト、デプロイなどの実行順序 - コーディングによく似た感じです。ソースコードのようなものを含めてみませんか? それは既に部分的に VCS (makefile など) にありますが、配信プロセス全体を表しているわけではありません。

Travis CI は、そのように機能することを私が知っている唯一のものです (一種の)。他にもありますか？いいえの場合 - なぜですか？