私は、プロジェクトの展開プロセスを置き換える (改善する) ことに取り組んでおり、可能な限り自動化しようとしています。現在、プレーン シェル スクリプトを使用しています。Fabric と Capistrano についていくつか調査を行い、デプロイの自動化に役立つかどうかを確認しました。
展開ツール (つまり、Capistrano、Fabric) は、シェル スクリプトを使用するのとほぼ同じことを行います。
高度なプログラミング言語を身につける以外に、プレーン シェル スクリプトに対して展開を使用する利点は何ですか?
展開の適切な「適合性」は、展開のサイズ、複雑さ、および運用プロファイルに大きく関係していると思います。アプリが 1 台のマシンで実行されていて、新しいインスタンスをときどき起動するだけで、それをシェルで完全に自動化できる場合は、祝福を数えて、できる限りそのシェル スクリプトを使用してください。シンプルさには価値があります。
デプロイ アーキテクチャ、クラスタ サイズ、チーム サイズ、ステージング/テスト環境の数、デプロイ頻度などが増大するある時点で、Fabric などを使用して次のレベルの洗練に進むことは理にかなっています。コストと利点の両方があります。主な利点、または私の考えでは、シェル スクリプトで満たすのが本当に難しい要件は、複数のターゲットへの同時のリモート デプロイ、既にデプロイされたインスタンスへのスクリプトのべき等再適用などです。高水準言語 (python、ruby など) や使用できるサード パーティ製モジュールなどの滑らかさにとらわれないでください。基本に固執してください。要件を満たすために本当に必要な展開の複雑さに対してのみ支払い、単純なスクリプトが機能する場合は、それらに固執します。ケーススタディ：Solaris の多くの部分が Korn シェル スクリプトとして存在し、10 年以上にわたって正常に動作しています。少量の Fabric/Capistrano/Puppet/Chef/Etc を組み合わせてシェル スクリプトの堅実なセットを編成することで、展開範囲の中程度の範囲のほとんどを処理できます。