<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Devops on Rafael Zago</title><link>https://www.rafaelvzago.com/en/tags/devops/</link><description>Recent content in Devops on Rafael Zago</description><generator>Hugo</generator><language>en-US</language><copyright>© Rafael Zago</copyright><lastBuildDate>Fri, 24 Jul 2026 16:16:10 -0300</lastBuildDate><atom:link href="https://www.rafaelvzago.com/en/tags/devops/index.xml" rel="self" type="application/rss+xml"/><item><title>How I use AI in development (Cursor and Claude)</title><link>https://www.rafaelvzago.com/en/posts/como-eu-uso-ia-no-desenvolvimento/</link><pubDate>Wed, 22 Jul 2026 00:00:00 -0300</pubDate><guid>https://www.rafaelvzago.com/en/posts/como-eu-uso-ia-no-desenvolvimento/</guid><description>&lt;p>&lt;a href="https://www.rafaelvzago.com/assets/img/headers/como-eu-uso-ia-no-desenvolvimento.png" class="img-lightbox" data-lightbox>
	&lt;img src="https://www.rafaelvzago.com/assets/img/headers/como-eu-uso-ia-no-desenvolvimento.png" alt="" loading="lazy" decoding="async">
&lt;/a>&lt;/p>
&lt;p>The question I hear most about day-to-day AI is not &amp;ldquo;which model do you use?&amp;rdquo; It is &amp;ldquo;how do you organize this so it does not turn into a mess?&amp;rdquo;&lt;/p>
&lt;p>I use AI constantly, in code and on this blog. What changed my routine was not a miracle prompt. It was treating the agent like someone who joins the project with no context: if the rule is not in a file, it does not exist. Skills, &lt;code>AGENTS.md&lt;/code>, agents with narrow roles, and me reviewing the result. No magic.&lt;/p></description></item><item><title>Claude Code: from PRD to pull request with agents</title><link>https://www.rafaelvzago.com/en/posts/claude-code-automatizando-workflow-prd-pr/</link><pubDate>Fri, 08 May 2026 00:00:00 -0300</pubDate><guid>https://www.rafaelvzago.com/en/posts/claude-code-automatizando-workflow-prd-pr/</guid><description>&lt;p>&lt;a href="https://www.rafaelvzago.com/assets/img/headers/claude-code-automatizando-workflow-prd-pr.png" class="img-lightbox" data-lightbox>
	&lt;img src="https://www.rafaelvzago.com/assets/img/headers/claude-code-automatizando-workflow-prd-pr.png" alt="" loading="lazy" decoding="async">
&lt;/a>&lt;/p>
&lt;h2 id="introduction">Introduction&lt;/h2>
&lt;p>I discovered Claude Code a few months ago when our team was struggling to keep code reviews consistent. After six weeks with the tool, we cut average PR time from 4 days to 1 day — and that was only the start.&lt;/p>
&lt;p>Claude Code automates a large part of the development workflow. PRDs, TDD, code review, even MCP setup. It is not magic, but it works well enough to change the day-to-day.&lt;/p></description></item><item><title>OpenShift Service Mesh 3: what changes with Istio</title><link>https://www.rafaelvzago.com/en/posts/openshift-service-mesh-3/</link><pubDate>Mon, 07 Jul 2025 00:00:00 -0300</pubDate><guid>https://www.rafaelvzago.com/en/posts/openshift-service-mesh-3/</guid><description>&lt;p>&lt;a href="https://www.rafaelvzago.com/assets/img/headers/openshift-service-mesh-3.png" class="img-lightbox" data-lightbox>
	&lt;img src="https://www.rafaelvzago.com/assets/img/headers/openshift-service-mesh-3.png" alt="" loading="lazy" decoding="async">
&lt;/a>&lt;/p>
&lt;h2 id="overview">Overview&lt;/h2>
&lt;p>&lt;a href="https://www.redhat.com/en/technologies/cloud-computing/openshift/what-is-openshift-service-mesh">OpenShift Service Mesh&lt;/a> 3 (OSSM3) replaces Maistra with upstream Istio as the core of the solution. Maistra was a Red Hat-maintained custom fork of Istio; with OSSM3, the base is Istio straight from the community project — no custom patches, no rebase.&lt;/p>
&lt;p>Concrete changes include: control plane upgrades can be in-place or revision-based (canary), Kiali must be installed separately via the Kiali Operator, and multi-cluster support uses the standard upstream Istio topologies.&lt;/p></description></item><item><title>Jenkins CasC: high-performance pipelines with GitOps</title><link>https://www.rafaelvzago.com/en/posts/dominando-pipelines-de-alta-performance/</link><pubDate>Fri, 13 Jun 2025 00:00:00 -0300</pubDate><guid>https://www.rafaelvzago.com/en/posts/dominando-pipelines-de-alta-performance/</guid><description>&lt;p>&lt;a href="https://www.rafaelvzago.com/assets/img/headers/dominando-pipelines-de-alta-performance.png" class="img-lightbox" data-lightbox>
	&lt;img src="https://www.rafaelvzago.com/assets/img/headers/dominando-pipelines-de-alta-performance.png" alt="" loading="lazy" decoding="async">
&lt;/a>&lt;/p>
&lt;h2 id="the-need-to-evolve-challenges-of-basic-jenkins">The Need to Evolve: Challenges of &amp;ldquo;Basic&amp;rdquo; Jenkins&lt;/h2>
&lt;p>Jenkins is one of the most powerful and popular automation servers in the world. It drives countless CI/CD pipelines that build, test, and deploy applications. Managed only through the web UI — what many call &amp;ldquo;ClickOps&amp;rdquo; — it shows its weak spots.&lt;/p>
&lt;p>ClickOps creates problems that hurt agility and reliability on any project, especially in complex MLOps environments:&lt;/p>
&lt;ul>
&lt;li>&lt;strong>No versioning or audit trail:&lt;/strong> Who changed a job config? Why? Without version control those questions are almost impossible to answer. Rolling back a bad change becomes a manual treasure hunt.&lt;/li>
&lt;li>&lt;strong>Inconsistency and hard reproducibility:&lt;/strong> Cloning a Jenkins environment for development, staging, or disaster recovery is painful and error-prone. Small config drifts between environments cause unexpected failures.&lt;/li>
&lt;li>&lt;strong>Painful scale and maintenance:&lt;/strong> Managing dozens or hundreds of jobs by hand does not scale. Maintenance becomes a bottleneck, and consistency across projects stays out of reach.&lt;/li>
&lt;/ul>
&lt;p>To get the reliability, speed, scale, and security modern projects need, you have to go beyond the basics.&lt;/p></description></item><item><title>Who am I? About Rafael Zago</title><link>https://www.rafaelvzago.com/en/posts/quem-sou-eu/</link><pubDate>Mon, 04 Dec 2023 00:00:00 -0300</pubDate><guid>https://www.rafaelvzago.com/en/posts/quem-sou-eu/</guid><description>&lt;p>&lt;a href="https://www.rafaelvzago.com/assets/img/headers/quem-sou-eu-hero.webp" class="img-lightbox" data-lightbox>
	&lt;img src="https://www.rafaelvzago.com/assets/img/headers/quem-sou-eu-hero.webp" alt="" loading="lazy" decoding="async">
&lt;/a>&lt;/p>
&lt;h2 id="introduction">Introduction&lt;/h2>
&lt;p>Qué pasa?&lt;/p>
&lt;p>Hi. Don&amp;rsquo;t take me too seriously, okay? I built this space to share a bit of what I know—and about 90% of it came from the internet. So it was past time to give some of it back.&lt;/p>
&lt;p>Today I&amp;rsquo;m a senior software automation engineer at Red Hat. Before that I bounced through a few companies, small and large, doing a bit of everything:&lt;/p>
&lt;ul>
&lt;li>DevOps at heart, sysadmin by vocation.&lt;/li>
&lt;li>Building learning methods and structuring training.&lt;/li>
&lt;li>Years of application support across all sizes and complexity levels.&lt;/li>
&lt;li>Instructor at Caelum/Alura.&lt;/li>
&lt;li>Godfather to the coolest kid on the planet. No bias here…&lt;/li>
&lt;/ul>
&lt;h2 id="communities">Communities&lt;/h2>
&lt;p>I&amp;rsquo;m a DevOps person at heart and also part of the DevOpsDays SP organizing team.&lt;/p></description></item><item><title>CI/CD upstream vs downstream: when to use each</title><link>https://www.rafaelvzago.com/en/posts/ci-cd-downstream-upstream/</link><pubDate>Fri, 02 Jun 2023 00:00:00 -0300</pubDate><guid>https://www.rafaelvzago.com/en/posts/ci-cd-downstream-upstream/</guid><description>&lt;p>&lt;a href="https://www.rafaelvzago.com/assets/img/headers/ci-cd-downstream-upstream-hero.webp" class="img-lightbox" data-lightbox>
	&lt;img src="https://www.rafaelvzago.com/assets/img/headers/ci-cd-downstream-upstream-hero.webp" alt="" loading="lazy" decoding="async">
&lt;/a>&lt;/p>
&lt;h2 id="integrating-skupper-upstream-and-downstream">Integrating Skupper upstream and downstream&lt;/h2>
&lt;p>Integrating upstream and downstream projects is rarely simple. Here is a practical approach for Skupper on the upstream side and its commercial downstream line, using familiar tools for each side of the work.&lt;/p>
&lt;h2 id="introduction">Introduction&lt;/h2>
&lt;p>Skupper is an open-source project that provides a service network for Kubernetes. It is developed by Red Hat and released under the Apache 2.0 license. That is the upstream version—the one under active development.&lt;/p></description></item><item><title>Skupper: multicloud app network in a few commands</title><link>https://www.rafaelvzago.com/en/posts/multicloud-com-skupper/</link><pubDate>Sat, 01 Oct 2022 00:00:00 -0300</pubDate><guid>https://www.rafaelvzago.com/en/posts/multicloud-com-skupper/</guid><description>&lt;p>&lt;a href="https://www.rafaelvzago.com/assets/img/headers/multicloud-com-skupper-hero.webp" class="img-lightbox" data-lightbox>
	&lt;img src="https://www.rafaelvzago.com/assets/img/headers/multicloud-com-skupper-hero.webp" alt="" loading="lazy" decoding="async">
&lt;/a>&lt;/p>
&lt;h2 id="references-and-technologies-used">References and technologies used&lt;/h2>
&lt;ol>
&lt;li>&lt;a href="https://skupper.io">https://skupper.io&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://minikube.sigs.k8s.io">https://minikube.sigs.k8s.io&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://github.com/skupperproject/skupper-example-hello-world">Repository with the code&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://qpid.apache.org/components/dispatch-router/index.html">Qpid-dispatch&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://activemq.apache.org/">ActiveMQ&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/">Kubectl&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://kubernetes.io/docs/home/">Kubernetes&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://en.wikipedia.org/wiki/Transport_Layer_Security">MTLS&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://en.wikipedia.org/wiki/Open_source">Open-source&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://github.com/skupperproject/skupper-router">Skupper-router&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://github.com/skupperproject/skupper">Skupper&lt;/a>&lt;/li>
&lt;/ol>
&lt;h2 id="tools">Tools&lt;/h2>
&lt;ul>
&lt;li>A computer with minikube [2] installed;&lt;/li>
&lt;li>A terminal to run the commands;&lt;/li>
&lt;li>&lt;code>kubectl&lt;/code> &amp;gt; 1.15 [6] or newer.&lt;/li>
&lt;/ul>
&lt;h2 id="solution-overview">Solution overview&lt;/h2>
&lt;p>Skupper [1] lets you connect two or more cloud environments in a non-intrusive, secure way. Those environments can sit on different cloud providers—AWS, GCP, Azure, and others—or on native Kubernetes clusters.&lt;/p></description></item></channel></rss>