有一個已經運行多年的生產系統，首先是作爲PHP應用程序，然後是與Rails的混合，現在完全在Rails中。目前還不清楚它到底有多長。最古老的git commit是從5年前開始的。強化遺留Rails應用程序的第一步是什麼？
目標是保持系統不惜一切代價運行。只要沒有中斷，我們使用什麼代碼就沒有關係。目前它在Rails版本3.2.33。
如果我們不升級任何寶石，我們將有機會過時並且不可部署。如果我們升級，我們需要對代碼進行更改，導致潛在的錯誤蔓延。我們不僅面臨代碼腐敗，而且還面臨由於AWS中斷而導致的停機時間。
什麼是確保什麼都不破的第一步？我花了幾個月時間寫黃瓜（整合）測試，但很難涵蓋每個邊緣案例。該應用程序運行時間很長，大多數錯誤已得到修復，並且幾乎沒有新的例外。測試從一開始就不是優先考慮事項，因此大部分代碼都是無證的。
老實說，我發現Ruby on Rails對於這類應用程序並不理想。 Ruby和Rails都有非常積極的發佈時間表，Rails尤其不怕向後兼容。 Rails對於敏捷開發來說非常重要，因爲事物總是在變化，但是以長期穩定性爲代價。
我假設你的應用程序足夠大，你不想切換到其他任何東西。例如，Sinatra變化不大，而且會是一個更穩定的選擇。
如果你堅持使用Rails，我建議擺脫儘可能多的gem依賴關係。他們總會有一種危險，他們將不再被開發，或者他們可能會引入錯誤或漏洞。
此外，儘可能多地傾向於使用Rails相關代碼的PORO（普通的舊Ruby對象）。它通常需要更多的工作，但最終會得到更穩定和可重用的代碼。
我意識到，可能比您想要放入這樣的應用程序更多的工作，但這是我最好的建議。
我的經驗證實了你的說法，這是一項艱鉅的任務，因爲開發人員傾向於儘可能多地使用寶石來儘快完成工作在開始的時候，Gems的質量是混合的，但通常比自行開發的解決方案要好，幾乎總是這樣，這個應用程序將從更高的代碼質量標準中獲益最多 –
第一步是將寶石文件中使用的所有寶石的特定寶石版本。
對於〔實施例
gem 'rspec-rails'
可能成爲
gem 'rspec-rails', '2.14.1'
你可以找出哪些版本目前正在使用的看着你Gemfile.lock的，例如，該行Gemfile.lock的節目爲rspec選擇的版本：
rspec (2.14.1)
即使Gemfile沒有版本n，例如
gem chronic
所述的Gemfile 將已使用的版本，例如
chronic (0.10.2)
如果我們沒有任何升級寶石，我們運行的過時和undeployable的機會。如果我們升級，我們需要對代碼進行更改，導致潛在的錯誤蔓延。
是的，這是您的困境。沒有什麼魔力，你必須選擇你想要解決的兩個優先級中的哪一個。正如所指出的，RoR不是一個可以「保持原狀」的框架。對構成大多數應用程序的寶石的不斷變化意味着RoR應用程序的老化程度並不高。
你應該解釋並重復，重複，重複這個項目的所有者。通常這是「被接受」的原則 - 但不是真的 - 因爲同樣的問題繼續被問到「儘管如此，我該如何升級它，怎樣才能確保沒有任何變化或破裂等等。」
如果應用程序將在幾個月內退役，則沒有問題。如果沒有真正的計劃來實現應用程序的日落，它將繼續成爲業務的重要組成部分，那麼您只需要使用資源來維護它。在RoR的土地上沒有免費的午餐。
升級不是項目所有者的優先事項，但如果代碼[R它會是。所以我們需要找到適時升級和穩定性之間的平衡點。 –
安全性也是一個問題，所以我們需要檢查每個gem的更新日誌，以查看當前版本是否有任何漏洞。 –
寫很多測試是關鍵的第一步，很高興看到這一點。檢查您的語句覆蓋範圍，看看您是否缺少重要代碼區域的測試，並確保您具有涵蓋關鍵序列的集成測試。這個想法是修改您的測試，以減少更改會導致用戶可見的故障的風險。
現在在某些系統上設置連續測試。
設置您的Gemfile和.ruby版本，以便您具體控制所有內容的加載版本。這不會自動更新 - 但它確保您擁有控制權而不是您更新的內容。檢入Gemfile和Gemfile.lock。
此時你可以慢慢增加版本號。不要跳過很多版本號 - 緩慢升級通常會更好，以便您可以看到棄用警告。修復那些，沖洗，重複。
修改您的（輸入）驗證器爲挑剔的白名單（「它必須是這種形式或我不會接受它」）。如果您可以防止來自的錯誤數據進入您的系統，那麼它更可能正常工作，並且通常更難以攻擊。
爲了安全起見，請考慮添加安全頭，並將CSP設置爲儘可能強。
開始添加一些靜態分析儀。 Rubocop和Brakeman非常有用。您可能必須配置Rubocop纔會抱怨一些事情，然後慢慢增加他們報告的內容。將所有檢查添加到默認的「rake」命令中，以便您可以鍵入「rake」來運行靜態分析器和測試套件。
不管你使用什麼框架，沒有魔法。人們會犯錯誤，假裝別人是沒有幫助的。
你可能是CII Best Practices badge project一個有用的例子。它使用RoR，並由我領導。特別是，請參閱： * CONTRIBUTING * Security information (assurance case)
從貢獻： 「一般來說，我們儘量積極主動地檢測並儘快消除錯誤和漏洞，並減少它們的影響時，他們有這樣的事情我們。使用防禦性設計和編碼風格來減少錯誤發生的可能性，嘗試儘早發現錯誤的各種工具以及具有顯着覆蓋範圍的自動測試套件。「
謝謝。這是比我挑選的更好的答案，但自從我問:)以來已經很長時間了。 –
什麼意思是硬化？安全？ –
另外，是否還有新功能？ –
我的意思是強化服務中的任何可能的中斷，包括安全相關問題，正常運行時間/可用性和一般維護 –