<?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 Chen Kai Blog</title><link>https://www.chenk.top/en/tags/ci/cd/</link><description>Recent content in CI/CD on Chen Kai Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 09 May 2026 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/en/tags/ci/cd/index.xml" rel="self" type="application/rss+xml"/><item><title>Alibaba Cloud Full Stack (12): End-to-End — One Terraform Apply for Everything</title><link>https://www.chenk.top/en/aliyun-fullstack/12-terraform-e2e/</link><pubDate>Sat, 09 May 2026 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/aliyun-fullstack/12-terraform-e2e/</guid><description>&lt;p>Eleven articles. Dozens of CLI commands. Hundreds of manual steps. Now we throw all of that away and rebuild the entire stack with a single &lt;code>terraform apply&lt;/code>. This is why infrastructure-as-code exists.&lt;/p>
&lt;p>Over the past eleven parts of this series, we have clicked through consoles, typed &lt;code>aliyun&lt;/code> CLI commands, and manually configured everything from VPCs to Function Compute triggers. It worked. We learned every resource intimately because we built each one by hand. But if I asked you right now to recreate that entire stack in a new region — the VPC with its three tiers and two availability zones, the ECS instance with its cloud-init script, the RDS MySQL HA setup, the OSS bucket with lifecycle rules, the RAM policies, the SLS log pipeline, the Function Compute event processing — you would need at least a full day of careful work. And you would inevitably miss something. A security group rule. A backup policy. A CORS configuration.&lt;/p></description></item><item><title>Cloud Computing (7): Cloud Operations and DevOps Practices</title><link>https://www.chenk.top/en/cloud-computing/operations-devops/</link><pubDate>Fri, 26 May 2023 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/cloud-computing/operations-devops/</guid><description>&lt;p>&lt;figure class="article-figure">
 &lt;img src="https://blog-pic-ck.oss-cn-beijing.aliyuncs.com/posts/en/cloud-computing/operations-devops/illustration_1.png" alt="Cloud Computing (7): Cloud Operations and DevOps Practices — Chapter overview" loading="lazy" decoding="async" class="content-image">
 
&lt;/figure>
&lt;/p>
&lt;p>In 2017 GitLab lost six hours of database state. An engineer, exhausted, ran &lt;code>rm -rf&lt;/code> on the wrong server during an incident. The backup procedures had silently been broken for months; nobody noticed because no one was restoring from backups. The lesson is not &amp;ldquo;be careful with rm&amp;rdquo;. The lesson is that operations is a &lt;em>system&lt;/em> — tools, runbooks, monitoring, automation, and the rituals around them. When the system is healthy, no single tired engineer can take down production. When the system is rotten, every late-night fix is one keystroke from disaster.&lt;/p></description></item></channel></rss>