如何處理Gemfile.lock與本地寶石資源庫？

Question

介紹

我們有一個Rails5應用程序，這是在約10+發動機splittend和核心應用，其安裝這些引擎。

在我們的例子中，引擎是一個簡單的舊的rails引擎，被定義爲gem並位於專用的git存儲庫中。核心應用程序中的Gemfile指的是所有引擎（見下文）。

要求的行爲

• 對於部署寶石/引擎的特定版本應該使用（由核心）。
• 對於本地開發，本地克隆存儲庫的HEAD應該被使用（由核心）。

當前設置

我們實現了通過執行以下步驟在覈心應用程序的每個引擎：

• 添加gem 'nice_engine1', '~> 0.0.1', branch: :develop, git: '[...]', tag: 'v0.0.1'
• 設置一個捆綁的配置項：bundle config local.nice_engine1 ../nice_engine1

這似乎工作，但我們沒有嘗試運行部署尚未安裝。

問題與安裝

每次存儲庫中的一個局部更新，我們運行的核心bundle install，捆綁更新Gemfile.lock新HEAD裁判本地引擎存儲庫。我們曾經承諾改變Gemfile.lock。

不幸的是這是否會導致一些問題：

1. 如果有人更新了核心應用程序，而不更新引擎，它可能發生，即核心Gemfile.lock指的是git的承諾發動機，這不在當地存在。如果試圖使用rails應用程序，那會導致錯誤。
2. 在部署時（我認爲）Gemfile.lock可能引用一個提交id，這是更新的，然後提交我想要部署的標記/版本。我不確定在這種情況下會發生什麼，但我擔心，這隻會導致我們陷入困境。
3. 我們在更改Gemfile.lock的核心中有很多提交（可能針對其中一個引擎的每個更改）。
4. 使用其他引擎分支機構本地然後master迫使開發商在主應用程序來改變分支名Gemfile

問題

什麼是管理Gemfile並在Gemfile.lock正確的/最佳途徑避免這些問題的給定情況？

有關最佳實踐和改進建議等的一些提示，如何使用bundler和git來滿足我們的要求，我會很感激。

Answer 1

如果有人更新了核心應用程序，而不更新引擎，它可能 發生，該核心Gemfile.lock的指的是git的承諾的 引擎，它不存在於本地的。如果您嘗試使用 來使用rails應用程序，則會導致錯誤。

這裏有幾個選項：

1）使用像git-bundle寶石，讓您可以運行一個命令，如gitb pull更新主要應用和引擎。

2）打開主應用程序和IDEM中的引擎，如RubyMine，因爲如果單擊VCS - >更新項目，它將更新所有存儲庫。

3）創建一個類似於git-bundle的腳本，它可以同時更新所有的存儲庫。

在部署的時候（我認爲）的Gemfile.lock的可能指的是 提交ID，這是新的，則提交的標籤/版本我 要部署。我不確定在這種情況下會發生什麼，但我擔心，這隻會讓我們陷入麻煩。

可以說主應用程序的特定修訂版標記爲1.0。該版本的Gemfile.lock指定引擎的哪些版本用於1.0。無法在運行引擎修訂版的主應用程序的標籤1.0中部署非Gemfile.lock中指定的引擎版本。

我們在更改Gemfile.lock （可能用於其中一個引擎中的每個更改）的核心中提交了很多提交。

是的，這是正確的。這是有效地將不同的git存儲庫和修訂版綁定到一個應用程序中的文件。它在版本控制文件中的事實使它更好，更易於追蹤。

什麼是正確/最好的方式來管理Gemfile和 Gemfile.lock在給定的情況下，以避免這些問題？

1）有一個寶石。它叫做git-bundle。我寫了它，並且我們已經在不同的應用程序中使用了大約5年，現在取得了巨大的成功。歡迎提出請求或反饋。

2）在主應用程序Gemfile中引用引擎時不要使用標籤。如果在發動機正在創建新的功能做在一個特性分支的分支在本地覆蓋所有庫：

gitb checkout -b feature/branch_name 

如果需要，發佈管理可以通過具有多個分支，如主，釋放和穩定上完成所有的git倉庫。在發動機或反之亦然

gitb checkout release 
gitb pull origin master 
gitb push 

3）如果您需要延長（裝飾或猴補丁）班：從一個環境移動代碼到接下來我們也做了activesupport-decorators尋找可用的各種選項之後。

Answer 2

經過良好的answer from Pierre Pretorius，一些研究和新的經驗，我設法解決所有4個問題。我會解釋的設置和每個問題的解決方案：

1. 如果有人更新了核心應用程序，而不更新引擎，它可能發生，即核心Gemfile.lock的指的是git的承諾發動機，這在本地不存在。如果嘗試使用Rails應用程序，則會導致錯誤。

爲了解決這個問題（和不相關的這個線程其他一些問題），我們寫了一個腳本，它關心更新引擎，並做一些其他必要的設置任務。對於每一個發動機下面的步驟將被執行：

• 設置爲主要應用的捆綁配置使用本地回購
• git pull -r --autostash或克隆如果回購尚未
• bundle install
• yarn install克隆
• bower install

之後，腳本拉和SE主應用程序。

對於更簡單的設置，您可以使用git-bundle gem，它允許您在所有引擎上執行命令。

最終解決了這個問題，即堆棧的某些內容不是最新的。

---

在部署時（我認爲）的Gemfile.lock的可參照提交ID，這是較新的，則提交的標籤/版本，我想部署。我不確定在這種情況下會發生什麼，但我擔心，這隻會導致我們陷入困境。

爲了解決這個問題，我們告訴團隊不要提交Gemfile.lock。相反，我們更新並提交Gemfile.lock，同時發佈新版本的主應用程序。這樣，主應用程序總是引用每個引擎的具體（通常最新）版本。然而Bundler通過本地覆蓋確保本地引擎庫的HEAD將獨立於鎖定版本使用。

這樣的部署是一致的，鎖定對具體的版本，降級是容易實現和開發人員不必更動版本，commitIds等

---

在更改Gemfile的核心中我們有很多提交。鎖定（可能對於其中一個引擎的每次更改）。

查看問題＃2的解決方案：我們只是不提交這些更改。這並不完美，但它確實有效。

---

使用其他發動機分支局部然後掌握迫使顯影劑在主應用程序的Gemfile改變分支名稱。

爲了解決這個問題，我們設置了捆綁配置disable_local_branch_check爲true：

bundle config disable_local_branch_check true 

通過這種方式，我們可以從Gemfile中刪除分支名稱爲引擎和開發人員可以使用他們可能希望在本地使用哪個分支（例如，在開發/檢查時的功能分支）。

---

之後，對於我們的引擎之一的Gemfile條目看起來是這樣的：

gem 'nice_engine1', '0.0.1', git: '[...]', tag: 'v0.0.1'