GitHub Actions CD Process
GitHub Actions CD 프로세스에 대해 설명 하도록 하겠습니다. CI 경우는 배포 하고자 하는 애플리케이션을 TEST 를 주로 담당 하고 있습니다. 이를 통해
버그 및 코드 오류를 예방 할 수 있고 동시에 지속적인 소프트웨어 개발 및 업데이트 주기를 유지하는 데 도움이 됩니다.
그럼 CD 는 CI 를 통해 소프트웨어 품질을 확인 한 후 이를 통해 애플리케이션을 자동화 배포 담당을 하고 있습니다.
먼저 GitHub Actions 을 통해 Trigger 가 발생되면 Docker 를 이용해서 해당 애플리케이션을 Image 를 생성 합니다. 이후 생성한 Image 를 AWS ECR 저장소로 저장 하게 됩니다.
그런 다음 AWS EKS 서비스를 이용해서 helm 활용해 kubernetes 에 배포 및 쉽게 관리 할수 있도록 합니다.
GitHub Actions CI-CD Process
그럼 전체적인 CI-CD FLOW 에 대해 설명 하도록 하겠습니다.
크게 브랜치는
- develop
- release-dev
- release-prod
입니다. ‘develop’ 브랜치는 가장 중심이 되는 default 브랜치 입니다. 만약 작업이 추가 할때 마다 default 브랜치인 ‘develop’ 브랜치 로 부터 새로운 feature 브랜치를 만듭니다.
‘release-dev’ 브랜치는 개발 서버에 배포 및 관리하기 위한 브랜치 입니다. feature 에서 작업한 내용을 release-dev 브랜치로 merge 하게 된다면 개발서버에 자동화 배포 하도록 합니다.
‘release-prod’ 브랜치는 상용 서버에 배포 및 관리 하기 위한 브랜치 입니다.
처음에 작업을 할당 받았다면 default 브랜치인 ‘develop’ 브랜치에서 새로운 브랜치 feature 브랜치를 생성 하게 되고 여기서 작업 후 개발서버에 배포 하기 위해
‘release-dev’ 브랜치에 반영하도록 합니다. 이를 위해서는 GitHub 에서 PR 을 생성 하고 (동시에 CI 발동) PR Close 및 ‘release-dev’ 브랜치에 merge 를 하게 되면
자동화 배포 작업 (CD) 발생 됩니다.
이후 개발서버에 작업 내용 확인 및 문제가 없다면 작업한 feature 브랜치에 최상위 commit 에 Tag 를 반영 후 푸쉬 하게 됩니다. (ex: V1.0.0)
그럼 자동으로 release Tag Branch 가 생성 동시에 GitHub 에 PR 이 생성 하게 됩니다. (동시에 CI 발동)
정상적으로 CI 가 문제 없다면 ‘develop’ 브랜치에 merge 를 합니다. merge 와 동시에 ‘develop’ 브랜치에서 -> ‘release-prod’ 브랜치로 merge 할 수 있는
PR 이 생성 하고 문제가 없다면 merge 진행과 동시에 상용 서버에 배포 하도록 합니다.
상용 서버 배포 진행 중에 GitHub Approve 기능을 이용해서 승인 받는 후 실질적으로 상용 배포 진행 하게 됩니다.
CI-CD 작업이 완료 되었으면 동일한 클러스터 내에 개발 및 상용 name space 로 각각 관리 되어 배포 하게 됩니다.
Copyright 201- syh8088. 무단 전재 및 재배포 금지. 출처 표기 시 인용 가능.
