[DevOps] Github Action과 필요한 개념정리.

Data-Forge : 데이터로 세상 이해해보기.·2025년 10월 20일

데브옵스

목록 보기

3/3

[DevOps] Github Action과 필요한 개념정리.

▽ [DevOps] Github Action과 필요한 개념정리.

목      차

1. CI/CD란 무엇이고 왜 필요할까?

2. Github Action이란

3. Github Action 명령어 사용법

1. CI/CD란 무엇이고 왜 필요할까?

DevOps 철학 : 문화, 프로세스, 도구의 결합.

DevOps (Development + Operations)는 단순히 도구의 집합이 아니라, 소프트웨어 개발과 IT 운영 팀 간의 협업과 자동화를 강조하는 문화적, 전문적 변화.

목표는 소프트웨어를 더 빠르게, 더 안정적으로, 더 자주 배포하는 것.

직군별 초점(백엔드/데브옵스/데이터엔지니어)

CI/CD란 무엇인가??

CI/CD는 개발 프로세스의 반복적인 부분을 자동화하는 일련의 관행을 의미하며,
DevOps 문화의 핵심적인 기술 구현체.

CI/CD의 목적은?

반복적인 일(빌드,테스트,배포 작업 등)들을 처리하고 문제가 있을 때 경고를 해주는 등
'자동화된 파이프라인'을 통해서 코드 변경과 배포 단계를 원활하게 진행 가능.

즉, 자동화를 통해 시간 절약 및 휴먼에러를 관리 가능함.

CI: 지속적 통합(Continuous Integration)

정의.

개발자들이 각자의 작업 코드를 공유 레포지토리에 자주 통합(Merge)하는 관행.
코드를 통합할 때마다 자동화된 "빌드(Build) 및 테스트(Test)"를 실행하여 문제가 없는지 검증 가능.
- 추가,변경(push나 pull request)된 코드를 빌드하고 테스트 하는 프로세스를 자동화하는 것
- 위와 같은 프로세스를 거친후에 병합(통합) 즉, 코드를 merge해주는 것
- 다수의 인원이 함께 개발할때 충돌과 같은 일들을 미연에 방지 가능하며
  Lint(코드 규칙)를 잘 지켰는지, 제대로 동작하는지 등 확인가능

목표.

코드 통합 과정에서 발생하는 충돌이나 오류를 조기에 발견하고 해결하여, 메인 브랜치의 코드 품질과 안정성을 지속적으로 유지하는 것.

CD : 지속적 제공/배포(Cotinuous Delivery / Continuous Deployment)

CI를 통과하여 안정성이 검증된 코드를 사용자에게 제공하는 단계.

Delivery과정은 CI 과정을 거친후에 병합하여 실행테스트를 할 수 있도록 하는 것

Deployment는 뜻 그대로 배포 과정을 자동으로 처리 해주는 것

지속적 제공(Continuous Delivery, CDe)

의미
: 코드가 테스트를 통과하고 릴리스 준비가 완료된 상태로
"배포 가능한 저장소"에 항상 유지되는 것.
최종 단계
: "수동 승인" 후 실제 운영 환경에 배포.

지속적 배포(Continuous Deployment, CDp)

의미
: 코드가 테스트를 통과하면 사람의 개입 없이 자동으로 운영 환경까지 릴리스되는 것
최종 단계
: "자동 배포"까지 완료.

CI/CD는 왜 필요할까??

CI/CD는 개발 팀의 효율성을 극대화하고, 사용자에게 더 빠르고 안정적인 서비스를 제공하기 위해 필수적.

개발 속도 향상 및 효율성 극대화.

배포 주기의 단축
: 수동 배포에 드는 시간과 노력을 자동화하여,
새로운 기능을 몇 시간 또는 몇 분 만에 릴리스 가능.
- 시장 변화에 민첩하게 대응 가능하게 해줌.

개발 집중
: 개발자가 반복적이고 지루하며 실수하기 쉬운 빌드, 테스트, 배포 작업 대신
핵심적인 코딩 및 문제 해결에 집중할 수 있도록 함.

위험 감소 및 코드 품질 향상.

오류의 조기 발견(CI)
: 코드를 자주 통합하고 테스트하기 때문에, 버그가 큰 문제로 발전하기 전에 작은 단계에서 즉시 발견하고 수정 가능.
- 통합 문제(Integration Hell)를 방지.
안정적인 릴리스(CD)
: 자동화된 테스트를 거친 코드만 배포되므로, 수동 배포 과정에서 발생하는 사람의 실수(Human Error)가 줄어들고 서비스의 안정성이 높아짐.
신속한 롤백
: 배포 실패나 심각한 운영 문제가 발생할 경우, CI/CD 파이프라인을 통해 이전의 안정적인 버전으로 신속하게 롤백(Rollback)하는 과정을 자동화할 수 있어 서비스 중단을 최소화.

협업 강화 및 피드백 루프 단축.

투명성
: 모든 팀원(개발, QA, 운영)이 빌드, 테스트, 배포의 진행 상황을
실시간으로 모니터링할 수 있어 협업이 투명.

피드백 가속화
: 사용자나 테스터의 피드백이 서비스에 반영되는 시간이 짧아져,
제품 개선이 지속적으로 이루어지는 선순환 구조.

CI/CD 파이프라인의 필수 구성 요소

현업의 CI/CD 파이프라인은 단순히 빌드와 배포를 넘어서 다양한 검증 단계를 포함.

$\text{CI} \rightarrow \text{코드 분석/보안 스캔} \rightarrow \text{테스트 (단위/통합)} \rightarrow \text{Artifact 생성} \rightarrow \text{CD (배포)} \rightarrow \text{모니터링 연동}$

데브옵스 관점
: 파이프라인 내에 terraform plan (IaC 검증) Job이나 SonarQube Scan (코드 품질) Job을
의무적으로 포함하여 안정성을 강화.
데이터 엔지니어 관점
: dbt test나 데이터 품질 검사 Job을 포함하여, 데이터셋에 대한 변경이 파이프라인에 통합되기 전에 검증.

2. Github Action이란

GitHub Actions는 GitHub 저장소 내부에서 소프트웨어 개발 워크플로를 자동화, 사용자 지정 및 실행할 수 있도록 하는 CI/CD 및 자동화 플랫폼.

1. GitHub Actions의 기본 개념.

GitHub Actions는 이벤트 기반 자동화 엔진으로, GitHub 리포지토리에서 발생하는 특정 이벤트(예: 코드 푸시, 풀 리퀘스트 생성 등)를 감지하여 일련의 자동화된 작업(Workflow)을 실행.

자동화된 워크플로 (Automated Workflow)

YAML 기반:
- 모든 자동화 로직은 리포지토리의 .github/workflows 디렉터리 내에
  YAML 파일 형식으로 정의.
통합 환경 :
- 코드가 있는 동일한 플랫폼(GitHub) 내에서
  CI/CD 및 기타 자동화 작업을 처리함으로써,
  별도의 외부 CI 서버(예: Jenkins)를 구축하고 연동할 필요성을 없애줌.

주요 구성 요소(Components)

GitHub Action의 현업 활용 범위(Beyond CI/CD)

GitHub Actions는 단순히 CI/CD(빌드/테스트/배포)뿐만 아니라, 리포지토리 관리 및 개발 프로세스 전반을 자동화하는 데 사용.

활용 분야 : 백엔드/데브옵스 개발자 관점.

CI/CD

코드 푸시 시 Docker 이미지 빌드 및 EKS/EC2에 자동 배포.

코드 품질

Pull Request 시 정적 분석 도구(SonarCloud, Lint) 실행 및 결과 보고.

인프라 관리

Terraform 코드 변경 시 terraform plan 실행 결과를 PR에 댓글로 자동 게시.

자동화 관리

오래된 브랜치나 이슈 자동 종료, 릴리스 노트 자동 생성.

활용 분야 : 데이터 엔지니어 관점.

CI/CD

Airflow DAGs 변경 시 Syntax 검사 후 Airflow 서버로 자동 동기화.

코드 품질

dbt test 또는 Great Expectations를 실행하여 데이터 품질 사전 검증.

인프라 관리

데이터셋 변경 이벤트 발생 시 ML 모델 학습 파이프라인 자동 트리거.

자동화 관리

주기적인 Cron 기반 스케줄링으로 데이터 통계 생성 및 Slack 알림.

심화 개념.

Secrets 및 Environment를 통한 보안 관리

현업에서는 환경 변수 대신 GitHub Secrets를 사용하여 민감 정보를 안전하게 주입.

Environment (배포 환경) :
- 개발, 스테이징, 운영 등 환경별로 Job을 분리하고,
  각 환경에 필요한 Secret을 할당하여 격리 관리.
수동 승인 (Approval) :
- 운영 환경(Production Environment) 배포 시 Required reviewers 기능을 통해
  특정 팀 리더나 데브옵스 엔지니어의 수동 승인 없이는 Job이 실행되지 않도록 설정.

Caching 전략을 통한 성능 최적화

CI의 실행 시간을 줄이는 가장 중요한 방법.

actions/cache :
- Node Modules, Maven .m2, Python .venv 등 의존성 파일을 캐시하여 반복적인 설치 시간을 제거.
- 캐시 키를 package-lock.json이나 pom.xml의 해시값에 연동하여 정확한 복원(Hit)율을 유지하는 것이 핵심.

Job 간의 데이터 공유 (Artifacts)

Job은 독립적인 환경에서 실행되므로, 파일이나 데이터 공유를 위해 Artifacts를 사용.

활용 예시:
- 빌드 Job: JAR 파일(Artifact)을 업로드.
- 테스트 Job: 업로드된 JAR 파일을 다운로드하여 통합 테스트 실행.
- 배포 Job: JAR 파일을 다운로드하여 운영 서버에 배포.

Self-hosted Runner (데브옵스 관점)

필요성 :
- GitHub 호스팅 러너의 제한적인 사양이나 시간을 초과하는
  대용량 작업(예: 대규모 데이터 처리, 무거운 빌드)이 필요할 때,
- 또는 기업 내부망(VPC)에만 접근 가능한 리소스에 배포해야 할 때 사용.
장점 : 비용 절감 및 인프라 환경 사용자 정의가 가능.

3. Github Action 명령어 사용법

셀 명령어 직접 실행: run

run 키워드는 Runner(가상 환경)의 기본 셸(Bash, PowerShell 등)을 사용하여 스크립트나 명령어를 실행할 때 사용.

기본 사용법.

가장 일반적인 형태는 단일 명령어를 실행하는 것

YAML

steps:
  - name: Install Dependencies
    run: npm install # 단일 셸 명령어 실행

멀티라인 스크립트 사용.

여러 줄의 명령어를 순차적으로 실행해야 할 때는 YAML의 파이프(|) 문법을 사용.
이는 특히 복잡한 빌드나 환경 설정을 할 때 유용.

YAML

steps:
  - name: Build and Test Application
    run: | # 파이프 문법으로 여러 줄의 셸 명령어 실행
      echo "Starting build process..."
      npm run build
      npm run test
      echo "Build successful."

환경 변수 사용.

Step이나 Job 레벨에서 정의된 환경 변수(env)를 셸 스크립트 내에서 사용.

YAML

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      NODE_ENV: production # Job 레벨 환경 변수

    steps:
      - name: Deploy to Server
        env:
          TARGET_HOST: ${{ secrets.SERVER_IP }} # Step 레벨 환경 변수 (Secrets 사용)
        run: |
          echo "Deploying to $TARGET_HOST in $NODE_ENV mode."
          ssh user@$TARGET_HOST 'sudo systemctl restart api-server'

재사용 가능한 액션 사용: uses

uses 키워드는 미리 정의되고 패키징된 Action을 가져와 실행할 때 사용.
이는 복잡한 설정 과정을 한 줄로 단순화하여 Workflow의 가독성과 효율성을 높여줌.

기본 사용법 및 버전 관리

{소유자}/{리포지토리}@{버전} 형태로 Action을 지정하며, 안정성을 위해 특정 버전(태그, 커밋 SHA)을 명시하는 것

YAML

steps:
  - name: Checkout Code
    uses: actions/checkout@v4 # GitHub 공식 Action 사용

  - name: Set up Python
    uses: actions/setup-python@v5 # 서드파티 Action 사용
    with:
      python-version: '3.11' # Action의 입력 값(Input) 지정

액션의 입력 (with)

대부분의 Action은 with 키워드를 통해 설정을 위한 입력 값(Input)을 받습니다. 이는 Action의 동작 방식을 사용자 정의할 때 사용

YAML

steps:
  - name: AWS Credentials Setup
    uses: aws-actions/configure-aws-credentials@v4
    with:
      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} # Secrets을 입력으로 전달
      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      aws-region: ap-northeast-2

액션 결과 사용 (Outputs)

일부 Action은 실행 결과를 출력 값(Output)으로 제공합니다. 이 출력 값은 Step ID와 outputs 컨텍스트를 사용하여 후속 Step에서 접근가능.

YAML

steps:
  - name: Get Short Commit SHA
    id: get_sha # 이 Step에 ID 지정
    run: echo "short_sha=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT
    # get_sha Step의 출력 값으로 short_sha 정의

  - name: Tag and Push Docker Image
    run: docker push my-repo/my-image:${{ steps.get_sha.outputs.short_sha }}
    # 이전 Step의 출력 값을 사용하여 Docker 태그에 적용

심화 명령어 제어: 조건부 실행

IF 조건문

if 키워드를 사용하여 표현식(Expression) 기반의 조건을 정의.

YAML

steps:
  - name: Deploy to Production
    if: github.ref == 'refs/heads/main' && success()
    # main 브랜치에 대한 push 이벤트이고, 이전 Step/Job이 성공했을 때만 실행
    run: echo "Initiating production deployment..."

상태 함수 활용

if 문에서 사용할 수 있는 기본 상태 함수는 다음과 같음.

YAML

steps:
  - name: Send Failure Notification
    if: failure() # 이전 Job/Step이 실패했을 때만 실행
    uses: slackapi/slack-notify-action@v1
    # ... 알림 설정

Data-Forge : 데이터로 세상 이해해보기.

Roll with the punches

이전 포스트

[DevOps] Github Action과 필요한 개념정리.

데브옵스

[DevOps] Github Action과 필요한 개념정리.

▽ [DevOps] Github Action과 필요한 개념정리.

1. CI/CD란 무엇이고 왜 필요할까?

DevOps 철학 : 문화, 프로세스, 도구의 결합.

직군별 초점(백엔드/데브옵스/데이터엔지니어)

CI/CD란 무엇인가??

CI/CD의 목적은?

CI: 지속적 통합(Continuous Integration)

정의.

목표.

CD : 지속적 제공/배포(Cotinuous Delivery / Continuous Deployment)

지속적 제공(Continuous Delivery, CDe)

지속적 배포(Continuous Deployment, CDp)

CI/CD는 왜 필요할까??

개발 속도 향상 및 효율성 극대화.

위험 감소 및 코드 품질 향상.

협업 강화 및 피드백 루프 단축.

CI/CD 파이프라인의 필수 구성 요소

2. Github Action이란

1. GitHub Actions의 기본 개념.

자동화된 워크플로 (Automated Workflow)

주요 구성 요소(Components)

GitHub Action의 현업 활용 범위(Beyond CI/CD)

활용 분야 : 백엔드/데브옵스 개발자 관점.

CI/CD

코드 품질

인프라 관리

자동화 관리

활용 분야 : 데이터 엔지니어 관점.

CI/CD

코드 품질

인프라 관리

자동화 관리

심화 개념.

Secrets 및 Environment를 통한 보안 관리

Caching 전략을 통한 성능 최적화

Job 간의 데이터 공유 (Artifacts)

Self-hosted Runner (데브옵스 관점)

3. Github Action 명령어 사용법

셀 명령어 직접 실행: run

기본 사용법.

멀티라인 스크립트 사용.

환경 변수 사용.

재사용 가능한 액션 사용: uses

기본 사용법 및 버전 관리

액션의 입력 (with)

액션 결과 사용 (Outputs)

심화 명령어 제어: 조건부 실행

IF 조건문

상태 함수 활용

[DevOps] Docker와 Kubernetes의 기본 개념 공부.

0개의 댓글