2

独自の Rails アプリをデプロイするのは非常に簡単です。しかし、サードパーティの Rails アプリをバージョン管理下に置いてデプロイするのは非常に困難であることがわかりました。

既存の RoR アプリケーション (私の場合は Redmine ですが、Rails 以外のアプリにも適用できます) を (従来の) ホスティング サーバーにデプロイするとします。構成またはローカルのカスタマイズに加えた変更を確実に元に戻したいと考えていますが、定期的に最新バージョンにアップグレードできるようにしたいとも考えています。

Redmine の公開 git リポジトリには.gitignore、config yaml ファイルやセッション ストアなどをカバーするファイルがあります。これは開発には理にかなっていますが、展開には適していません。

いくつかのオプションがあるようです：

  1. 公式レポのコピーにある構成ファイルを無視せず、カスタマイズ、プラグインなどを追加します。その後、新しいバージョンをブランチにマージして、競合に対処できます。
  2. 公式リポジトリからの履歴のないローカル リポジトリを保持します。新しいバージョンのマージは完全に手動になります。
  3. もっと複雑なことをしてください。複数レベルのブランチ/リポジトリ?

これらのオプションのどれも、私には特に洗練されたものでもシンプルなものでもないので、これまでのところ、何もしないという簡単な方法をとってきました。

これはよくある問題のようですが、実際にこれを扱っているブログや質問を見つけることができませんでした。サードパーティの Web アプリケーションの展開をどのように処理しますか?

4

1 に答える 1

0

いくつかのオプションは次のとおりです。

デプロイにはcapistranoを使用します。

capistrano で db migrations を実行するためのチュートリアルはたくさんあり、すべて git に保存できます。

パペットまたはシェフを使用して移行を行います。

これには、サーバーの追加など、あらゆる種類の展開をセットアップして実行できるという利点があります。

秘密のソース: 継続的な展開

単一の場所を使用して、これらの移行を自動的に実行します。

CI サーバー (例: Jenkins ) をセットアップして、上流のリポジトリ (または何でも) を監視し、originそこでliveコミットされた移行を実行します。また、Jenkins は、レポ内のロールバックを監視し、更新されたコードをコピーする前に無料の下方移行を実行するように設定できます。

CIが大きすぎる？

CI のセットアップがやり過ぎの場合は、途中でうまく機能する git ホスティング/デプロイ サービスがあります。シンプルな展開にはSpringloopsを使用し、すべての展開でデータベースの移行を実行するには REST フックを使用します。残念ながら、実際には「上」の移行でしか機能せず、「下」の移行は依然として手動で行われます。

于 2012-08-18T00:47:19.647 に答える