Github Action
- 빌드, 테스트, 배포 자동화를 위해 많이 쓴다고들 한다.
- 그게 아니더라도 특정 이벤트에 대한 동작들을 지정해두고 싶으면 쓸 수 있다. 이벤트는 후술
1) 구성
- 내 repo에서 ‘이벤트’가 발생하면 동작할 ‘workflow’를 지정해둘 수 있다.
- PR 등등
Workflows
- 1개 이상의 job으로 구성
- YAML 형식으로 작성
- repo의 .github/workflows에 작성
- 하나의 repo에 여러개의 workflow 작성 가능
- 빌드 테스트, 배포부터 이슈 오픈시 label을 자동으로 붙이는 것까지, 다 가능
Workflow syntax for GitHub Actions - GitHub Docs
Events
- Workflow를 시작시키는 특정한 행동
- PR, 이슈 오픈, push, commit 등등
- 특정 브랜치에 대한 push도 이벤트로 설정 가능
Events that trigger workflows - GitHub Docs
Jobs, Stps
Jobs
- Job은 같은 runner에서 실행되는 step들로 구성
- 각 step은 shell script, action 등등을 의미
- 서로에게 의존성을 줄 수 있지만 기본적으로는 의존성 x
- 빌드 job → 테스트 job과 같이 순서 매길 수 있음
Steps
- Step은 순서대로 실행되며 서로에게 의존적
- 같은 runner에서 실행되므로 데이터 공유 가능
Actions
- 빈번하게 반복되는 복잡한 작업을 수행하기 위한 custom application
- workflow 파일에 작성해야하는 반복되는 코드들을 줄이는데 사용 가능
- repo를 pull하고, 빌드 환경 구성, 클라우드 인증 등와 같은 작업에 사용 가능
Runners
- workflow를 실행시키는 서버
- 한번에 하나의 job 수행 가능
- Github에서 Ubuntu, windows, macOS runner 제공
2) 활용안
현업에서는 CI/CD 전략을 어떻게 가져가는가?
다음과 같이 활용해보고자 한다. git flow 전략 사용한다.
- feature 브랜치 push한 경우 build/test를 거쳐 dev로 merge
- 매주 목요일에 dev → main PR을 올린다. 이 때 build/test를 거쳐 main으로 merge
- 이때 test는 실제 환경과 같은 상황에서 이루어지도록 해야할 것
- 즉 실제 환경에 대한 파악을 미리 해야한다.
- 배포를 어떻게 할지 미리 구성해두자
- main으로 merge가 성공적으로 되면 서버들 하나씩 pull, 서버 instance 띄우기, 서버 갈아끼우기.. 식으로 갈 수 있으려나?
- was가 2대라면, 하나 일단 죽이고, pull, build, 서버 실행 → 다음꺼 pull, build, 서버 실행?
- Rolling, Blue Green, Canary 확인
Ref
응애