CI/CD 와 github actions

CI/CD

 

CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미

"CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미

 

 

 

지속적 통합(Continuous Integration, CI)

개발자를 위한 자동화 프로세스

• Code : 개발자가 코드를 원격 코드 저장소 (Ex. github repository)에 push
• Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드
• Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인

모든 코드 변화를 하나의 리포지토리에서 관리하는 것 부터 시작

잦은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합

지속적 통합으로 보안 이슈, 에러 등을 쉽게 파악할 수 있어 해당 이슈를 빠르게 개선

 

지속적 배포(Continuous Delivery/Deployment, CD)

지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미

 

• Release : 배포 가능한 소프트웨어 패키지를 작성
• Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출합니다. 실질적인 배포
• Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지

 

코드 변경 사항의 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계로, 테스트 자동화와 코드 배포 자동화가 포함

프로세스를 완료하면 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 배포할 수 있기 때문에 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포

 

CI/CD 파이프라인

 

개발자가 코드를 원격 저장소에 올리면, 그 코드가 빌드 및 테스트와 릴리즈를 거쳐 배포 서버로 전달

배포 서버에 도달한 빌드된 코드는 애플리케이션 서버로 최종 배포가 완료

그 결과물을 유저가 직접 확인하게 되는 것

 

자동화를 꾀하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계

이 부분을 지속적인 통합 및 배포를 위하여 일련의 자동화 단계로 만드는데, 이것을 파이프라인을 구축한다고 표현

 

CI/CD 파이프라인을 구성하는 기본 단계와 수행 작업

 

배포에서 파이프라인(Pipeline)이란 용어는 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조

 

대표적으로 쓰이는 세 가지 단계가 존재

1. Source 단계: Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행
2. Build 단계: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공. 또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행
3. Deploy 단계: Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행

 

Github Actions

Github가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼

레포지토리에서 Pull Request 나 push 같은 이벤트를 트리거로 GitHub 작업 워크플로(Workflow)를 구성

워크플로는 .yml (혹은 .yaml ) 파일에 의해 구성

워크플로는 .github/workflows 디렉토리 이하에 위치

 

https://docs.github.com/en/actions

GitHub Actions Documentation - GitHub Docs

 

YAML

Yet Another Markup Language의 약자

사람이 읽을 수 있는 데이터 직렬화 언어를 의미

.yaml 혹은 .yml 확장자

YAML은 JSON의 상위 호환 격이므로, 기존 json문서를 그대로 yaml파일로 사용하거나 원하는 부분만 손볼 수 있습니다. 반대로 yaml을 json으로 변환해 사용할 수도 있다는 점이 장점으로 작용

예시)

name: Bare Minimum Requirements
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Bare Minimum Requirements
        uses: actions/setup-node@v1
        with:
          node-version: '16'
      - run: npm install
      - run: npm test

 

YAML 문법

#이런 식으로 주석을 작성할 수 있습니다.

--- #문서 시작

#이 사이에 내용이 들어갑니다.

... #문서 끝

#기본 표현
#: 다음에는 무조건 공백 문자가 와야함
key: value

#int(숫자)
int_type: 1

#string(문자열)
string_type: "1"

#blooean(참/거짓)
boolean_true_type: true
boolean_false_type: false

#이외에 yes, no로 작성하기도 합니다.
yaml_easy: yes
yaml_difficult: no

#리스트(배열 형태)
person:
  name: Chungsub Kim
  job: Developer
  skills: 
    - docker
    - kubernetes
  # JSON 형식의 "skill" : [docker, kubernetes]와 같습니다.
  
  #객체
  
  key: 
  key: value
  key: value

#또는 이렇게도 작성합니다. 가독성을 위해 사용합니다.
key: {
  key: value,
  key: value
}

# TEXT

# |는 줄바꿈 표현입니다.
# JSON 형식의 "comment_line_break": "Hello codestates.\nIm kimcoding.\n"과 같습니다.
comment_line_break: |
  Hello codestates.
  Im kimcoding.

# >는 줄바꿈 무시 표현입니다.
# JSON 형식의 "comment_single_line": "Hello world my first coding."과 같습니다.
comment_single_line: >
  Hello world
  my first coding.