<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ci-Cd on Simple Enough Blog</title><link>https://blog-dev.simpleenough.net/tags/ci-cd/</link><description>Recent content in Ci-Cd on Simple Enough Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 25 Mar 2026 12:00:00 +0100</lastBuildDate><atom:link href="https://blog-dev.simpleenough.net/tags/ci-cd/index.xml" rel="self" type="application/rss+xml"/><item><title>Nx Is Not a JavaScript Tool: It Is a Work Orchestrator</title><link>https://blog-dev.simpleenough.net/blog/nx/</link><pubDate>Wed, 25 Mar 2026 12:00:00 +0100</pubDate><guid>https://blog-dev.simpleenough.net/blog/nx/</guid><description>&lt;h2 id="i-nx-is-not-a-javascript-tool-it-is-a-work-orchestrator" class="heading">I. Nx Is Not a JavaScript Tool: It Is a Work Orchestrator&lt;a href="#i-nx-is-not-a-javascript-tool-it-is-a-work-orchestrator" aria-labelledby="i-nx-is-not-a-javascript-tool-it-is-a-work-orchestrator">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>Nx is often presented — and perceived — as a JavaScript tool.&lt;br>
“A thing for Angular,” or at best “a monorepo runner for Node.”&lt;/p>
&lt;p>That perception is understandable…&lt;br>
but &lt;strong>fundamentally incorrect&lt;/strong>.&lt;/p>
&lt;p>Nx is not a JS tool.&lt;br>
&lt;strong>Nx is a work orchestrator.&lt;/strong>&lt;/p>
&lt;p>And that is precisely why it appears almost naturally
as soon as a repository becomes &lt;strong>polyglot&lt;/strong>.&lt;/p></description></item><item><title>Why Is Docker Cache Insufficient for a Monorepo?</title><link>https://blog-dev.simpleenough.net/blog/cache_docker/</link><pubDate>Wed, 18 Mar 2026 10:00:00 +0100</pubDate><guid>https://blog-dev.simpleenough.net/blog/cache_docker/</guid><description>&lt;h2 id="i-why-is-docker-cache-insufficient-for-a-monorepo" class="heading">I. Why Is Docker Cache Insufficient for a Monorepo?&lt;a href="#i-why-is-docker-cache-insufficient-for-a-monorepo" aria-labelledby="i-why-is-docker-cache-insufficient-for-a-monorepo">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>Docker is everywhere.&lt;br>
And with it, a widely shared idea:&lt;/p>





 &lt;blockquote class="blockquote">
 &lt;p>&lt;em>“If we structure our Dockerfiles well, Docker cache will speed up our CI.”&lt;/em>&lt;/p>
 &lt;/blockquote>
&lt;p>That is &lt;strong>true&lt;/strong>&amp;hellip; but only &lt;strong>up to a certain point&lt;/strong>.&lt;/p>
&lt;p>As soon as you work in a &lt;strong>monorepo&lt;/strong> — with multiple projects, multiple languages, and multiple logical pipelines — Docker cache quickly shows its limits.&lt;/p></description></item><item><title>What Should You Really Cache in a CI/CD Pipeline?</title><link>https://blog-dev.simpleenough.net/blog/cache_cicd/</link><pubDate>Wed, 11 Mar 2026 10:00:00 +0100</pubDate><guid>https://blog-dev.simpleenough.net/blog/cache_cicd/</guid><description>&lt;h2 id="i-introduction" class="heading">I. Introduction&lt;a href="#i-introduction" aria-labelledby="i-introduction">
&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 640 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>When trying to speed up a CI/CD pipeline, the first idea that almost always comes up is:&lt;/p>





 &lt;blockquote class="blockquote">
 &lt;p>&lt;em>“we need to add cache”&lt;/em>&lt;/p>
 &lt;/blockquote>
&lt;p>But very quickly, another question appears:&lt;br>
&lt;strong>what exactly are we caching?&lt;/strong>&lt;/p>
&lt;p>Files? Folders? Docker images? Dependencies?&lt;br>
And above all: &lt;strong>which cache has a real impact, and which one just makes the system more complex?&lt;/strong>&lt;/p></description></item></channel></rss>