개발이 끝났다고 서비스가 뚝딱 올라가는 줄 알아??
Next step으로 넘어가자!
CI/CD란?
애플리케이션을 개발하기 위해서는 일반적으로 개발 → 빌드 → 테스트 → 릴리즈 → 배포의 과정을 거친다. 그 중 빌드, 테스트, 릴리즈, 배포하는 과정을 자동화하는 것을 CI/CD라고 한다. CI/CD(Continuous Integration/Continuous Delivery 또는 Continuous Deployment)의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포이다. 한마디로 CI는 빌드 및 테스트 자동화 과정, CD는 릴리즈 및 배포 자동화 과정을 뜻한다. 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 것이다.
CI
개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다. 지속적인 통합이 제대로 구현되면 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합된다. 따라서 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌하는 문제를 이 방법으로 해결할 수 있다.
CI(지속적 통합)를 통해 개발자들은 코드 변경 사항을 공유 브랜치로 다시 병합하는 작업을 더욱 수월하게 자주 수행할 수 있다. 개발자가 애플리케이션에 적용한 변경 사항이 병합되면 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축하고 각기 다른 레벨의 자동화된 테스트 실행을 통해 변경 사항이 애플리케이션에 제대로 적용되었는지를 확인한다. 자동화된 테스트에서 기존 코드와 신규 코드 간의 충돌이 발견되면 CI를 통해 이러한 버그를 더욱 빠르게 자주 수정할 수 있다.
CD
지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환하여 사용된다.
지속적인 제공이란 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(GitHub)에 자동으로 업로드되는 것을 뜻하며, 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있다. 이는 개발팀과 비즈니스팀 간의 가시성 및 커뮤니케이션 부족 문제를 해결해 준다. 그러므로 지속적인 서비스 제공은 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 한다.
지속적인 배포란 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미한다. 이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결한다.
CI/CD Flow
GitHub Actions란?
GitHub Actions는 GitHub가 제공하는 CI/CD 플랫폼으로 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있다. 리포지토리에 대한 각 풀 리퀘스트를 빌드 및 테스트하거나 병합된 풀 리퀘스트를 프로덕션에 배포하는 것을 자동화할 수 있다.
GitHub Actions 워크플로우를 구성하여 리포지토리에서 풀 리퀘스트가 열리거나 이슈가 생성 등의 특정 이벤트가 발생할 때 트리거되도록 할 수 있다. 워크플로우는 하나 이상의 작업을 포함하며 이러한 작업은 순차적으로 실행하거나 병렬로 실행할 수 있다. 각 작업은 Linux, Windows 및 macOS 가상 머신 내에서 실행되거나 컨테이너 내에서 실행되며, 직접 데이터 센터나 클라우드 인프라에 자체 호스팅된 러너를 사용할 수도 있다. 사용자가 정의한 스크립트를 실행할 수도 있고 미리 정의되어 재사용 가능한 액션들을 실행할 수도 있다.
GitHub Actions 구성요소
Workflows
하나 이상의 작업을 실행하는 자동화된 프로세스이다. YAML 파일로 정의되며 리포지토리에서 이벤트에 의해 트리거되거나 수동으로 트리거하거나 정의된 일정에 따라 실행된다.
리포지토리의 .github/workflows 디렉토리에 정의되며 리포지토리에는 여러 워크플로우가 있을 수 있고 각각 다른 일련의 작업을 수행할 수 있다. 예를 들어, 풀 리퀘스트를 빌드하고 테스트하는 워크플로우, 릴리스가 생성될 때마다 애플리케이션을 배포하는 다른 워크플로우, 새 이슈가 열릴 때마다 레이블을 추가하는 워크플로우 등을 가질 수 있다.
Events
워크플로우 실행을 트리거하는 리포지토리의 특정 활동이다. 예를 들어, 누군가가 풀 리퀘스트를 생성하거나 이슈를 열거나 커밋을 푸시할 때와 같이 GitHub에서 발생하는 작업들을 이벤트로 정의할 수 있다.
예를 들어, 코드 저장소의 main 브랜치에 push 이벤트가 발생할 때 마다 워크플로우를 실행하려면 다음과 같이 설정해주면 된다.
on:
push:
branches: [main]또는 매일 자정에 워크플로우를 실행하려면 다음과 같이 설정해주면 된다.
on:
schedule:
- cron: "0 0 * * *"Jobs
워크플로우 내에서 실행되는 일련의 step이다. 각 step은 실행될 쉘 스크립트이거나 실행될 액션 중 하나이다. 하나 이상의 step들은 순서대로 실행되며 서로 종속적이고 동일한 러너에서 실행되기 때문에 한 step에서 다른 step으로 데이터를 공유할 수 있다. 예를 들어, 애플리케이션을 빌드하는 step 다음에 해당 빌드된 애플리케이션을 테스트하는 step을 구성할 수 있다.
Job의 종속성을 다른 job과 구성할 수 있으며, 기본적으로 job은 종속성이 없고 서로 병렬로 실행된다. 하나의 job이 다른 job에 종속성을 가질 경우 종속 작업이 완료될 때까지 기다린 후 실행된다.
다음 예시는 우분투의 최신 실행 환경에서 해당 레포지토리를 pull 받고 npm test를 진행하는 워크플로우이다.
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: npm install
- run: npm test커맨드나 스크립트를 실행할 때는 run 속성을 사용하며, 액션을 사용할 때는 uses 속성을 사용한다.
Actions
GitHub Actions 플랫폼을 위한 사용자 정의 애플리케이션으로, 복잡하지만 자주 반복되는 작업을 수행한다. 미리 정의된 액션을 사용하여 워크플로우 파일에서 자주 반복되는 코드의 양을 줄일 수 있다.
자체 액션을 작성하거나 GitHub Marketplace를 통해 다른 사람들이 정의한 액션들을 사용할 수 있다.
위 예제에서 사용된 uses: actions/checkout@v3는 해당 레포지토리를 pull 받아서 이동하겠다는 액션이다. uses 키에 해당 step에 대해 사용할 액션을 정의할 때는 {owner}/{repo}@{ref|version}의 형태로 정의한다. GitHub에서 제공하는 체크아웃 액션의 소유자는 actions이고, 저장소 이름은 checkout이며, 버전은 현재 포스팅 시점에서 사용 가능한 가장 최신 버전인 v3를 사용하겠다는 것이다.
Runners
워크플로우가 트리거될 때 작업을 실행하는 서버이다. 각 러너는 한 번에 하나의 job을 실행할 수 있다. GitHub은 Ubuntu Linux, Microsoft Windows 및 macOS 러너를 제공하여 워크플로우를 실행하며 각 워크플로우 실행은 새로운 가상 머신에서 실행된다. 다른 운영 체제가 필요하거나 특정 하드웨어 구성이 필요한 경우 직접 러너를 호스팅할 수도 있다.
Secrets
GitHub에서는 organization, repository에 Secret 변수를 등록할 수 있다. Secret 변수를 등록하여 사용하면 해당 변수를 workflow에서 사용할 때 workflow의 로그에서 해당 값이 아닌 환경변수로 나오기 때문에 민감한 정보들을 노출시키지 않을 수 있다.
Secret 변수는 해당 organization이나 repository에서 Setting에 들어간 다음 Secrets and variables 중 Actions 탭에서 등록, 삭제, 수정할 수 있다.
New repository secret 버튼을 누르면 새 Secret 변수를 등록할 수 있다.
이름과 값을 입력하면 변수가 등록되고 이후에는 수정하거나 삭제할 수는 있지만 값을 직접 볼 수는 없다.
workflow에서는 ${{ secrets.변수이름 }} 와 같은 형태로 사용할 수 있다.
Reference
