CI/CD란? 자동화로 빠르게 배포하기

출처: Dev.to

https://dev.to/sailee_shingare

By Sailee Shingare | M. S. in Computer Science, Northern Illinois University (NIU)

You’ve written your code. You’ve tested it. Now you need to get it to production.

In the old days, this meant manually copying files to a server, crossing your fingers, and hoping nothing broke. Deployments were stressful, infrequent, and error‑prone.

CI/CD changed all of that.

What is CI/CD?

CI/CD stands for Continuous Integration and Continuous Deployment (or Continuous Delivery). It’s a practice of automating the steps between writing code and running it in production.

Instead of manually building, testing, and deploying — CI/CD does it all automatically every time you push code.

Think of it as an assembly line for your software.

Continuous Integration (CI)

Continuous Integration is the practice of automatically building and testing your code every time a developer pushes a change.

Here’s what happens:

• Developer writes code and pushes to GitHub
• CI system automatically detects the change
• It builds the application
• It runs all tests
• It reports back — pass or fail

If tests pass, the code is good. If they fail, the developer is notified immediately before the bad code reaches anyone else.

The key benefit: Catch bugs early, when they’re cheap to fix — not after they’ve reached production.

Continuous Deployment (CD)

Continuous Deployment takes CI one step further — it automatically deploys your code to production after it passes all tests.

No human intervention. No manual steps. Code passes tests → code goes live. Automatically.

Continuous Delivery is slightly different — it automates deployment to a staging environment but requires a manual approval before production. Many teams prefer this for an extra layer of control.

The CI/CD Pipeline

A pipeline is the automated series of steps your code goes through from commit to production.

A typical pipeline looks like this:

코드 푸시 → 빌드 → 테스트 → 보안 스캔 → 스테이징에 배포 → 프로덕션에 배포

Each step is a gate. If any step fails, the pipeline stops and alerts the team. Nothing broken ever reaches production.

A Real Pipeline Example

Here’s a simple CI/CD pipeline using GitHub Actions:

name: CI/CD Pipeline
on:
  push:
    branches: [ main ]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
     - name: Checkout code
       uses: actions/checkout@v3

     - name: Set up Python
       uses: actions/setup-python@v4
       with:
         python-version: '3.11'

     - name: Install dependencies
       run: pip install -r requirements.txt

     - name: Run tests
       run: pytest tests/

     - name: Build Docker image
       run: docker build -t myapp:${{ github.sha }} .

     - name: Deploy to production
       run: echo "Deploying to production..."

Enter fullscreen mode
Exit fullscreen mode

Every time code is pushed to the main branch, this pipeline automatically installs dependencies, runs tests, builds a Docker image, and deploys. No manual steps needed.

Popular CI/CD Tools

• GitHub Actions — Built into GitHub, free for public repos, easiest to get started with
• Jenkins — Open source, highly customizable, widely used in enterprises
• Azure DevOps Pipelines — Microsoft’s CI/CD solution, integrates perfectly with Azure
• GitLab CI — Built into GitLab, powerful and flexible
• CircleCI — Cloud-based, fast and developer friendly
• AWS CodePipeline — Amazon’s native CI/CD service, integrates with AWS services

Why CI/CD Matters

Before CI/CD:

• Deployments happened once a month
• Every deployment was stressful
• Bugs were found weeks after being written
• Teams worked in isolation for weeks then merged everything at once — causing massive conflicts

After CI/CD:

• Deployments happen multiple times per day
• Deployments are boring and routine
• Bugs are caught within minutes of being written
• Small changes are integrated continuously — conflicts are rare and small
• Companies like Amazon deploy to production thousands of times per day — all powered by CI/CD.

Key Benefits

• Faster delivery — ship features in hours not months
• Higher quality — automated tests catch bugs before users do
• Less risk — small frequent deployments are safer than large infrequent ones
• Less manual work — engineers focus on building, not deploying
• Faster feedback — know immediately if your code broke something

Try it Yourself

GitHub Actions is the easiest way to try CI/CD for free:

Create a free account at github.com:

• Create a new repository
• Add a simple Python script
• Create a file at .github/workflows/ci.yml
• Paste this:

name: My First Pipeline
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
     - uses: actions/checkout@v3
     - name: Run a script
       run: echo "CI/CD is working!"

Enter fullscreen mode
Exit fullscreen mode

• Push your code — go to the Actions tab in GitHub
• Watch your pipeline run automatically

You just built your first CI/CD pipeline.

What’s Next?

Now you know how to automate your deployments with CI/CD. But what about the infrastructure those deployments run on? Servers, networks, databases — all of that needs to be set up too. And just like application code, infrastructure can be automated and version‑controlled. That’s Infrastructure as Code — and we’ll cover it in the next post with a deep dive into Terraform.