<p>A CI/CD system is, after all, just another software product/system. Regular upgrades and at least some changes in the plugin installations could be treated as changes of the software product itself. </p>

<p>I see no founded reason for which such software product can't also use as part of its own development process a CI/CD solution. <em>Maybe</em> even itself - the most recent production version, for example - if it's flexible enough (I'm still investigating such possibility for the CI system I'm working on).</p>

<p>Now, a CI/CD system deployed/actively used in a certain software development project is effectively a software product deployed in a specific environment. </p>

<p>Changes to the configurations of the CI/CD system aren't actually software changes, they're changes of the environment in which the software system is deployed. These are trickier to address in a CI/CD pipeline. Some even impossible. You'd have to replicate the environment as close as possible. But it's unlikely you'll be able to do that at 100% - just like no dev/QA/etc environment is <em>exactly</em> as the production one.</p>

<p>Some environment changes could be tested in a CI/CD pipeline. For example changes to a test script: both the old and the new versions can be executed as parallel pipeline jobs with the same set of artifacts for a period of time, long enough to determine the test quality and stability before making the new version the official one and retiring the old one.</p>

<p>Finally, don't forget that <em>most</em> CI systems are reactive: they <em>detect</em> breakages, but human action is required to identify the culprit and/or make repairs before the development process can be resumed. Applying such CI system to an actively used CI/CD system one would allow the show-stopper problems you mention. Only a <a href="https://www.apartsw.com/insights/2016/11/25/traditional_vs_non_blocking_ci.html" rel="nofollow noreferrer">non-blocking</a> CI system can completely <em>prevent</em> them (<strong>disclaimer</strong>: I'm the founder of the company owning the referenced page and offering such system).</p>

CC BY-SA 3.0
2017-11-25T08:28:33.747Z
2017-11-25T08:28:33.747Z
Dan Cornilescu
<p>CI/CD environment is the production carrier for DevOps teams.</p>

<p>An error here is a show stopper for possibly many teams.</p>

<p>Additionally, it is a product offered to teams which needs maintenance (quartely new features sometimes and security patches anyway) and room for experiment (new metrics plugins for example).</p>

<p>How to allow this? The only argument against a sandbox I can imagine is its cost. But then, isn't a transition to IaC, aka Pipelines as Code providing a "serverless" CI/CD like in Gitlab or Travis, not the next step?
Otherwise, CI/CD is the new "pet" system?</p>

CC BY-SA 3.0
2017-11-24T20:33:38.057Z
Why would you need another CI tool?
030
CC BY-SA 3.0
2017-11-24T20:34:46.463Z
Please re-read 3rd paragraph
Ta Mu
CC BY-SA 3.0
2017-11-24T20:50:58.503Z
What tool are you using now?
030
CC BY-SA 3.0
2017-11-24T21:35:41.303Z
A toolchain is a set of tools and thsir exact combination is imho not relevant in this methodological context.i
Ta Mu
CC BY-SA 3.0
2017-11-24T21:38:11.693Z
You are not experiencing this currently?
030
CC BY-SA 3.0
2017-11-24T21:42:08.720Z
I do backup my CI system (gitlab)  as any other part, and update it every day as part of the daily patching of the system, in case of failure, roll back to the previous backup. When a test is needed I spin up a temporary instance to test. (I wonder where you did ear about a no sandbox rule BTW)
Tensibai
CC BY-SA 3.0
2017-11-24T21:43:46.757Z
Thx Tensibai; What if it is not just one tool but a set of 8?
Ta Mu
CC BY-SA 3.0
2017-11-25T08:34:40.570Z
@PeterMuryshkin: isn't a set of 8 tools equivalent to a sw project containing 8 repos? (in the context of my answer to this post) :)
Dan Cornilescu
CC BY-SA 3.0
2017-11-25T08:37:42.037Z
You've got the point Dan ;) only that you don't compile tgem at least in overwhelmingly most cases. Idwally just exchange Docker inage version in the cloud formulae.
Ta Mu
<continuous-integration><continuous-delivery>
Founded argument to have no sandbox CI/CD?
Ta Mu
# Founded argument to have no sandbox CI/CD?

(Asked by: username_0 on 2017-11-24)

CI/CD environment is the production carrier for DevOps teams.

An error here is a show stopper for possibly many teams.

Additionally, it is a product offered to teams which needs maintenance (quartely new features sometimes and security patches anyway) and room for experiment (new metrics plugins for example).

How to allow this? The only argument against a sandbox I can imagine is its cost. But then, isn't a transition to IaC, aka Pipelines as Code providing a "serverless" CI/CD like in Gitlab or Travis, not the next step?
Otherwise, CI/CD is the new "pet" system?

**Tags:** continuous-integration, continuous-delivery

> **Comments:**
> **username_1**: Why would you need another CI tool?  
> **username_0**: Please re-read 3rd paragraph  
> **username_1**: What tool are you using now?  
> **username_0**: A toolchain is a set of tools and thsir exact combination is imho not relevant in this methodological context.i  
> **username_1**: You are not experiencing this currently?  
> **username_2**: I do backup my CI system (gitlab)  as any other part, and update it every day as part of the daily patching of the system, in case of failure, roll back to the previous backup. When a test is needed I spin up a temporary instance to test. (I wonder where you did ear about a no sandbox rule BTW)  
> **username_0**: Thx username_2; What if it is not just one tool but a set of 8?  
> **username_3**: @PeterMuryshkin: isn't a set of 8 tools equivalent to a sw project containing 8 repos? (in the context of my answer to this post) :)  
> **username_0**: You've got the point Dan ;) only that you don't compile tgem at least in overwhelmingly most cases. Idwally just exchange Docker inage version in the cloud formulae.  

---

## 1 answers

### Answer by username_3 on 2017-11-25. Score: 1 | Accepted answer

A CI/CD system is, after all, just another software product/system. Regular upgrades and at least some changes in the plugin installations could be treated as changes of the software product itself.

I see no founded reason for which such software product can't also use as part of its own development process a CI/CD solution. *Maybe* even itself - the most recent production version, for example - if it's flexible enough (I'm still investigating such possibility for the CI system I'm working on).

Now, a CI/CD system deployed/actively used in a certain software development project is effectively a software product deployed in a specific environment.

Changes to the configurations of the CI/CD system aren't actually software changes, they're changes of the environment in which the software system is deployed. These are trickier to address in a CI/CD pipeline. Some even impossible. You'd have to replicate the environment as close as possible. But it's unlikely you'll be able to do that at 100% - just like no dev/QA/etc environment is *exactly* as the production one.

Some environment changes could be tested in a CI/CD pipeline. For example changes to a test script: both the old and the new versions can be executed as parallel pipeline jobs with the same set of artifacts for a period of time, long enough to determine the test quality and stability before making the new version the official one and retiring the old one.

Finally, don't forget that *most* CI systems are reactive: they *detect* breakages, but human action is required to identify the culprit and/or make repairs before the development process can be resumed. Applying such CI system to an actively used CI/CD system one would allow the show-stopper problems you mention. Only a [non-blocking](https://www.apartsw.com/insights/2016/11/25/traditional_vs_non_blocking_ci.html) CI system can completely *prevent* them (**disclaimer**: I'm the founder of the company owning the referenced page and offering such system).


---

