개발자에게 있어서 CI / CD는 굉장히 중요하다고 한다. CI/CD를 통해 자동화함으로써 개발자의 생산성을 향상시킬 수 있으며, 휴먼 에러 없이 서비스 배포를 관리할 수 있기 때문이라고 생각한다.
실제로 적용해보기 위해서 기존에 진행했던 프로젝트에 Github Actions와 AWS의 CodeDeploy를 사용하여 CI / CD를 해보았다. 오늘은 먼저 Github Actions에 대해 먼저 알아보고자 한다.
Github Actions
GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 지속적 통합 및 지속적 배포(CI/CD) 플랫폼이다. 리포지토리에 대한 모든 풀 요청을 빌드 및 테스트하는 워크플로를 생성하거나 병합된 풀 요청을 프로덕션에 배포할 수 있다.
-
자동으로 코드 저장소에서 어떤 이벤트(event)가 발생했을 때 특정 작업이 일어나게 하거나 주기적으로 어떤 작업들을 반복해서 실행시킬 수 있다.
-
새로운 코드가 메인 브랜치에 push되면 소프트웨어를 빌드(build)하고 상용 서버에 배포(deploy)할 수도 있다.
-
추가적으로, 매일 밤 특정 시각에 그날 하루에 대한 통계 데이터를 수집시킬 수도 있다.
-
worlflow : 가장 상위 개념으로, .github/workflows 폴더 아래에 위치. YAML 파일로 설정하며, 하나의 코드 저장소에 여러 개의 워크플로우를 생성할 수 있다. 예를 들어 풀 리퀘스트를 작성하고 테스트하는 하나의 워크플로우, 릴리스가 생성될 때마다 애플리케이션을 배포하는 또 다른 워크플로우, 누군가 새 이슈를 열 때마다 레이블을 추가하는 또 다른 워크플로우를 가질 수 있다.
- on : 해당 워크 플로우가 언제 실행되는지를 정의
- jobs : 해당 워크 플로우가 구체적으로 어떤 일을 해야 하는지 명시.
- 독립된 가상 머신 또는 컨테이너에서 돌아가는 하나의 처리 단위.
- 모든 작업은 기본적으로 동시에 실행되며, 필요 시 작업 간에 의존 관계를 설정하여 작업이 실행되는 순서를 제어할 수도 있다.
- runs-on : 실행 환경 지정 (Linux, windows 등)
- steps : jobs 내 작업 순서를 정하는 것. run : 커맨드나 스크립트 속성, uses : 액션 사용 시. 두 가지 모두 - 를 붙여서 사용해야 함.
- actions : 깃헙 액션에서 빈번하게 필요한 반복 단계를 재사용하기 용이하도록 제공되는 일종의 작업 공유 메커니즘.
-
레포지토리에서 github action workflow를 생성한다.
이상으로 기본적인 내용들에 대해서 우선 알아보았다. 하지만 공식문서에서도 나와 있듯이, 각 작업 별로 정말 다양한 설정들을 해줄 수 있기 때문에, 이런 부분들에 대해서는 반드시 추가적인 공부가 필요하며, 앞으로 계속 공부해나갈 예정이다.
<참고>
https://docs.github.com/ko/actions
https://www.daleseo.com/github-actions-setup-node/
