從 CI/CD 提交到存儲庫

Question

我最近將我的一個存儲庫配置為在我推送匹配"vX.YZ"的git tag時自動部署一個版本，但這個過程不是完全自動的。

具體來說，我必須在源代碼中更新我的版本號（即 bump "vX.YZ" ），然后才能將其標記為要構建。

---

所以看來我有幾個選擇

1. 在標記之前繼續手動修改內部版本號
2. 讓我的 CI 更新內部版本號（例如從標簽中提取它）然后將更改提交給master

在我看來，手動修改版本號是可取的，因為在部署發布之前需要更多的努力，並且發布與提交相關聯，而不是在 CI 必須更新版本號的情況下落后於一次提交。 （我也不想在更新master之前等待構建完成部署）

一直沒能在網上找到比較強烈的意見，所以很好奇：

將我的 CI 構建服務器提交到我的存儲庫是否被認為是不好的做法？

Answer 1

將我的 CI 構建服務器提交到我的存儲庫是否被認為是不好的做法？

它不被認為是一種不好的做法，但它會產生更多的復雜性和安全問題，這些問題應該與好處相平衡。 還要記住，您自動化的過程應該能夠在 CI 中斷的情況下手動執行。

我認為在你的情況下有一個更簡單的解決方案。 您可以在源代碼中包含未在存儲庫中提交的版本號的文件，並在構建時從提取最新標簽的腳本生成。 通過這種方式，您將擁有發布版本（標簽）的單一事實點，並且 CI 無需在存儲庫中提交任何內容。

Answer 2

如果您可以使用 vX.YZ BuildVersion版本控制方案，我會推薦以下內容。

1. 根據語義版本控制策略手動管理vX.YZ。
2. 如果您將新標簽推送到 GitHub，CI 會使用設置BuildVersion制作一個發布包。
   這將是增量計數。
   請注意 BuildVersion 不在 GitHub 上管理。
3. CI 將包推送到 GitHub Release。

Answer 3

詳細說明最初的問題，這比標簽示例更豐富。 有時，我們的 CI 在生成工件之前會修改 repo 的內容。 例如，假設您將配置文件與應用程序代碼一起提交。 您通常會將它們打包在一起（例如在 Docker 映像中），然后將映像作為構建過程的結果發送。 如果您的 CI 通過更改某些值來修改這些文件，您將如何對待它們？

• 在不重新運行整個構建的情況下將文件提交回同一個 repo 會使配置保持一致，但會擾亂構建過程，如果在此期間 repo 已更改，則可能會導致問題。

• 在最終工件中使用新配​​置將非常容易，但是如果您回頭看，工件將不會反映 repo 的實際內容。

• 將這些工件外部化到新的存儲庫是一種選擇，但違反了將構建應用程序所需的依賴項數量最小化的最佳實踐。