CI/CD(Continious Integration/Continuous deploymen)라는 용어에 대해서 많이 들어보았지만, 실제로 회사에서 직접 구현해보지는 않아서 많이 낯설다.
이번에는 CI/CD가 무엇인지 알아보고 Github Action을 통해 CI/CD 파이프라인을 구축해서 자동화를 통해 코드를 서빙하는 과정을 가져보았다.
개발 환경
목적에 따라 개발 환경을 나누는 이유 : 실제 운영중인 서비스에 장애가 발생하면 안되기 때문이다.
Local
- 각자의 개인 컴퓨터
- 각자의 환경을 통일 시키기 위해 Docker 등을 사용한다
Dev
- local에서 개발한 기능을 테스트 하는 환경
- Test 서버라고 한다
Staging
- production 환경에 배포하기 전에 운영하거나 보안, 성능을 측정하는 환경
- Staging 서버라고 한다
Production
- 실제 서비스를 운영하는 환경
- 운영 서버라고 한다
Dev = Staging = Production인 경우 문제점?
Git Flow
main -> staging -> dev -> feature/기능
(prod Server) (Staging Server) (Dev Server)
<- 방향으로 Pull Request/Review가 이루어짐,
PR로 Merge가 되면 Local에서 git pull & Test 실행 후 괜찮으면 코드를 배포함(FTP로 파일 전송함)
이런 과정을 효율화할 수 없을까?
CI
CI란 Continous Intergration으로 지속적 통합을 이야기한다.
- 즉, 빌드, 테스트 자동화라고 볼 수 있다.
- 새롭게 작성한 코드 변경 사항을 build, test 진행 후 test case에 통과했는지 확인한다
- 지속적으로 코드 품질 관리를 한다(n명의 개발자가 코드를 수정하면 모두 CI프로세스를 진행한다)
CD
CD란 Continuous Deploy/Delivery로 지속적 배포를 이야기한다.
- 즉 배포 자동화라고 볼 수 있다.
- 작성한 코드가 항상 신뢰 가능한 상태가 되면 자동으로 배포될 수 있도록 하는 과정
- CI -> CD 순으로 진행된다
- dev/staging/main 브랜치에서 Merge 될 경우 코드가 자동으로 서버에 배포 된다.
CI/CD 도구
- Jenkins, circleci, Travis CI, AWS codeDeploy, GCP Cloud Build, Github Action 등이 있다.
Github Action
Github Action는 Github에서 소프트웨어 Workflow 자동화를 위해 출시한 기능이다.
Github Action 사용 예시
- Test code
- 작성한 소스코드가 특정 함수의 return값이 어떻게 나오는지, 특정변수 타입이 의도한대로 맞는지를 확인할 수 있다.
- Unit Test, End to End Test
- 배포
- Prodm Staging, Dev 서버에 코드 배포
- FTP 파일로 전송하거나, Docker Image를 push 할 수도 있음
- Node.js 등 다양한 언어 배포 지원
- 파이썬, 쉘 스크립트 실행
- Github Tag, Release 자동으로 설정
- Main 브랜치에 Merge 될 경우에 특정 작업 실행
- 기존 버전에서 버전 up 하기
- 새로운 브랜치 생성시 특정 작업 실행도 가능함
- 그외 다양한 Workflow 만들기 가능
제약조건
- 금액 : Public Repo 무료, Private Repo 조건에 따라 금액 다름
- 하나의 Github Repository당 최대 20개 workflow 등록가능
- Workflow에 존재하는 Job은 최대 6시간 실행할 수 있으며, 초과시 자동으로 중지됨
- 동시에 실행할 수 있는 Job 제한 존재