所以我最近一直在使用大厅和云代工厂调查ci / cd管道，我对最好的方法是什么感到困惑。所以我一直在思考整个流程从开发到发布的过程。有很多讨论和视频可以在很高的层次上讨论这个问题，但是它们往往会抽象出太多的实际实现细节，因为它很有用。就像人们如何在实际公司中实现这一点一样？我有很多问题，所以我会尝试在这里列出一些问题，希望有人能给我一些启发。
从开发到产品，整个流程和管道在概念上是什么样的？到目前为止，我有以下几点：
在开发过程中，每个产品团队都在他们自己的组织之下，每个开发人员都可能拥有自己的开发空间＆＃34;他们可以手动cf push来反对。 devs可以直接推送到开发空间，以及只能由自动化管道用于部署工件以进行功能测试的空间。
一旦开发人员完成了一项功能，他们就会发出一个拉取请求，这将触发一个较小的管道，并使用类似git-multibranch-resource或git-pullrequest-resource的某些测试来挂钩到github必要的状态检查挂钩并报告是否有任何特定的PR能够合并到主人
一旦所有检查都通过并且拉取请求被合并到主控器中，下面的管道就会被启动，这会在将工件发布到prod之前验证主分支。
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谈论他们如何实施这些管道/自动化管道，那将是很好的（如果你能省去细节当然）。谢谢大家！
答案 0 :(得分：0)
在开发过程中，每个产品团队都在他们自己的组织之下，每个开发人员都可能拥有自己的开发“空间”，他们可以手动将其推送到并进行开发。 devs可以直接推送到开发空间，以及只能由自动化管道用于部署工件进行功能测试的空间。
老实说，如果您在CloudFoundry中创建多个组织，则无关紧要。如果您的CI / CD系统在其他开发人员使用的相同导向器上运行，那么您可能会遇到困难（我在那里）。
一旦devs完成了一个功能，他们就会发出一个pull请求，这会触发一个较小的管道，并使用类似git-multibranch-resource或git-pullrequest-resource之类的东西进行一些测试，这会挂钩到github所需的状态检查挂钩并报告是否有任何特定的PR能够合并到母版
我们几乎完成了一切。对于PR的结帐jtarchie的PR资源https://github.com/jtarchie/github-pullrequest-resource。 唯一的区别是我们没有使用Github检查。它们的问题是，您必须为分支选择一组固定的检查。
但是如果我刚刚在PR中更改了清单xyz，我不想运行所有测试。您可以通过仅将Github Status API用于挂起和成功状态来克服该问题。
一旦所有检查都通过并且pull请求被合并到master中，下面的管道就会被启动，这会在将工件发布到prod之前验证master分支。
我们将PR纳入开发分支并遵循Git Flow系统。我们的版本手动合并为主文件。
在将每个PR合并到主服务器并触发生产系统更新之前，您需要先检查要执行的更新。您的测试用例可能很好，但您总是会错过一些东西。
此管道或此流程的任何部分可以/应该添加哪些其他内容？
您可以拥有一个管道，可以自动更新清单中的版本/词干单元。
一旦您自动部署，一旦发生某些事情，您如何自动执行诸如金丝雀版本或回滚之类的事情？这应该是管道的一部分还是完全独立的东西？
在投入生产之前在临时系统上测试您的东西。否则你a）不知道更新是否在零停机时间发生，b）防止生产中的潜在问题总是比回滚更好。
Ofc你也可以创建一个回滚管道，但如果你到了那一点，你的设置可能会出现其他问题。
管道是否应生成清单文件？或者应该完全取决于开发人员？只有开发人员知道应用程序需要哪些服务，而且看起来像实例计数，内存等应该是性能测试/管道应该能够确定/自动化的东西。你可以在管道中生成一个清单，但是如果没有读取清单就会知道应用程序需要哪些服务....鸡和鸡蛋问题？
我们自己编写清单并使用CI / CD系统更新/部署/测试它们。
但是如果你找到一个有效的案例和一个允许你在许多情况下应用你的清单生成管道的概念，我会尝试一下。
最后，您必须确定某个雾化是否为您的公司带来商业价值。
欢呼，丹尼斯