CI · CD
Continuous Integration / Continuous Delivery
What is CI?
- CI = merging code often
- CD = automated checks & release
- Fast, safe releases
When CI/CD arrives, the first thing that changes isn't the code but the team's calendar. Deployment goes from 'a Friday-night event everyone gathers for' to 'something that happens twenty times on a weekday afternoon.' Each release carries a smaller batch of changes, so when something breaks, the list of suspects narrows to a few lines and rolling back takes less time. What changes isn't so much speed as the confidence that you can undo a release, and from then on developers start touching the code they were afraid to touch.
CD splits into two. Continuous Delivery automates everything up to a release-ready state but leaves the final release button to a person, while Continuous Deployment pushes straight to production once checks pass, with no approval. Teams under regulatory review or a change control register, such as in finance and healthcare, usually choose the former. One practical condition applies: the pipeline from build to test must finish within 10 minutes. Developers will wait for results that fast; at 30 minutes everyone moves on to the next task and CI becomes an empty shell. Health is tracked with four metrics: deployment frequency, change lead time, change failure rate and recovery time. Keep the distinction clear, too: CI/CD is the tooling, and DevOps is the way of working that runs it.
You don't need to automate the whole path from day one. Teams usually go one step at a time: automated build → automated tests → automatic staging deploys → production deploys. For production, they add canary releases (opening to a small group of users first) or blue-green deployment (switching over while keeping the old version running) to shrink the blast radius of any incident. If you use an environment like vibe coding where a repository is connected to a hosting service, half of CD already comes built in, so the remaining work is filling in the testing stage.
The most common mistake is the illusion that 'it's automated, so it's safe.' A pipeline with no real tests is just a device for shipping defective products faster. Leave red builds unattended and force-merge 'because it's urgent' a few times, and within two months nobody trusts the test results. Let branches sit for two weeks and merge them all at once, and it's integration in name only, with the same merge-conflict hell. Incidents where deployment keys or DB passwords are hardcoded in config files and the repository is then made public, leaking production DB credentials wholesale, are not rare either. An organization that has never practiced a rollback ends up logging into the server directly in the middle of the night at its first outage.
Seungtae ParkHands-on AX instructor who teaches AI business development and marketing automation by building real systems
John KimInstructor John Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”Continuous integration (CI) was emphasized in Extreme Programming (XP) and popularized by Martin Fowler and others. It later matured into the CI/CD pipeline alongside cloud and automation tools.
Consider a hypothetical case. Company A, an online education platform with 210 employees and KRW 48 billion (≈ US$35,912,000) in annual revenue, had 11 developers deploying by hand at 10 p.m. on one Friday a month. Each deployment averaged 3 hours 30 minutes, and in 3 of the past 6 months they had rolled back in the early morning hours, leaving more than 200 customer service inquiries piled up. The CTO declared, 'I can no longer delay feature releases because we are afraid to deploy,' and launched an eight-week pipeline build.
- For the first two weeks, the backend lead skipped full coverage and started with the revenue-critical paths, payments and course enrollment, writing 47 automated tests.
- The DevOps lead set up a pipeline that runs build and tests on every push. It took 22 minutes at first, so they split the tests to run in parallel and cut it to about 7 minutes.
- In week 4, once automatic staging deploys were switched on, the QA manager said, 'I no longer have to chase people on messenger to ask them to check this,' and review wait time dropped from a day to 30 minutes.
- For production, we kept an approval button in place and ran a canary release that sends traffic to just 5% of users first. In week 6 it caught a payment error, and we rolled back within 4 minutes, so only 31 users were affected.
- Eight weeks later, deployments went from once a month to nine a week, time per deployment fell from 3 hours 30 minutes to 12 minutes, and rollback incidents, three in the previous half year, dropped to zero.