我們有一個非常大的Rails應用程序，它有兩個截然不同的部分：前端和CMS/Admin。我們希望將應用程序分成兩部分（用於維護，因爲我們有前後端工作的不同團隊，他們可能有不同的發佈週期）。將Rails應用程序分解爲兩部分
一個想法是啓動一個新的Admin 2.0應用程序，它可以訪問原始應用程序中的模型/架構，但具有自己的控制器/視圖和自己的模型，可以擴展原始模型直到完全解耦。這是可取的嗎？如果不是的話，那麼從一個單一代碼庫遷移出來的適當計劃是什麼？
警告，這是有點草率，並沒有去任何地方。
工作在一個非常大的應用程序，在你描述的莊園運行（爲了可擴展性的原因），我仍然有不同的意見（沒有確鑿的答案）。
目前我們使用3個主要應用程序（+一個或兩個使用模式片段的較小應用程序）。
RVW（我們的管理員應用程序）：這是寫入，運行在單個服務器上並負責維護模式的唯一應用程序。
reevoo.com：電子商務，價格比較，類似的東西。這（由於歷史原因運行時略有不同的模式，運行在RVW的只讀從站上，數據庫視圖用於映射模式，所有的寫操作都是通過在RVW拾取和操作的隊列上進行操作完成的。 ，但隨機數據庫相關的問題（主要與視圖有關）的數量是一個問題。這個應用程序的主要問題是難度共享代碼（寶石運作良好，我經常夢想將模式排成一行並共享！核機型中的寶石），我們使用Ruby寶石使用大量的集成測試跨應用邊界測試共享應用程序之間的代碼和（使用drunit（presentation on this available））
reevoomark：。非常高負荷的B2B應用這有許多服務器都有一個完整的堆棧（數據庫服務器，每個節點有一臺應用服務器），這些服務器的數據庫中都有一個數據庫導出 - 導入批處理作業。這在短期內效果很好，它的剪切靈活性僅僅是ace，但是應用程序之間的集成測試非常困難。
我的建議是避免不惜一切代價分開應用程序，讓事情快速幹掉成爲一項重大挑戰。我的建議是堅持一個應用程序，兩套路線（由環境變量啓動時選擇）。
這會給你所有其他解決方案的優點，同時使代碼共享隱含。將測試包拆分出來可以縮短測試周期，讓兩個團隊更容易管理。我會避免在不同的代碼基礎上工作，因爲這樣做會促使應用程序分離並使代碼共享變得棘手（如.com）。
如果您決定進行拆分，請進行一系列高級別的跨應用程序測試。自定義（每個應用程序）對一組核心模型的擴展聽起來像是一個很好的計劃，儘管具有不同的代碼庫和團隊，您仍然可能會得到重複的代碼。 Rails引擎應該是共享模型的好方法，但要爲模型重新加載做好準備，變得有點精神分裂。
祝你好運！
你有namespaced your admin controllers嗎？這將是一個相對簡單的細分點，並且還可以避免將代碼分成兩個應用程序的許多負面影響。
是的，我們有，但現在的痛點是前端團隊與後端團隊的時間安排不同，而後端團隊（觀衆人數更少）希望能夠更頻繁地進行部署對另一隊造成傷害。 – rdeshpande 2009-09-03 20:12:32
我認爲你可能試圖通過技術手段來解決管理問題，這樣做是非常危險的，因爲如果你分裂應用程序，你將只會面臨更多的管理問題。 – 2009-09-03 21:13:54
您是否考慮過在Rails Engines？在2.3中添加到Rails。
謝謝你的徹底答案！ – rdeshpande 2011-05-01 16:32:35