지속적 통합과 배포 (CI/CD)가 왜 필요할까?
- 빠른 "배포 속도"와 유연한 반영을 기반으로 하는 "효율성"
- 다차원 적인 요구사항과 빠른 비지니스 변화에 맞는 개발 환경을 고려할 때, 시장 변화와 요구사항을 빠르고 유연하게 반영할 수 있는 방법론 제기
- 탄력적이고 민첩한 (Elastic & Agile)의 강조와 개발과 운영의 긴밀한 협조관계의 DevOps 문화의 도약으로 CI/CD 필요성 급부상
- CI -> Continuous Integration, 지속적 통합
- CD -> Continuous Delivery, 지속적 제공
- CD -> Continuous Deployment, 지속적 배포
지속적 통합과 배포 (CI/CD)
- CI/CD는 애플리케이션 개발 단계를 자동화하여 보다 짧은 주기로 변경을 제공하여 전반적인 개발 프로세스의 효율성과 지속성 보장할 수 있다.
- 반복적 작업의 자동화를 통해 업무 효율성을 올리고, 실수를 줄일 수 있다.
- 개발 업무에 집중할 수 있는 환경을 제공한다.
- "빌드-테스트-배포"의 자동화 프로세스를 통해 수동 작업을 줄여 오류 위험을 최소화한다.
- 일관된 빌드 및 배포를 보장할 수 있다.
- CI/CD 과정을 묶어서 CI/CD 파이프라인을 구축하면 애플리케이션의 통합 및 테스트단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화 및 모니터링을 제공하여 안정적인 배포를 수행하는데 도움이 된다.
1. 지속적 통합(CI)
- CI/CD = 지속적 통합(CI) & 지속적인 서비스 제공(CD) & 지속적인 배포(CD)로 구성
- CI는 현대적 애플리케이션의 다양한 기능 부여와 서로 다른 모듈까지 동시에 여러 개발자가 작업가능하도록 구성하는 것을 목표로 한다.
- CI는 빌드 자동화를 통해 변경되는 개발 코드의 충돌이나 예상치 못한 문제 발생을 예방하고, 통합 과정에서 빌드 + 테스트를 수행하여 코드 문제점을 빠르게 확인할 수 있다.
2. 지속적 제공(CD)
- CI/CD = 지속적 통합(CI) & 지속적인 서비스 제공(CD) & 지속적인 배포(CD)로 구성.
- CD(지속적 제공)는 유효한 개발 코드를 repository(예, github)에 자동 Release하여 운영환경으로 배포할 준비가 되어 있는 안정적 배포 준비 단계다.
- CD는 CI 단계를 거쳐 검증이 완료된 개발 코드를 저장소로 가져와서 수동 또는 자동으로 지속적 배포 단계로 넘겨 운영 환경으로 배포하게 된다.
3. 지속적 배포(CD)
- CI/CD = 지속적인 통합(CI) & 지속적인 서비스 제공(CD) & 지속적인 배포(CD)로 구성.
- CD(지속적 배포)는 애플리케이션을 운영 환경으로 배포하는 작업을 자동화 한다.
- 즉, 애플리케이션의 변경 사항이 테스트를 통과하자마자 자동으로 최종 사용자에게 배포되어, 사용자의 피드백도 즉각 반영될 수 있다.
4. CI/CD 자동화 배포 이후
- 구성된 workflow에 맞춰 형상 관리 도구(예, github등)에 개발 코드를 통합한다.
- 빌드, 테스트가 자동으로 진행되므로 품질 관리가 되기 때문에 코드 검증에 들어가는 시간을 절약할 수 있다.
- Repository에는 테스트가 통과된 코드만 저장되어 좋은 코드 퀄리티 유지가 가능하다.
- 검증된 애플리케이션이 실제 운영 환경으로 자동 배포된다. 이로써 개발자는 한번 클릭으로 모든 프로세스를 자동화할 수 있고 더욱 개발에 집중할 수 있게 된다.
Docker 환경에서의 CI/CD 파이프라인
- Docker환경에서 CI/CD 파이프라인은 docker image를 생성(Dockerfile)하는데 사용한다.
- docker image는 모든 종속성과 구성 파일 및 환경 설정이 포함되므로 배포가 모든 환경에 배포가 쉽다.
- 생성된 이미지는 docker hub(hub.docker.com) or Private registry에 push 하여 docker image 관리가 용이하다.
- 일련의 과정을 자동화 할 수 있다.
Docker 환경에서의 CI/CD 파이프라인
1) 버전 및 형상 관리를 위해 git 등에 변경 코드를 push 한다.
2) 사전에 구성된 CI/CD 파이프라인에서 자동으로 빌드를 트리거하여 Dockerfile을 사용한 새로운 docker image를 생성한다.
3) 새롭게 생성된 docker image를 사용하고 있는 docker registry에 push한다. (CI)
4) 추가된 docker image를 가져와 테스트 환경에 배포한다.
5) 애플리케이션 테스트가 마무리되면 docker image 운영 환경에 배포된다.
일관적이고 안정적인 배포 관리가 이루어지고, 오류 위험을 최소화하여 전반적인 애플리케이션 개발 단게를 쉽게 관리할 수 있다.
Docker 환경에서의 CI
- Docker Image를 생성하고 Dockerfile을 작성하여 동일환경의 팀원과 공유한다.
- 또한, 팀원과의 협업을 위해 Github, GitLab 같은 git 서비스를 이용한다.
Docker CI를 간단히 표현하면 "pull request(PR) or git push로 코드가 입력되면 자동으로 docker build가 수행되고 성공, 실패를 나타내고 docker hub에 새로운 docker image가 build 되어 저장되는 일련의 과정"이다.
실행 중인 애플리케이션에 적용되는 과정까지는 CD과정이 필요하다.
CI 도구 종류 및 시장 영향력
- Enterprise 부터 Small Biz. 용도의 CI 도구는 다양하며, 시장을 선도하는 CircleCI, TeamCity, Bamboo와 같은 상용 제품과 "오픈 소스인 Jenkins" 가 있음
Github Ation
- 코드 저장소인 Github에 CI/CD 기능이 추가된 서비스를 Github Action이라고 한다.
- 이 코드 저장소에서 어떤 이벤트가 발생하면 특정 작업이 트리거 되도록 자동화할 수 있다.
- 코드 저장소에 Pull Request를 생성하게 되면 GitHub Action을 통해 변경된 코드 검사
- main(or master) branch에 코드 유입시 GitHub Action을 통해 변경된 코드 검사
- 특정 시간에 작업 스케줄도 가능(cron)
- 지속적으로 수행해야 하는 반복 작업을 Github Action을 통해 자동화 한다.
GitHub Action 주요 개념
- workflow
- 자동화된 전체 프로세스 과정을 의미하고, 하나 이상의 job으로 구성
- event에 의헤 스케줄(on.schedule.cron)이나 트리거 되는 자동화 구성
- on 속성을 통해서 해당 workflow가 언제 실행되는지를 정의
- YAML로 작성되고 Github Repository의 .github/workflows 폴더 아래 저장
- 작성된 YAML이 전달되면 Github Actions는 해당 파일을 기반으로 그대로 실행.
- event
- workflow를 실행하는 활동 및 규칙 지정
- git 저장소에 commit을 하거나 pull request가 생성되면 GitHub 활동 시작 (Action)
- jobs
- job은 여러 Step으로 구성되고, 단일 가상 환경에서 실행되는 하나의 처리 단위
- 필요에 따라 다른 Job에 의존 관게를 가질 수도 있고, 실행 순서 제어도 가능
- step
- job 안에서 순차적으로 실행되는 프로세스 단위
- 즉, 하나의 job은 여러 단계(step)의 명령을 순차적으로 실행
- step은 명령이나 스크립트를 run 속성으로 작성하거나, uses 속성으로 action을 사용
- action
- job을 구성하기 위한 step들의 조합으로 구성된 독립적인 명령. workflow의 가장 작은 빌드 단위
- workflow에서 action을 사용하기 위해서는 action이 step을 포함해야함
- 빈번하게 필요한 반복 단계를 재사용 가능하도록 제공되는 작업 공유 메커니즘
- GitHub Actions Marketplace를 통한 Action 공유 커뮤니티
- runner
- GitHub Action Runner 애플리케이션이 설치된 가상머신 환경으로, workflow가 실행될 인스턴스
- GitHub에서 자체 제공하는 가상머신인 GitHub-hosted Runner와
- 사용자가 직접 환경을 구성하는 Self-hosted Runner가 있다.
신입 개발자