CI-CD

CI/CD Principles CI/CD 원칙은 지속적 통합 (CI) 과 지속적 배포 (CD) 를 기반으로 코드 변경 사항을 빠르게 통합, 테스트, 배포하는 자동화된 프로세스를 강조한다. CI/CD 는 DevOps 문화의 중심에 있으며, 개발팀이 더 자주, 더 안정적으로 코드를 통합하고 배포할 수 있게 해준다. 핵심 개념 CI/CD 는 두 가지 연관된 개념의 조합이다: 지속적 통합 (Continuous Integration, CI): 개발자들이 코드 변경사항을 중앙 리포지토리에 자주 통합하는 개발 방식으로, 보통 하루에 여러 번 이루어진다. 각 통합은 자동화된 빌드와 테스트로 검증되어 통합 문제를 빠르게 식별한다. ...

Gitlab CI .gitlab-ci.yml 구조 Stage/Job 구성 및 GitLab Pages 활용 Multi-Project 파이프라인 Auto DevOps 설정 Kubernetes 배포 자동화 GitLab에 내장된 지속적 통합/배포 도구로, .gitlab-ci.yml 파일을 통해 파이프라인을 정의하고 관리 특징 통합성: GitLab 저장소와 긴밀하게 통합되어 있어 별도의 도구 없이 CI/CD 파이프라인을 구축할 수 있습니다. 유연성: YAML 파일을 통해 파이프라인을 구성할 수 있어 다양한 프로젝트 요구사항에 맞춤 설정이 가능합니다. 확장성: 다양한 Runner 유형을 지원하여 다양한 환경에서 작업을 실행할 수 있습니다. 가시성: 파이프라인 실행 상태와 결과를 GitLab 인터페이스에서 쉽게 확인할 수 있습니다. 기능 자동 빌드 및 테스트: 코드 변경 시 자동으로 빌드 및 테스트를 실행합니다. 환경 배포: 다양한 환경(개발, 스테이징, 프로덕션 등)에 자동으로 배포할 수 있습니다. 아티팩트 관리: 빌드 결과물을 저장하고 관리할 수 있습니다. 병렬 실행: 여러 작업을 동시에 실행하여 파이프라인 속도를 향상시킵니다. 환경 변수 관리: 민감한 정보를 안전하게 저장하고 사용할 수 있습니다. 구성요소 .gitlab-ci.yml: 파이프라인 구성 파일 Runners: 작업을 실행하는 에이전트 Jobs: 실행할 개별 작업 Stages: 작업의 실행 순서를 정의하는 단계 Pipeline: 전체 CI/CD 프로세스 장점 GitLab과의 긴밀한 통합 쉬운 설정과 사용 확장성과 유연성 무료로 사용 가능한 기능이 많음 단점 GitLab에 종속적 복잡한 워크플로우의 경우 설정이 복잡해질 수 있음 일부 고급 기능은 유료 버전에서만 사용 가능 설정 방법 프로젝트 루트에.gitlab-ci.yml 파일 생성 YAML 형식으로 파이프라인 구성 작성 변경사항을 커밋하고 푸시 GitLab에서 파이프라인 실행 확인 .gitlab-ci.yml 파일의 기본 구조 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 stages: - build - test - deploy job1: stage: build script: - echo "Building the project..." job2: stage: test script: - echo "Running tests..." job3: stage: deploy script: - echo "Deploying to production..." 주요 구성 요소 stages: 파이프라인의 실행 단계를 정의합니다. 각 단계는 순차적으로 실행됩니다. jobs: 각 작업을 정의합니다. 작업은 특정 단계에 속하며, 실행할 스크립트를 포함합니다. script: 작업에서 실행할 명령어들을 정의합니다. image: 작업을 실행할 Docker 이미지를 지정합니다. artifacts: 작업 결과물을 저장하고 다른 작업에서 사용할 수 있게 합니다. cache: 작업 간에 공유할 파일이나 디렉토리를 지정합니다. 고급 구성 옵션 only/except: 특정 브랜치나 태그에서만 작업을 실행하거나 제외할 수 있습니다. variables: 파이프라인 전체 또는 특정 작업에서 사용할 변수를 정의합니다. before_script/after_script: 작업 실행 전후에 실행할 스크립트를 정의합니다. environment: 배포 환경을 지정합니다. 예시 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 # 파이프라인 단계 정의 stages: - build - test - deploy # 캐시 설정: node_modules 폴더를 캐시하여 빌드 속도 향상 cache: paths: - node_modules/ # 빌드 작업 정의 build: stage: build image: node:14 # Node.js 14 버전 이미지 사용 script: - npm install # 의존성 설치 - npm run build # 프로젝트 빌드 artifacts: paths: - dist/ # 빌드 결과물 저장 # 테스트 작업 정의 test: stage: test image: node:14 script: - npm install # 의존성 설치 - npm test # 테스트 실행 # 배포 작업 정의 deploy: stage: deploy image: alpine:latest script: - apk add --no-cache rsync openssh # 배포에 필요한 도구 설치 - mkdir -p ~/.ssh - echo "$SSH_PRIVATE_KEY" | tr -d '\r' > ~/.ssh/id_rsa - chmod 600 ~/.ssh/id_rsa - ssh-keyscan -H $DEPLOY_SERVER_IP >> ~/.ssh/known_hosts - rsync -avz --delete dist/ $DEPLOY_USER@$DEPLOY_SERVER_IP:/path/to/deployment/ only: - master # master 브랜치에 푸시될 때만 실행 stages: 파이프라인의 단계를 정의합니다. 여기서는 build, test, deploy 세 단계로 구성됩니다. cache: node_modules 폴더를 캐시하여 빌드 속도를 향상시킵니다. build 작업: stage: build로 빌드 단계에 할당합니다. Node.js 14 버전 이미지를 사용합니다. npm install로 의존성을 설치하고, npm run build로 프로젝트를 빌드합니다. artifacts를 사용하여 빌드 결과물을 저장합니다. test 작업: stage: test로 테스트 단계에 할당합니다. npm test 명령으로 테스트를 실행합니다. deploy 작업: stage: deploy로 배포 단계에 할당합니다. Alpine Linux 이미지를 사용하여 가벼운 환경을 구성합니다. SSH 키를 설정하고 rsync를 사용하여 빌드 결과물을 서버에 배포합니다. only: - master로 master 브랜치에 푸시될 때만 실행되도록 설정합니다. 기본 설정 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 # GitLab CI의 기본 설정 예시 image: node:16 # 기본 Docker 이미지 지정 # 파이프라인 스테이지 정의 stages: - build - test - deploy # 캐시 설정 - node_modules 디렉토리를 캐시 cache: paths: - node_modules/ # 빌드 작업 정의 build: stage: build # 속한 스테이지 지정 script: - npm install # 의존성 설치 - npm run build # 빌드 실행 artifacts: # 빌드 결과물 저장 paths: - dist/ # 테스트 작업 정의 test: stage: test script: - npm run test # 테스트 실행 dependencies: # build 작업의 결과물 사용 - build # 배포 작업 정의 deploy: stage: deploy script: - echo "Deploying application…" - npm run deploy only: # main 브랜치에서만 실행 - main 고급 설정 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 # 환경변수와 조건부 실행이 포함된 고급 설정 예시 variables: DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG # Docker 이미지 태그 정의 # 커스텀 도커 이미지 빌드 build_image: image: docker:20.10.16 services: - docker:20.10.16-dind # Docker-in-Docker 서비스 stage: build script: # Docker 레지스트리 로그인 - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY # Docker 이미지 빌드 및 푸시 - docker build -t $DOCKER_IMAGE . - docker push $DOCKER_IMAGE rules: - if: $CI_COMMIT_BRANCH == "main" # main 브랜치에서만 실행 when: always - when: never # 그 외의 경우 실행하지 않음 # 보안 스캔 작업 security_scan: image: security-scanner stage: test script: - scan-dependencies # 의존성 취약점 검사 - scan-code # 코드 보안 검사 allow_failure: true # 실패해도 파이프라인 계속 진행 # 스테이징 환경 배포 deploy_staging: stage: deploy environment: name: staging script: - deploy-to-kubernetes.sh --env staging rules: - if: $CI_COMMIT_BRANCH == "develop" 환경별 배포 설정 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # 환경별 배포 구성 예시 .deploy_template: &deploy_template # 재사용 가능한 배포 템플릿 정의 script: - echo "Deploying to $CI_ENVIRONMENT_NAME" - kubectl apply -f k8s/$CI_ENVIRONMENT_NAME/ deploy_dev: <<: *deploy_template # 템플릿 상속 environment: name: development rules: - if: $CI_COMMIT_BRANCH == "develop" deploy_prod: <<: *deploy_template environment: name: production rules: - if: $CI_COMMIT_BRANCH == "main" when: manual # 수동 승인 후 배포 병렬 작업 실행 1 2 3 4 5 6 7 8 9 10 11 12 13 14 # 병렬 테스트 실행 예시 test: parallel: 3 # 3개의 병렬 작업 생성 script: - npm run test -- --split=$CI_NODE_INDEX/$CI_NODE_TOTAL # 매트릭스 작업 정의 test_matrix: parallel: matrix: - NODE_VERSION: ["14", "16", "18"] DB_TYPE: ["mysql", "postgres"] script: - docker-compose run --rm -e NODE_VERSION=$NODE_VERSION -e DB_TYPE=$DB_TYPE test 캐시와 아티팩트 관리 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # 캐시와 아티팩트 관리 예시 build: cache: key: ${CI_COMMIT_REF_SLUG} # 브랜치별 캐시 키 paths: - node_modules/ - .npm/ policy: pull-push # 캐시 정책 설정 artifacts: paths: - dist/ # 빌드 결과물 - coverage/ # 테스트 커버리지 리포트 reports: junit: test-results.xml # 테스트 결과 리포트 coverage: coverage/lcov.info # 커버리지 리포트 expire_in: 1 week # 아티팩트 유효 기간 이러한 설정들은 프로젝트의 요구사항과 규모에 따라 적절히 조정하여 사용할 수 있습니다. ...

CI(지속적 통합) Vs. CD(지속적 전달) vs. CD(지속적 배포) CI/CD 는 현대 소프트웨어 개발 방법론의 핵심으로, 개발 과정을 자동화하고 신속하게 가치를 전달하는 데 중점을 둔다. 지속적 통합 (CI) 은 개발자가 코드 변경 사항을 자주 통합하고 검증하는 과정을 말하며, 지속적 전달 (CD) 은 검증된 코드를 자동으로 프로덕션 환경에 배포 가능한 상태로 준비하는 과정을, 지속적 배포 (CD) 는 검증된 코드를 자동으로 프로덕션 환경에 배포하는 과정을, 각각 자동화하는 방법론이다. 이 세 가지 접근 방식의 주요 차이점은 코드 변경 사항이 프로덕션 환경에 도달하는 자동화 수준과 사람의 개입 정도에 있다. CI/CD 파이프라인은 코드 품질 향상, 출시 주기 단축, 팀 협업 강화 등 다양한 이점을 제공하며, 최신 트렌드로는 GitOps, AIOps, 보안 통합 (DevSecOps) 등이 있다. ...

History and Evolution of CI/CD CI/CD(지속적 통합/지속적 배포) 의 역사와 발전은 소프트웨어 개발 방법론의 진화를 보여주는 중요한 여정입니다. 1990 년대 후반 익스트림 프로그래밍 (XP) 에서 처음 등장한 지속적 통합 개념이 시작점이었으며, 이후 애자일 방법론의 부상과 함께 발전했다. 워터폴 모델의 한계를 극복하기 위해 등장한 CI/CD 는 개발자들이 코드 변경사항을 빈번하게 통합하고 자동화된 테스트를 수행하는 방식으로 진화했다. 2000 년대 중반 젠킨스 (이전의 허드슨) 의 등장은 CI/CD 도구의 대중화를 이끌었고, 이후 클라우드와 컨테이너 기술의 발전과 함께 GitLab CI, CircleCI, GitHub Actions 등 다양한 도구들이 등장했다. 현재 CI/CD 는 GitOps, AIOps, 보안 통합 (DevSecOps) 등의 최신 트렌드를 포함하며 계속 발전하고 있다. 이 발전 과정은 수동적이고 경직된 개발 프로세스에서 자동화되고 유연한 방식으로의 전환을 보여주며, 소프트웨어 산업의 혁신과 속도를 가속화하는 데 중요한 역할을 하고 있다. ...

Shadow Deployment 실제 트래픽을 복제해 신규 환경에 적용, 영향 분석 미러링된 트래픽으로 실환경 테스트 로그 분석을 통한 기능 안정성 검증 트래픽 복제 시 개인정보 마스킹 이슈 처리 Shadow Deployment 는 소프트웨어 배포 전략 중 하나로, 새로운 버전의 애플리케이션을 기존 버전과 병행하여 실행하되 사용자에게는 영향을 주지 않는 방식이다. Shadow Deployment 는 새로운 버전의 애플리케이션을 프로덕션 환경에 배포하고 실제 트래픽을 복제하여 새 버전으로 전송하지만, 그 결과는 사용자에게 반환하지 않는 방식이다. 이는 실제 환경에서 새로운 버전을 안전하게 테스트할 수 있게 해준다. ...

Feature Flags Feature flags(또는 feature toggles)는 소프트웨어 개발에서 중요한 배포 전략 중 하나이다. 이 기술을 통해 개발자는 코드 변경 없이 런타임에 특정 기능을 활성화하거나 비활성화할 수 있다. Feature flags는 조건문을 사용하여 코드의 특정 부분을 동적으로 제어하는 소프트웨어 개발 기법이다. 이를 통해 배포와 릴리스를 분리하고, 위험을 최소화하며 유연한 기능 관리가 가능해진다. Feature flags는 현대적인 소프트웨어 개발에서 중요한 도구이다. 이를 효과적으로 사용하면 더 안전하고 유연한 배포 프로세스를 구축할 수 있다. 하지만 적절한 관리와 주의가 필요하며, 팀의 요구사항과 프로젝트의 특성에 맞게 사용해야 한다. ...

A/B Testing 사용자 그룹별로 다른 버전 제공, 실험적 배포 피처 플래그 (Feature Flag) 시스템 도입 사용자 그룹 분리 기반 실험 결과 측정 지표 (Conversion, Retention 등) A/B Testing 은 소프트웨어 배포 전략 중 하나로, 두 가지 이상의 버전을 사용자에게 제공하여 어떤 버전이 더 효과적인지 비교하는 방법이다. A/B Testing 은 두 가지 이상의 버전 (A 와 B) 을 사용자 그룹에게 무작위로 제공하여 각 버전의 성능을 비교하는 실험적 접근 방식이다. 이는 웹사이트, 모바일 앱, 마케팅 캠페인 등 다양한 분야에서 사용된다. ...

Blue-Green Deployment 두 환경을 번갈아 사용, 무중단 배포, 빠른 롤백 [2] 활성 (Active) vs 대기 (Standby) 환경 구성 배포 전후 Smoke Test 수행 Load Balancer 또는 Ingress 트래픽 전환 Blue-Green Deployment 은 무중단 배포 전략 중 하나로, 애플리케이션의 새 버전을 안전하고 효율적으로 배포하는 방법이다. Blue-Green 배포는 두 개의 동일한 프로덕션 환경을 유지하는 방식이다: Blue 환경: 현재 운영 중인 버전 Green 환경: 새로 배포할 버전 이 두 환경은 완전히 동일한 인프라와 설정을 가지고 있다. Blue-Green Deployment 은 안전하고 효율적인 배포 전략이지만, 적절한 계획과 자동화가 필요하다. 조직의 요구사항과 인프라 환경에 맞게 적절히 조정하여 사용하는 것이 중요하다. ...

Canary Deployment 점진적 트래픽 배포 비율 설정 (e.g., 5%, 10%, 50%, 100%) 사용자 행동/성능 모니터링 연동 Istio/Flagger 로 구현하는 실습 일부 트래픽에만 신규 버전 적용, 이상 시 빠른 복구 카나리 배포 (Canary Deployment) 패턴은 새로운 버전의 애플리케이션을 점진적으로 배포하는 전략이다. 이 방식은 위험을 최소화하면서 새로운 기능이나 업데이트를 테스트할 수 있게 해준다. 카나리 배포라는 이름은 광부들이 유독 가스를 감지하기 위해 카나리아 새를 사용했던 관행에서 유래되었다. 소프트웨어 배포에서 이 개념은 다음과 같이 적용된다: ...

Rolling Deployment 배포 중 다운타임 최소화 Pod 수 또는 인스턴스 수 조절 전략 Kubernetes RollingUpdate 정책 설정 점진적 배포, 트래픽 분산, 점검 및 롤백 용이 Rolling Deployment 는 애플리케이션의 새 버전을 점진적으로 배포하는 무중단 배포 전략이다. Rolling Deployment 는 기존 버전의 인스턴스를 새 버전으로 점진적으로 교체하는 방식이다. 이 과정에서 서비스의 가용성을 유지하면서 새 버전을 배포할 수 있다. 주요 특징: 인스턴스를 하나씩 또는 작은 배치로 업데이트 전체 배포 과정 동안 서비스 유지 새 버전과 이전 버전이 일시적으로 공존 Rolling Deployment 는 서비스의 연속성을 유지하면서 새 버전을 안전하게 배포할 수 있는 효과적인 전략이다. 그러나 버전 간 호환성과 데이터베이스 변경 관리에 주의가 필요하다. 조직의 요구사항과 애플리케이션 특성을 고려하여 적절히 구현해야 한다. ...