<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Flux on Danilo Falcão da Silva</title><link>https://falcao.org/tags/flux/</link><description>Recent content in Flux on Danilo Falcão da Silva</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 19 May 2026 13:30:00 -0300</lastBuildDate><atom:link href="https://falcao.org/tags/flux/index.xml" rel="self" type="application/rss+xml"/><item><title>GitOps with Argo CD: The Reconciliation Loop That Survives 3 a.m.</title><link>https://falcao.org/posts/gitops-argocd/</link><pubDate>Tue, 19 May 2026 13:30:00 -0300</pubDate><guid>https://falcao.org/posts/gitops-argocd/</guid><description>&lt;p>Here&amp;rsquo;s the test I use for any deployment tooling:&lt;/p>
&lt;p>&lt;strong>It is 3 a.m. on a Sunday. PagerDuty just woke you up. A production
service is degraded. You roll out of bed, open your laptop, and have
to figure out what the cluster &lt;em>thinks&lt;/em> is true, what&amp;rsquo;s &lt;em>actually&lt;/em>
true, and what changed in the last twelve hours. The faster you can
answer those three questions, the better the tooling.&lt;/strong>&lt;/p>
&lt;p>The right GitOps stack collapses all three questions into one
dashboard. The wrong one has you SSH-hopping between five servers
running &lt;code>kubectl rollout history&lt;/code> against unlabeled deployments. I&amp;rsquo;ve
done both. I&amp;rsquo;m writing this post about the former.&lt;/p></description></item></channel></rss>