持续集成和“X作为代码”

在VCS中保持所有持续集成和交付配置的优点和缺点是什么？持续集成和“X作为代码”

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

特拉维斯CI是我知道的唯一那种工作方式（种）。还有其他人吗？如果不是 - 为什么？

来源

2014-05-05 Mikhail Cheshkov

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

，我能想到的唯一的con是你西港岛线在VCS系统使用了一些额外的空间，但它不是太多，相当值得的开销

来源

2014-05-08 04:38:27

完全如我所料。但是，如果是这样，为什么我找不到在vcs中存储Jenkins'job.xml'（甚至是多个作业）的方法，因此在每个新版本中，新配置都会被拾取？还是其他CI服务器？ –

我对Jenkins并不熟悉，但几乎每台服务器都可以进行备份，并且可以将备份存储在VCS /磁盘备份中。如果詹金斯不提供这种功能，那么只需编写一个自定义的unix脚本来创建所有xml文件的zip文件。 –

我不是指_backup_（有插件，btw），我的意思是基本的工作流程，当一切需要提供新的版本是从VCS中提取的，因此即使CI服务器配置成为“源文物”，通过轮询，更改检测和所有内容。就像在Travis中一样 - 最小的配置是通过web界面完成的 - （repo url，安全数据的关键），大部分是从文件中回收的 - “.travis.yml” –

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

来源

2014-05-21 20:33:10 Robert

持续集成和“X作为代码”

回答

相关问题