CICD 예제 파이프라인 및 demo
- Taejoon Moon
CICD
CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법
CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포입니다.
CI : 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)
CD : 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미
CI/CD(CI CD, 지속적 통합/지속적 배포): 개념, 툴, 구축, 차이
github, gitlab (git)
분산버전관리시스템
github, gitlab 의 주요제공기능
버전관리
프로젝트관리 (wiki, issues)
패키지기능(npm, RubyGems, Apache Maven, Gradle, Docker, and NuGet, docker 등)
자동화와 CICD
보안
API 제공
github VS gitlab 어떤 것 선택을 할 것인가?
gitlab | github |
|---|---|
Free Premium : 1인당 월$19*12= 년 $228 Ultimate : 1인당 월$99*12=년 $1188 | Free Team : 1인당 월 $4*12 = 년 $48 Enterprise : 1인당 월 $21*12 = 년 $252 |
솔루션 관리의 편의성을 위해서 SaaS 선택, IDC나 사내에서 배포 필요시 runner 를 이용하면 됨
타입별 비교 : Free 제외.
API는 모두 제공됨
CICD 기준 평가
github은 기본적인 CICD 기능을 제공
gitlab은 CICD에 필요한 각종 기능을 통합하여 제공을 하고 있음. (테스팅과 관련한 각종 툴이 통합, Auto DevOps, 애플리케이션 운영 및 유지 관리에 도움이되는 다양한 도구를 제공, 쿠버네티스 통합 등)
배포
gitlab은 environments 를 이용하여 애플리케이션 배포 및 롤백이 편리
github은 public repo 또는 Enteprise에서만 지원을 함
선택
gitlab에서 제공하는 CICD 이 다양하지만 당장 사용을 할 수 있는 있는 상황은 아님
gitlab의 배포기능은 상당히 유용하며 이 부분을 활용할 것이라면 gitlab을 사용하는 것이 좋음
gitlab 배포기능이 현재 당장 필요한 것이 아니라면 github 사용
git branch 전략
github flow
https://guides.github.com/introduction/flow/
https://guides.github.com/pdfs/githubflow-online.pdf
branch 생성 → commit → Pull request → 코드 토론 및 검토 → 풀 요청이 검토되고 브랜치가 테스트를 통과하면 변경 사항을 배포하여 프로덕션에서 확인 → 코드를 메인 브랜치에 병합
git 브랜칭 전략으로는 여러 가지가 있으며 (Git flow, GitHub flow, GitLab flow) 각 개발조직에서 맞는 것을 선정하여 사용하면 됨.
https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/
github actions 이용한 CICD
사전 설정
Pull request (github) 를 생성할 때 Reviewers, Assignees 를 지정
Pull request (github) 또는 Merge request(gitlab)를 했을 때 버전 관리 프로그램에서 사전에 *명의 리뷰를 받도록 강제로 설정할 수 있음.
github : 해당 git repo Settings -Branches - Branch protection rules - Require pull request reviews before merging
gitlab : 해당 git repo Settings - Merge request (MR) approvals
environments 로 dev, staging, production 을 설정하여 환경을 구분하고 배포 관련한 작업을 연관시킬 수 있음.
github 에서는 environments 기능을 공개 repo나 enterprise plan 일 경우에만 지원을 하고 private repo에는 아직 지원 안함. GitHub Team 의 private repo에서도 environments 를 지원(2022년 언젠가부터 지원 시작). github 에서 environments 기능을 이용하면 리뷰어의 승인이 있어야 배포 가능, 트리거 발생후 일정 시간이 지나야 배포 가능, 특정 브랜치만 배포 가능 등을 설정할 수 있음.
environments 에 따른 변수를 다르게 쓸 수 있는 것도 좋은 기능인데 environments 가 지원되어야 가능한 부분임.
github actions workflow
github actions를 이용하여 소프트웨어 워크 플로를 쉽게 자동화 할 수 있음. GitHub에서 바로 코드를 빌드, 테스트 및 배포
https://github.com/taejoonmoon/cicd_example/blob/main/.github/workflows/main.yml
기본조건 : main 브랜치에 push 나 pull_request가 있을 때 github actions 실행이 됨.
build, test 는 현재 workflow에서 모두 실행이 됨
Pull Request 상태 일 때만 Dev에 배포
메인에 커밋하거나 병합 할 때만 스테이징에 배포
스테이징 후 승인을 받아 프로덕션에 배포
branch 생성 → commit → Pull request → 코드 토론 및 검토 → 병합 및 배포
개발자는 생성한 branch 에서 필요한 코드를 수정하고 테스팅을 함.
Pull request 요청
코드 토론 및 검토
사전에 리뷰어 설정을 해두었으면 리뷰가 끝나야 코드 병합이 가능함.
Pull request 를 요청한 화면에서 github actions 에 설정한 build, test 등의 조건이 통과해야 이후 진행이 가능함
Pull request 요청이 왔을때 github actions 에서는 deploy-dev 까지 진행.
메인에 커밋하거나 병합 할 때만 스테이징에 배포
스테이징 후 승인을 받아 프로덕션에 배포
프로덕션에 배포하는 것은 승인을 받도록 구성을 했음. 특정 환경에 대한 배포시 승인을 하는 부분은 github 공개 repo나 enterprise plan 일 경우에만 지원을 함. 이런 경우 프로덕션 환경에는 수동으로 배포를 하도록 구성할 수 있음.
수동으로 배포를 하는 부분 :
https://github.com/taejoonmoon/cicd_example/blob/main/.github/workflows/deploy_prd.yml
rest api를 이용해서 GitHub Actions workflow 를 실행할 수도 있음 https://docs.github.com/en/rest/reference/actions#create-a-workflow-dispatch-event
git_user=tjmoon git_token=xxxxxxxxxx curl \ -X POST \ -H "Accept: application/vnd.github.v3+json" \ -u $git_user:$git_token \ https://api.github.com/repos/taejoonmoon/cicd_example/actions/workflows/deploy_prd.yml/dispatches \ -d '{"ref":"main"}'
배포 예제를 위해서 AWS s3 bucket 에 html 파일 업로드하는 부분을 추가하였음. 사전에 s3 버킷 생성하고 정적 웹호스팅 설정을 해야함. 이 문서에서 이에 대한 설명은 생략.
deploy-staging: name: deploy-staging if: github.event.ref == 'refs/heads/main' needs: [test] runs-on: ubuntu-latest environment: name: staging url: 'http://tjmoon-cicd-example.s3-website.ap-northeast-2.amazonaws.com/staging/' steps: - name: Checkout uses: actions/checkout@v2 - name: Configure AWS credentials from Test account uses: aws-actions/configure-aws-credentials@v1 with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: ap-northeast-2 - name: Copy files to the test website with the AWS CLI run: | aws s3 rm s3://$BUCKET_NAME/staging/ --recursive aws s3 cp ./ s3://$BUCKET_NAME/staging/ --recursive --exclude "*" --include "*.html" env: BUCKET_NAME: vntg-cicd-example
github actions 예제
https://docs.github.com/en/actions/guides
gitlab 이용한 CICD
사전설정
Merge request(gitlab) 를 생성할 때 Reviewers, Assignees 를 지정
Merge request(gitlab)를 했을 때 버전 관리 프로그램에서 사전에 *명의 리뷰를 받도록 강제로 설정할 수 있음.
gitlab : 해당 git repo Settings - Merge request (MR) approvals
environments 로 dev, staging, production 을 설정하여 환경을 구분하고 배포 관련한 작업을 연관시킬 수 있음
gitlab CICD
build - test - deploy staging - deploy production
test 에서 문제가 없으면 staging 에는 자동으로 배포를 하지만 production 환경에 배포를 할 경우에는 수동으로 진행을 하도록 구성을 하였음.
각 environments 에서 배포기록을 볼 수 있고 손쉽게 ui에서 과거의 특정 git revision 으로 롤백을 할 수도 있음.
gitlab 예제
https://docs.gitlab.com/ee/ci/examples/README.html
기타
test의 경우 단위테스트, 성능테스트 등 다양한 테스트가 있으나 여기에서는 설명 생략
배포전략의 경우도 blue/green, 카나리, 롤링 업데이트등 다양하며 여기에서는 설명 생략