GitHub Actions
GitHub에서 제공하는 CI/CD (지속적 통합/지속적 배포) 서비스이다. 이 서비스는 소프트웨어 개발 작업을 자동화하는 데 사용되며, 특히 레포지토리에 대한 다양한 이벤트에 반응하여 코드 통합, 테스트 실행, 배포 등의 작업을 자동으로 수행할 수 있다.
주요 기능
- 이벤트 기반 워크플로우: GitHub 레포지토리에서 발생하는 다양한 이벤트(예: 풀 리퀘스트 생성, 이슈 등록, 새 브랜치 생성 등)에 따라 워크플로우를 실행할 수 있다.
- YAML 구성: 워크플로우는. github/workflows 디렉터리에 YAML 파일로 저장된다. 이 파일을 통해 워크플로우의 동작을 정의하고 구성할 수 있다.
- Matrix Builds: 하나의 워크플로우 내에서 다양한 환경(예: 다른 OS, 다른 언어 버전 등)에서 동시에 빌드와 테스트를 실행할 수 있다.
- 내장된 환경 변수: GitHub Actions는 다양한 내장 환경 변수와 시크릿 관리 기능을 제공하여, 민감한 정보를 안전하게 관리할 수 있다.
- 도커 지원: Docker 컨테이너를 사용하여 워크플로우를 실행할 수 있어, 복잡한 빌드와 배포 환경도 손쉽게 구성할 수 있다.
- 잡과 스텝: 워크플로우는 여러 '잡(job)'으로 구성될 수 있으며, 각 잡은 다시 여러 '스텝(step)'으로 이루어져 있다. 이를 통해 복잡한 워크플로우도 세밀하게 제어할 수 있다.
- 아티팩트와 캐시: 빌드 결과물(아티팩트)을 저장하거나 캐시를 활용하여 워크플로우의 속도를 높일 수 있다.
- 마켓플레이스: GitHub 마켓플레이스에서 다양한 미리 만들어진 Actions를 찾을 수 있어, 복잡한 워크플로우를 빠르게 구성할 수 있다.
작동 방식
GitHub Actions의 작동 방식은 상대적으로 직관적이며, 워크플로우를 중심으로 구성된다. 워크플로우는 일련의 '잡(Jobs)'과 이 잡을 구성하는 '스텝(Steps)'으로 이루어져 있다.
- 이벤트 트리거
- 워크플로우는 GitHub 레포지토리 내에서 발생하는 다양한 이벤트에 의해 트리거 될 수 있다. 이벤트에는 풀 리퀘스트, 푸시, 이슈 생성 등이 포함된다. - 워크플로우 파일
- YAML 파일에서는 어떤 이벤트에 반응할 것인지, 어떤 잡을 실행할 것인지, 각 잡에서 어떤 스텝을 거칠 것인지 등을 설정한다. - 잡과 러너
- 하나의 워크플로우 안에서 여러 개의 잡을 정의할 수 있고, 이 잡들은 병렬로 또는 순차적으로 실행될 수 있다.
- 각 잡은 '러너(Runner)'라고 불리는 가상 환경에서 실행된다. 러너는 GitHub에서 제공하는 것을 사용할 수도 있고, 자체 호스팅 러너를 설정할 수도 있다. - 스텝과 액션
- 각 잡은 여러 개의 스텝으로 구성된다. 스텝은 개별적인 작업 단위로, 각각 하나의 명령어나 액션을 실행한다.
- '액션(Actions)'은 재사용 가능한 코드 단위로, GitHub 마켓플레이스에서 다른 사용자가 작성한 액션을 사용하거나 직접 만들어 사용할 수 있다. - 출력과 결과
- 워크플로우의 실행 결과는 GitHub 레포지토리의 'Actions' 탭에서 확인할 수 있다.
- 성공, 실패, 에러 메시지 등이 출력되며, 필요한 경우 워크플로우에서 생성한 아티팩트(빌드 결과물 등)를 다운로드할 수 있다. - 조건부 실행
- 워크플로우, 잡, 스텝은 조건에 따라 실행될 수 있다. 예를 들어, 특정 브랜치에 푸시될 경우만 워크플로우를 실행하는 등의 설정이 가능하다.
장점
- 통합성: GitHub 레포지토리와 자동으로 통합되므로 별도의 CI/CD 도구를 설정하고 관리할 필요가 없다.
- 간편한 구성: YAML 파일 하나로 워크플로우를 구성할 수 있어 사용하기 쉽다.
- 유연성: 다양한 언어, 프레임워크, 플랫폼에 대한 지원이 있으며, 커스터마이징이 용이하다.
단점
- 비용: 무료 플랜에는 제한된 수의 빌드 분이 할당되며, 추가 분은 유료이다.
- 복잡한 워크플로우: 매우 복잡한 워크플로우의 경우 YAML 파일이 길고 복잡해질 수 있다.
이것과 가장 많이 비교되는게 젠킨스(Jenkins)인데 간단히 비교해 보면
젠킨스
- 독립성: 독립적인 서버에서 실행되므로 별도의 인프라 설정과 관리가 필요하다.
- GUI 기반 설정: 웹 인터페이스를 통해 설정이 가능하며, Jenkins Pipeline은 Groovy 스크립트로 설정할 수 있다.
- 플러그인 생태계: 광범위한 플러그인 생태계가 있어 다양한 도구와 통합이 가능하다.
- 고도의 커스터마이즈 가능: 거의 모든 것을 커스터마이즈 할 수 있지만, 그만큼 설정이 복잡할 수 있다.
- 온프레미스/클라우드: 자체 서버나 클라우드에서 실행할 수 있다.
장점
- 유연성: 매우 다양한 플러그인과 확장성을 통해 거의 모든 CI/CD 요구사항을 수용할 수 있다.
- 큰 커뮤니티와 풍부한 문서: 장기간에 걸쳐 축적된 풍부한 지식과 커뮤니티 지원이 있다.
- 온프레미스 지원: 로컬 네트워크 내에서 실행할 수 있어, 보안이 중요한 조직에 적합하다.
- 자유도: 빌드, 테스트, 배포 프로세스를 세밀하게 커스터마이즈 할 수 있다.
- 코드 없는 구성 가능: GUI를 통해 복잡한 워크플로우를 설정할 수 있다.
단점
- 설치 및 관리 복잡성: 별도의 서버 설정과 유지 관리가 필요하고, 플러그인 설치/관리가 복잡할 수 있다.
- 자원 사용: 독립적인 서버나 머신에서 실행되므로, 자원(메모리, CPU 등) 사용이 늘어날 수 있다.
- 시작 난이도: 초기 설정이나 플러그인 관리, 스크립트 작성 등에 어느 정도의 기술적 지식이 필요하다.
- UI/UX: 사용자 인터페이스가 다소 노후하고 직관적이지 않을 수 있다.
- 플러그인 호환성: 다양한 플러그인이 있지만, 종종 플러그인 간의 호환성 문제가 발생할 수 있다.
정리하면 깃허브액션이 조금 더 설정이나 사용이 편하고 가볍다. 젠킨스는 상대적으로 문서도 많고, 거의 모든 요구 사항을 수용할 수 있으면서, 로컬에서도 사용할 수 있다는 점은 좋지만 설정이 복잡하고 호환성에 문제가 있을 수 있으며 무겁다.
'오늘 뭐했냐 > 개발에 대한 주저리' 카테고리의 다른 글
23.09.10 엘라스틱서치(Elasticsearch) (0) | 2023.09.14 |
---|---|
23.09.09 도커(Docker) (0) | 2023.09.13 |
23.09.05 캐시(cache) (0) | 2023.09.11 |
23.09.04 운영체제(Operating System, OS) (0) | 2023.09.10 |
23.09.03 스웨거(Swagger) (0) | 2023.09.09 |