0

What are pros and cons of keeping all of continuous integration and delivery configuration in VCS?

Just like "infrastructure as a code", this should allow to work with all the configuration matrices, pipelines and stuff just like code itself. Order of executing building, testing, deploying, etc. - something feels much like coding. Why not contain that like source code? It's already partially in VCS - makefiles etc., but they don't represent the entire delivery process.

Travis CI is the only thing I know that work that way (kind of). Is there any others? If no - why?

Mikhail Cheshkov
  • 226
  • 2
  • 14

2 Answers2

1

If it is a piece of code that needs to execute more than once or if its is a configuration that can be resued, it should always be stored in VCS. In short , you should always store your CI and delivery configuration in VCS.

The only con that I can think of is you wil be using up a few extra space in your VCS system but it is not too much and quite worth the overhead

Biswajit_86
  • 3,661
  • 2
  • 22
  • 36
  • That exactly as I thought. But if so, why i can't find a way to store, Jenkins `job.xml` (or even multiple jobs) in vcs, so at each new revision new configuration is picked up? Or any other CI server? – Mikhail Cheshkov May 08 '14 at 07:41
  • I am not familiar with Jenkins but almost every server enables you to take a backup and you can store the backup in VCS / disk backups. If jenkins does not offer that functionality , then just write a custom unix script to create a zip file of all xmls files – Biswajit_86 May 08 '14 at 13:53
  • I don't mean a _backup_ (there are plugins for that, btw), I mean that essential workflow, when everything needed to deliver new revision is taken from VCS, so even CI server config become "source artifact", with polling, changes detection and all the stuff. Just as in Travis - minimal configuration is done from web interface - (repo url, keys for secure data) and most is taken from file in repo - `.travis.yml` – Mikhail Cheshkov May 08 '14 at 22:55
  • You can always check in those configuration files to a VCS , so that in the case of a blankout all the data can be restored from VCS. – Biswajit_86 May 09 '14 at 02:37
0

Jenkin's job DSL plugin might be a start; see https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin Maybe you can push templates with their REST API (https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API). You could keep all these scripts and templates under version control and e.g., create a new job from the template when you tag in SVN.

Robert
  • 7,394
  • 40
  • 45
  • 64