<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Configuration on F. Latini - IT Engineer</title><link>https://latini.dev/tags/configuration/</link><description>Recent content in Configuration on F. Latini - IT Engineer</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 12 Nov 2026 08:00:00 +0000</lastBuildDate><atom:link href="https://latini.dev/tags/configuration/index.xml" rel="self" type="application/rss+xml"/><item><title>The Change That Skipped the Pipeline</title><link>https://latini.dev/posts/the-change-that-skipped-the-pipeline/</link><pubDate>Thu, 12 Nov 2026 08:00:00 +0000</pubDate><guid>https://latini.dev/posts/the-change-that-skipped-the-pipeline/</guid><description>&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; - Most platform teams have spent years making code deploys safe: review, tests, a canary, a one-command rollback, a record of who shipped what. Then production changes in a dozen other ways that touch none of it - a feature flag flipped to everyone at once, a global config value edited in a web UI, a security group changed in the cloud console, a manual &lt;code&gt;UPDATE&lt;/code&gt; in a database shell, a DNS record, an IAM policy, a vendor setting. In most organisations I have worked with, those side doors start a large share of the incidents, and the change failure rate cannot see any of them because it only counts deploys. The cure is not to force every change through a twenty-minute pipeline. It is to give every change channel the properties that made deploys safe - a record, a proportionate review, a staged rollout and a fast undo - and to make &amp;ldquo;what changed in the last hour?&amp;rdquo; a single query instead of a question in Slack.&lt;/p&gt;</description></item></channel></rss>