Chefはアプリケーションのデプロイメントに使用する適切なツールですか？
両方の構成管理にChefを使用します（「DBノード」に適切なバージョンの適切なDBがあることを確認します。「アプリケーションサーバー」に適切なバージョンのJavaおよびenv varsがあることを確認します。等）と同様に展開（chef-client --once）を適切なアプリサーバーノードに追加します。
個人的には、デプロイはCIサーバーの領域に属しているように感じます。アプリ以外のすべてのもの（コンテナー、OS、システムツール、システム構成など）は構成管理に属しているため、ChefやPuppetなどのツールで管理するのが最適です。
現在、CIビルドはアーティファクト（Tomcatコンテナーが埋め込まれた実行可能JAR）を生成し、JARをデプロイする必要があるすべてのノードでChef-Clientを実行します。 Chef-Clientは、CIサーバーからJARをプルするように構成されています。これは私にはハッキーな感じがします。私はより良い、より説得力のあるソリューションを研究しようとしています。
だから私は尋ねます：
- デプロイメントはCIサーバーに属していますか、それともCMツールに属していますか？ なぜ？
- CIサーバーに属している場合、実際にデプロイを実行するためにCIサーバーはどのメカニズム（SSH、SCPなど）を使用する必要がありますか？私たちはBambooを使用していますが、JenkinsやHudsonなどについても同じくらい簡単に話している可能性があります。
- deploying（ノードにアプリを配置する）とrunningには違いがあります。実行はCIサーバー、CMツール、またはその他のプロセスにも属していますか？つまり、アプリの「古い」バージョンを実際にstopし、「新しい」バージョンに置き換えて、start新しいバージョン？これはランデッキのようなものの候補ですか？
答えは主に意見に基づいており、人々が働いている企業の政治的雰囲気を反映していると思いますが、ここに行きます...
すべてが「なぜ」から始まると思います。アプリを作成する理由ビジネス目標を達成するため。インフラストラクチャを構築する理由ビジネス目標を達成するアプリを実行するため。したがって、ここには自然な階層があるようです。 CIサーバーはアプリをビルドし、それらをsomethingでテストします。 CMツールはサーバーを構築します。したがって、適切に構成されたDevOpsチェーンは、CIサーバーを使用してCMツールを呼び出し、それらが展開先が適切に構成されていることを確認します。次に、テストに合格すると、それらの同じCIサーバーが展開ツールを呼び出し（必要な場合）、コードを本番サーバーにプッシュしますcould必要に応じてCMスクリプトですぐにビルドされます。つまり、スクリプトはそこにあるものの定義になります。最初にスクリプト化されていないサーバーに変更は加えられません。既存のアプリをバウンスする限り、それはインフラストラクチャの構成に依存します。アプリサーバーを（ユーザーに影響を与えることなく）スムーズにオフラインにでき、新しいコードをデプロイし、スモークテストを実行して、サーバーのファーム全体でローリングスクリプトですべてをオンラインに戻すことができる場合、それが目的です-継続的エンドユーザーに影響を与えない配信機能。
私の意見では、DeploymentはCIサーバーに属しています。 chefのようなCMツールは、インフラストラクチャを望ましい状態に構築することです。しかし、展開はそれ以上のものです。フロントエンドWebアプリケーションを含むシステムを複数の負荷分散サーバーにデプロイし、一部のDB変更スクリプトといくつかのバックエンドサービスを別のサーバーセットにデプロイする必要があるとします。デプロイメントには依存関係と順序があります。例えばすべてのサーバーへのバックエンドサービスの前、およびフロントエンドWebアプリの前のDBの変更。いずれかのステップでエラーが発生した場合、実行する必要があるアクションがある場合があります。私が理解しているように、シェフはこの種のシナリオを処理できませんが、有能なCIツールは処理できます。
もう1つの問題は、多くの場合、インフラストラクチャが複数のアプリ間で共有され、アプリとは異なるペースでパッチが適用されて更新されます。実際、1つのアプリはインフラストラクチャを所有していないため、インフラストラクチャをアップグレードしないでください。これは、CIとCMを分離しておくもう1つの理由です。