자, 이제 다시 도커의 시간(주말동안 Docker, CSS 디자인 공부 시작)
그럼 뭐다?(참고로 다 까먹은 후) CI/CD부터 알자(참고로 CD에는 Continuous Delivery (CD)라고 지속적 제공이라는 개념이 하나 더 있습니다)
CI/CD는 Continuous Integration(지속적 통합)과 Continuous Delivery/Deployment(지속적 제공/배포)의 약자로, 소프트웨어 개발과 배포 과정에서 자동화를 통해 효율성과 품질을 높이는 방법론 및 프로세스를 의미합니다.
1. Continuous Integration (CI)
지속적 통합은 팀의 여러 개발자가 작성한 코드를 주기적으로 통합하고 테스트하는 프로세스를 말합니다.
개발자가 새로운 코드를 리포지토리에 푸시하면, CI 파이프라인이 자동으로 코드를 빌드하고 테스트하며, 문제를 사전에 발견합니다.
목표:
자주, 작은 단위로 코드를 통합하여 코드 충돌, 의도하지 않은 오류, 품질 저하를 방지.
핵심 활동:
코드 변경 사항이 푸시되면 빌드와 테스트가 자동으로 실행됩니다.
실패한 테스트나 빌드 오류는 즉시 개발자에게 피드백됩니다.
CI 도입 전의 문제:
코드를 대규모로 병합할 때 충돌이 발생하거나, 테스트 비용이 증가.
오류 발견이 늦어지면서 배포 주기가 길어짐.
2. Continuous Delivery (CD)
지속적 제공은 CI 프로세스가 성공적으로 끝난 후, 테스트된 코드가 릴리스(배포) 준비 상태로 유지되도록 하는 프로세스입니다.
배포는 자동화되지만, 운영 환경에 릴리스를 실행하는 최종 결정은 오로지 저희가 합니다~
목표:
코드를 항상 배포 가능한 상태로 유지하고, 운영 환경에 배포하는 시간을 단축.
핵심 활동:
성공적으로 빌드된 코드를 스테이징 환경에 배포.
배포 전 최종 승인 단계를 유지하며, 배포를 수동으로 실행 가능.
CD 도입 전의 문제:
코드 릴리스 과정에서 복잡한 수동 작업이 필요.
배포 오류 발생 가능성이 높음.
3. Continuous Deployment (CD)
지속적 배포는 지속적 제공(CD)에서 한 단계 더 나아가, 코드가 자동으로 운영 환경에 배포되는 프로세스입니다.
사람의 개입 없이 빌드와 테스트가 성공적으로 완료된 코드를 곧바로 운영 환경에 반영합니다.
목표:
완전히 자동화된 배포 파이프라인으로 개발 주기를 극단적으로 단축.
핵심 활동:
스테이징 환경에서 운영 환경으로 자동 배포.
운영 환경에서의 모니터링과 롤백 자동화.
CD 도입 전의 문제:
긴 배포 주기와 수동 작업으로 인해 변경 사항 배포 지연.
사람의 실수로 인해 운영 환경에서 문제 발생.
파이프라인?
CI/CD 파이프라인이란?
파이프라인(Pipeline)은 소프트웨어 개발에서 코드를 최종 배포까지 자동으로 처리하는 일련의 단계를 의미합니다.
CI/CD 파이프라인은 다음과 같은 단계들로 구성됩니다.
코드 소스(Stage 1: Source)
개발자가 코드 변경 사항을 리포지토리에 푸시하거나, Pull Request(PR)를 생성합니다.
트리거 이벤트:(이건 나도 이해가 잘....)
git push, pull_request, 또는 workflow_dispatch(수동 실행).
빌드(Stage 2: Build)
푸시된 코드를 컴파일하고 종속성을 설치하여 빌드 프로세스를 실행합니다.
예: npm install, maven build.
목표: 코드가 실행 가능한 상태인지 확인.
테스트(Stage 3: Test)
빌드된 코드를 대상으로 자동화된 테스트를 실행합니다.
예: 유닛 테스트, 통합 테스트, 기능 테스트.
목표: 코드의 품질을 확인하고, 버그나 문제가 있는지 파악.
배포(Stage 4: Deploy)
테스트를 통과한 코드를 운영 환경(또는 스테이징 환경)에 배포합니다.
지속적 제공: 수동 승인을 통해 배포.
지속적 배포: 테스트 성공 시 자동으로 배포.
CI/CD 파이프라인을 구현하는 예제와 함께 주요 구성 요소(name, on, jobs, runs-on 등)의 역할을 주석으로 설명한 코드
# 전체 워크플로우 이름: UI에서 이 이름으로 구별 가능 name: Full CI/CD Pipeline for Node.js App # 워크플로우 트리거 조건 정의 on: # 특정 브랜치(main)에 푸시가 발생할 때 push: branches: - main # main 브랜치를 대상으로 하는 PR이 생성되거나 변경될 때 pull_request: branches: - main # 수동으로 워크플로우 실행 가능 workflow_dispatch: # 모든 작업을 정의하는 섹션 jobs: # 1단계: CI - 코드를 빌드하고 테스트하는 작업 build-and-test: # 이 작업이 실행되는 환경: 최신 Ubuntu OS runs-on: ubuntu-latest # 이 작업을 구성하는 단계들 steps: # 첫 번째 단계: 리포지토리의 코드를 체크아웃합니다. - name: Checkout Repository uses: actions/checkout@v3 # 두 번째 단계: Node.js 버전을 설정합니다. - name: Setup Node.js Environment uses: actions/setup-node@v3 with: node-version: 16 # 세 번째 단계: 종속성을 설치합니다. - name: Install Dependencies run: npm install # 네 번째 단계: 테스트를 실행합니다. - name: Run Tests run: npm test # 2단계: CD - 테스트 후 성공 시 빌드 및 배포 deploy: # 이 작업은 CI 작업(build-and-test)의 성공을 전제로 실행됩니다. needs: build-and-test # 이 작업이 실행되는 환경: 최신 Ubuntu OS runs-on: ubuntu-latest # 이 작업을 구성하는 단계들 steps: # 첫 번째 단계: 리포지토리를 다시 체크아웃합니다. - name: Checkout Repository uses: actions/checkout@v3 # 두 번째 단계: Node.js 환경을 설정합니다. - name: Setup Node.js Environment uses: actions/setup-node@v3 with: node-version: 16 # 세 번째 단계: 애플리케이션을 빌드합니다. - name: Build Application run: npm run build # 네 번째 단계: 애플리케이션을 배포합니다. - name: Deploy Application env: # GitHub Secrets에서 가져온 민감한 정보 AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} run: | aws s3 sync ./build s3://my-bucket-name --delete코드에 대한 설명 및 연관성
1. CI 섹션: build-and-test
주요 목적:
코드를 빌드하고 테스트하여 문제가 없는지 확인합니다. 배포 전에 소프트웨어 품질을 보장하는 단계입니다.
runs-on: ubuntu-latest
CI 작업이 실행될 환경으로, 최신 Ubuntu 가상 머신에서 실행됩니다.
CD에서도 동일한 환경이 설정되므로 연속성을 유지합니다.
steps: Checkout Repository
GitHub Actions에서 제공하는 checkout@v3 액션을 사용해 리포지토리의 코드를 가져옵니다.
CD 단계에서도 동일한 리포지토리를 다시 가져와야 하므로 중요합니다.
steps: Setup Node.js Environment
setup-node@v3 액션을 사용해 지정된 Node.js 버전을 설정합니다.
이는 테스트와 빌드가 동일한 환경에서 이루어지도록 합니다.
steps: Install Dependencies
npm install 명령어로 종속성을 설치합니다. 이후 deploy 작업에서도 동일한 환경을 재현합니다.
steps: Run Tests
npm test를 실행하여 코드를 테스트합니다.
여기서 테스트가 실패하면 배포가 중단됩니다(needs: build-and-test 조건 때문).
2. CD 섹션: deploy
주요 목적:
테스트가 성공적으로 통과된 코드를 빌드하고 실제 운영 환경에 배포합니다.
needs: build-and-test
CD 단계는 CI 작업인 build-and-test가 성공적으로 완료되어야만 실행됩니다.
즉, 테스트가 실패하면 배포가 진행되지 않습니다.
steps: Checkout Repository
배포를 위해 동일한 리포지토리를 가져옵니다.
이 단계는 build-and-test 작업의 환경과 일관성을 유지하기 위함입니다.
steps: Build Application
npm run build 명령어를 실행하여 애플리케이션을 빌드합니다.
CI 단계와 마찬가지로 동일한 Node.js 버전을 사용합니다.
steps: Deploy Application
빌드된 애플리케이션을 AWS S3에 배포합니다.
GitHub Secrets를 사용해 민감한 정보를 보호하며, 운영 환경에 코드를 배포합니다.
CI와 CD의 구분 및 연계
CI(Continuous Integration):
코드의 품질을 보장하기 위해 자동화된 빌드와 테스트를 수행합니다.
위 예제에서는 build-and-test 작업이 CI를 담당합니다.
핵심은 npm test를 통해 테스트를 통과해야 CD로 넘어갈 수 있습니다.
CD(Continuous Deployment):
CI 단계를 통과한 코드를 빌드하고 실제 운영 환경에 배포합니다.
위 예제에서는 deploy 작업이 CD를 담당합니다.
CD는 needs: build-and-test를 통해 CI 작업의 성공 여부를 전제로 실행됩니다.
연계 포인트:
종속성 관리: setup-node 및 checkout 단계가 동일하게 반복되어 CI와 CD 간의 일관성을 유지합니다.
조건부 실행: needs를 사용하여 CI 작업의 성공 여부에 따라 CD 작업이 실행되도록 설정합니다.
기초 설계?
CI/CD를 처음 시작할 때는 전체 워크플로우를 설계하고 준비하는 과정이 필요합니다. 이는 단순히 CI/CD 파이프라인을 설정하는 것을 넘어서, 환경 설정, 도구 선택, 프로세스 정의를 포함한 여러 준비 단계가 포함됩니다.
1. CI/CD 도입 전의 준비 단계
1-1. 프로젝트와 워크플로우 정의
CI/CD 파이프라인을 구축하려면 먼저 프로젝트 목표와 워크플로우를 정의해야 합니다.
목표 설정:
어떤 문제를 해결하고자 CI/CD를 도입하는가?
예: 테스트 자동화, 배포 속도 향상, 품질 보장.
CI/CD 파이프라인을 적용할 소프트웨어의 범위는 무엇인가?
예: 백엔드 API만 적용, 전체 애플리케이션 적용.
워크플로우 설계:
프로젝트의 소스 코드 관리 방식: Git, Subversion, Mercurial 등.
파이프라인에 포함될 단계 정의: 빌드, 테스트, 배포.
1-2. 환경 설정
CI/CD 파이프라인에서 사용될 환경을 설정합니다. 이는 워크플로우가 실행될 서버, 가상 머신, 또는 클라우드 환경의 준비를 의미합니다.
운영 체제 선택:
CI/CD 작업이 실행될 환경(예: Ubuntu, Windows, MacOS).
예: runs-on: ubuntu-latest는 최신 Ubuntu 환경에서 워크플로우가 실행되도록 설정.
도구 설치 및 설정:
필요한 빌드 도구와 라이브러리 설치.
예: Node.js, Python, Java 같은 언어별 런타임, 패키지 매니저(npm, pip, maven) 등을 준비.
CI/CD 도구 선택: GitHub Actions, Jenkins, GitLab CI/CD, CircleCI 등.
사용하려는 CI/CD 도구의 설정 및 설치를 진행.
1-3. 소스 코드 관리(SCM) 준비
CI/CD의 기반은 소스 코드 관리입니다.
코드가 저장되고, 파이프라인 트리거가 발생하며, 모든 작업이 이 소스를 기반으로 진행됩니다.
리포지토리 설정:
GitHub, GitLab, Bitbucket 등에서 리포지토리를 생성.
브랜치 전략 정의: main, develop, feature/* 브랜치를 나누고 역할을 지정.
Pull Request(PR) 워크플로우: 브랜치 병합 전 검증 및 리뷰 프로세스 정의.
Protected Branch: 주요 브랜치에 직접 푸시를 방지하고, PR로 병합하도록 설정.
트리거 조건 정의:
어떤 이벤트에서 파이프라인이 실행되는지 정의.
예: 코드 푸시, PR 생성, 태그 생성, 수동 실행.
1-4. 자동화 스크립트 준비
파이프라인에서 실행될 작업을 스크립트로 정의합니다.
빌드 스크립트:
코드를 실행 가능한 상태로 변환.
예: npm run build(Node.js), mvn package(Java).
테스트 스크립트:
코드 검증을 위한 유닛 테스트, 통합 테스트 정의.
예: npm test(JavaScript), pytest(Python).
배포 스크립트:
배포 시 필요한 작업 정의.
예: scp(서버 복사), aws s3 sync(AWS S3 업로드).
1-5. 비밀 키와 환경 변수 설정
CI/CD 파이프라인에서는 민감한 정보(예: API 키, DB 비밀번호)가 필요합니다.
GitHub Secrets 또는 환경 변수 사용:
GitHub Actions의 경우, secrets에 민감 정보를 저장.
예: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY.
.env 파일을 활용하여 환경 변수를 로드.
환경 분리:
개발(Development), 스테이징(Staging), 운영(Production) 환경을 분리하고 각각의 설정을 정의.