在 VCS 中保留所有持续集成和交付配置的优点和缺点是什么？
就像“基础设施即代码”一样，这应该允许像代码本身一样使用所有配置矩阵、管道和东西。执行构建、测试、部署等的顺序——感觉很像编码。为什么不包含类似的源代码？它已经部分包含在 VCS - makefile 等中，但它们并不代表整个交付过程。
Travis CI 是我唯一知道以这种方式工作的东西（有点）。还有其他人吗？如果没有 - 为什么？
问问题
288 次
2 回答
1
如果它是一段需要多次执行的代码，或者它是一个可以重新使用的配置，它应该始终存储在 VCS 中。简而言之，您应该始终将 CI 和交付配置存储在 VCS 中。
我能想到的唯一缺点是您将在您的 VCS 系统中占用一些额外的空间，但这并不过分，而且非常值得开销
于 2014-05-08T04:38:27.217 回答
0
Jenkins 的工作 DSL 插件可能是一个开始；请参阅https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin也许您可以使用他们的 REST API 推送模板（https://wiki.jenkins-ci.org/display/JENKINS/Remote+访问+API）。您可以将所有这些脚本和模板保留在版本控制之下，例如，当您在 SVN 中标记时，从模板创建一个新作业。
于 2014-05-21T20:33:10.473 回答