4

私は先週、Chefを増やし、Capistranoの使用をやめる準備をしています（感情的および運用的に）。（Railsアプリをホストしています。）

GitHubのフローに従います。つまり、マスターと多数の機能ブランチがあります。現在、継続的インテグレーションと継続的デプロイにはJenkinsを使用しておりmaster、サーバーへのデプロイにはCapistranoを使用していますが、ユニット、統合、および受け入れのテストに合格した場合に限ります。

私はChefのdeploy_revisionリソースを使用しており、それがどれほどうまく機能しているかにわくわくしています。「プッシュ」から「プル」になりたいです。しかし、テストに合格しない限り、コードをデプロイしたくありません。私はその効果を達成するための代替アプローチ間の選択に固執しています：

  1. Chefをタグ（例2.0）に向け、デプロイメントレシピでそのタグを定期的に更新します。（これは実際には継続的なデプロイメントではないため、これは好きではありません。コードをリリースするたびに、コードを手に持つようになりました。）
  2. ブランチのシェフを指してmaster -> release、テストスイートに合格した後にJenkinsをマージします。（これは、Jenkinsサーバーがリポジトリへの読み取り/書き込みアクセス権を持っているためです。）
  3. Chefを定期的に実行するように構成しないでください。代わりに、Jenkinschef-clientをSSH経由で実行してください。（JenkinsマシンがサーバーにSSHでアクセスできなくなる日を楽しみにしていたので、これは好きではありません。）
  4. コードをデプロイしますが、後でテストが失敗した場合はコミットを元に戻します。（私の見解では、エラーが発生しやすいです。）

私はすでに十分な宿題をしたと思います。私は、とりわけSteve Jangの徹底的な記事をフォローしており、 Chefのドキュメントに何時間も費やしてきました。しかし、Chefによる継続的デプロイに関するすべての優れたコミュニティチュートリアルでは、この特定のユースケースについての言及はありません。

上記のほとんどのオプションで生活できましたが、それが実証済みのアプローチであることがわかっていれば、気分が良くなります。そこにある他の組織はすでにこれを解決していると確信しています。どうやってやったの？

4

2 に答える 2

2

Jenkins からの prod をリッスンし、chef を実行する小さなスクリプトをセットアップできます。つまり、完全な SSH アクセスを必要としない Jenkins の限定的なトリガー アクセスを作成できます。

別のオプションは、Jenkinsがマージするリポジトリの別のクローンを作成することですmaster->releaseそれはあなたの開発リポジトリではありません。次に、Chef にそこからプルさせます (または、Chef にそこでリビジョンを検索させ、元のリポジトリからそのリビジョンをプルさせます。これにより、その間に誰も人為的にコミットを台無しにしていないという確信が少し得られます)。

于 2012-12-30T18:17:04.700 に答える
0

私が使用した解決策の1つは、環境変数（具体的にはENV['deploy_build']）の背後にあるシェフのレシピで実際のコードのデプロイを保護することです。実際にコードをデプロイすることに関係のないものはすべてレシピでこれらのガードの外に残され、chef-clientは30分ごとに楽しく実行され、ベースシステムの準備ができていることを確認します。

ビルドとテストの実行が成功すると、ビルドシステムは次の形式のsshを起動します。

ssh deploy_system deploy_build=true chef-client

これにより、レシピで最新のビルドをデプロイできます。これは、ビルドシステムが特定の順序でサーバーに更新をデプロイする必要があるため、特に役立ちます。これにより、ビルドシステム（jenkins）から調整できます。

于 2012-12-31T22:59:31.860 に答える