使用Concourse和Cloud Foundry進行連續部署的最佳實踐

Question

因此，我最近一直在使用concourse和雲代工廠調查ci/cd管道，並且我一直在困惑於實現此目的的最佳方式。所以我一直在考慮整個流程如何從開發到發佈。有很多談話和視頻在很高的層次上討論這個問題，但是他們經常會抽象出太多實際的實施細節以使其有用。就像人們如何在實際公司中推出這些產品一樣？我有很多問題，所以我會試着在這裏列出其中的一些，希望有人能夠給我一點啓發。

1. 整個流程和流水線在概念上從開發到製造看起來是什麼樣子？到目前爲止，我沿着線的東西：在自己的組織

   • 在開發過程中的每個產品團隊，每個開發者可能有自己的發展「空間」，他們手動cf push到可能，只是制定打擊。將會有開發空間，開發人員可以直接將其推向以及只能由自動化管道使用的空間來部署用於功能測試的工件。

   • 一旦開發者完成一個特點，他們會做一個拉請求，這會觸發與使用類似的git-multibranch-resource或git-pullrequest-resource一些試驗，這將鉤到GitHub的需要的狀態檢查掛鉤，如果任何回報一個較小的管道特定的PR可以合併成主或者不合並

   • 一旦所有檢查通過並且拉請求合併到主設備中，下面的管道被啓動，這在將工件釋放到產品之前驗證主分支。

code repo [master] -> build -> snapshot artifact repo -> deploy to test space -> run functional tests -> deploy to staging space -> run smoke tests and maybe other regression tests -> deploy artifact to prod -> monitoring/rollbacks (?)

可以/應該被添加到該管線或該方法的任何部分什麼其他東西？

一旦你自動部署，你怎麼也自動化事情發生像金絲雀版本或回滾一旦發生？這應該是管道的一部分還是完全獨立的東西？

我一直在玩臨時創建空間然後在功能測試階段將其拆分的想法，這樣做會有什麼好處嗎？這個想法是，正在部署的應用程序將有自己的乾淨環境使用，但這可能會很慢，並且很難知道每個空間內需要哪些服務。您將不得不閱讀清單，該清單僅指定服務名稱，這似乎需要某種在相同空間內命名服務實例的規範方式？另一種辦法是管理一個似乎也很複雜的空間池......

管道應該生成清單文件嗎？還是應該完全由開發者決定？只有開發人員知道應用程序需要哪些服務，而且似乎像實例計數，內存等應該是性能測試/管道應該能夠確定/自動化的東西。你可以在管道中生成一個清單，但是如果沒有閱讀清單，你就不知道應用程序需要哪些服務......雞和雞蛋問題？

我還有很多炙手可熱的問題，但現在我會在這裏把它關掉。我知道這些主題在Concourse和Cloud Foundry之間來回跳動，但是在討論CI/CD概念時，似乎實際細節通常是將兩者緊密結合在一起的實際棘手問題。我也知道具體的實施細節通常對每家公司都非常具體，但如果人們可以談論他們如何在他們的公司使用Concourse和Cloud Foundry實施這些管道/自動化管道（如果您可以將這些管道當然細節）。感謝大家！

Answer 1

在開發過程中，每個產品團隊都在自己的組織下，每個開發人員都可能擁有自己的開發「空間」，以便他們可以手動推送並發展。將會有開發空間，開發人員可以直接將其推向以及只能由自動化管道使用的空間來部署用於功能測試的工件。

老實說，如果您在CloudFoundry中創建多個組織，則無關緊要。如果您的CI/CD系統運行在與其他開發人員使用（ab）相同的導演上，您可能會遇到困難（我在那裏）。

一旦開發者完成一個特點，他們會做一個拉請求，這會觸發與使用類似的混帳多分支資源或混帳pullrequest資源的一些測試較小的管道，這將鉤到GitHub的如果任何特定的PR能夠合併爲主或不需要狀態檢查掛鉤並報告回去

我們正在做幾乎確切的事情。對於PR的結帳jtarchie的PR資源，請點擊這裏https://github.com/jtarchie/github-pullrequest-resource。 唯一的區別是我們沒有使用Github檢查。他們的問題是，你必須選擇一組固定的分支。

但是，如果我只是在PR中更改清單xyz，我不想運行所有測試。您只能將Github狀態API用於待處理和成功狀態，以解決該問題。

一旦所有檢查都通過並且拉取請求合併到master中，則下面的管道將被啓動，這會在將工件釋放到prod之前驗證主分支。

我們將PR放入開發分支並遵循Git Flow系統。我們的版本被手動合併到主版本中。

在將每個PR合併到主設備並觸發生產系統更新之前，您要首先檢查要執行的更新。你的測試用例可能很好，但你總是會錯過一些東西。

還有什麼其他的東西可以/應該添加到這個管道或這個過程的任何部分？

您可以擁有一個管道，它可以自動更新清單中的發佈/幹細胞。

一旦您自動部署，一旦出現什麼情況，您如何自動執行像金絲雀版本或回滾之類的操作？這應該是管道的一部分還是完全獨立的東西？

在您進入生產之前，在分段系統上測試您的東西。否則，你a）不知道更新是否在零宕機時間發生，b）防止生產中的潛在問題總是比回滾更好。

Ofc你也可以創建一個回滾管道，但是如果你到了那個地步，你的設置可能會出錯。

管道是否應該生成清單文件？還是應該完全由開發者決定？只有開發人員知道應用程序需要哪些服務，而且似乎像實例計數，內存等應該是性能測試/管道應該能夠確定/自動化的東西。你可以在管道中生成一個清單，但是如果沒有閱讀清單，你就不知道應用程序需要哪些服務......雞和雞蛋問題？

我們自己編寫清單，並使用CI/CD系統更新/部署/測試它們。

但是，如果你發現一個有效的案例和一個概念，可以讓你應用你的清單產生管道的情況下，我會試試看。

最後，您必須決定某個原子化是否對您的公司具有商業價值。

歡呼聲，丹尼斯