我和我的團隊正在開始構建一些可重複使用的腳本。他們只能在我們的組織內重複使用，因爲他們與專用應用程序和我們特定的服務器環境一起工作。所以不適合rubyforge或github等。在組織內共享紅寶石代碼
我的問題是，確保我們所有用戶都使用最新，最好的腳本的最佳做法是什麼？我們幾乎在一臺服務器上運行這些腳本，但可能需要擴展到其他服務器。
我們應該將它們捆綁成寶石並啓動一個私人寶石服務器嗎？
或者像普通的，可共享的lib目錄一樣簡單。也許用腳本從我們的SCM下載/更新？
其他想法？
感謝....
這取決於一些因素，例如，有多少人想改變的代碼（只有你的團隊，還是別人太），或多少錢，你有嗎？
個人而言，我會創建一個build + gem服務器，您可以在其中使用某些版本控制系統（如git或svn，取決於項目中有多少人）上傳腳本，然後創建一個cron作業，這會自動在通用時間間隔內從源頭生成寶石並將它們存儲爲不同的版本。通過這種方式，您可以確保始終擁有一個存儲應用程序寶石的授權服務器，並且如果出現問題，您可以始終獲得早期版本。您的腳本可能會創建單獨的寶石版本名稱，如「appserv-edge」或「appserv-stable」
如果您有錢買得起，您可能還想查看github的封閉源代碼選項。然而，我不知道他們是否擁有非開源程序的寶石建設和託管設施。
我創建了一個私人gemserver，它很容易。唯一棘手的問題是決定用戶如何上傳寶石。就個人而言，我只是使用一個PHP上傳表單，並檢查它以確保它不掩蓋任何現有的寶石。
在我的辦公室，我們對一些共享腳本和庫使用了一些混合方法。我們將它們全部捆綁到一個gem中，但不是使用gem服務器，而是將它們保存在源代碼控制中，然後構建gem（使用newgem），並根據需要在本地安裝它。
這種方法的不足之處在於，它需要兩條命令來安裝gem，但是由於我們使用Capistrano進行部署，因此在qa和生產環境中很大程度上減輕了這種情況。
好處在於它很簡單，如果您正在處理需要更改寶石的某些內容，那麼在開發過程中會有一個非常短的編輯/構建/部署週期。我目前在共享gem中引入了很多常用功能，所以我非常欣賞這一點。