持续集成和“X 即代码”答案

【问题标题】：Continuous integration and "X as a code"持续集成和“X 即代码”
【发布时间】：2014-05-05 12:27:49
【问题描述】：

在 VCS 中保留所有持续集成和交付配置的优缺点是什么？

就像“基础设施即代码”一样，这应该允许像代码本身一样使用所有配置矩阵、管道和东西。执行构建、测试、部署等的顺序——感觉很像编码。为什么不包含类似的源代码？它已经部分包含在 VCS - makefile 等中，但它们并不代表整个交付过程。

Travis CI 是我所知道的唯一以这种方式工作的东西（有点）。还有其他人吗？如果没有 - 为什么？

【问题讨论】：

【解决方案1】：

如果它是一段需要多次执行的代码，或者如果它是一个可以重新使用的配置，它应该始终存储在 VCS 中。简而言之，您应该始终将 CI 和交付配置存储在 VCS 中。

我能想到的唯一缺点是你会在你的 VCS 系统中占用一些额外的空间，但这并不算太多，而且非常值得开销

【讨论】：

跟我想的完全一样。但如果是这样，为什么我找不到在 vcs 中存储 Jenkins job.xml（甚至是多个工作）的方法，所以在每个新版本中都会选择新配置？还是其他 CI 服务器？
我对 Jenkins 不熟悉，但几乎每台服务器都允许您进行备份，并且您可以将备份存储在 VCS / 磁盘备份中。如果 jenkins 不提供该功能，那么只需编写一个自定义 unix 脚本来创建所有 xmls 文件的 zip 文件
我不是指备份（有插件，顺便说一句），我的意思是基本工作流程，当交付新修订所需的一切都来自 VCS 时，因此，即使 CI 服务器配置也成为“源工件”，具有轮询、更改检测等所有功能。就像在 Travis 中一样——最少的配置是从 Web 界面完成的——（repo url，安全数据的密钥），大部分是从 repo 中的文件中获取的——.travis.yml
您可以随时将这些配置文件签入到 VCS 中，以便在空白的情况下可以从 VCS 中恢复所有数据。

【解决方案2】：

Jenkin 的工作 DSL 插件可能是一个开始；请参阅https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin 也许您可以使用他们的 REST API (https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API) 推送模板。您可以将所有这些脚本和模板保留在版本控制之下，例如，当您在 SVN 中标记时，从模板创建一个新作业。

【讨论】：