Please enable JavaScript.

Coggle requires JavaScript to display documents.

GitHub Actions를 활용한 CI/CD 파이프라인 - Coggle Diagram

- - - - 핵심 이점
        
        환경 일관성과 높은 이식성
        
        도커 이미지에 애플리케이션의 의존성이 모두 포함되어 개발, 테스트, 운영 서버에서 동일한 배포 환경을 보장
        
        이로 인해 환경 간 차이를 줄이고, GitHub Actions에서의 빌드 및 배포 과정에서도 일관된 실행 환경 유지
        
        컨테이너화 된 애플리케이션은 플랫폼에 구애받지 않고 아디서든 동일하게 실행 가능
        
        격리된 실행 환경
        
        도커 컨테이너는 각 작업을 독립된 환경에서 실행하므로, 테스트 간의 간섭 방지 및 안정성 향상
        
        GitHub Actions에서 여러 컨테이너를 활용한 병렬 테스트 및 다양한 환경에서 동시 실행이 가능
        
        확장성과 유연성
        
        도커 이미지를 활용해 다양한 버전의 애플리케이션을 손쉽게 테스트하고 배포할 수 있음
        
        GitHub Actions는 여러 환경(OS, 언어 등)에서의 호환성 테스트를 자동화하는데 유용
        
        마이크로서비스 아키텍쳐에서도 개발 컨테이너 활용으로 확장성 높은 Ci/CD 구축 가능
        
        속도 및 리소스 효율성
        
        컨테이너는 가상머신보다 가벼워 빠른 실행과 종료를 지원 ⇒ GitHub Actions 파이프라인의 실행 속도 향상
        
        필요할 때만 컨테이너를 실행하고 종료할 수 있어 불필요한 리소스의 낭비를 줄임
      - 주의 및 고려 사항
        
        러닝 커브
        도커와 GitHub Actions의 설정 및 관리에는 일정 수준의 학습이 필요.
        특히 Dockerfile 작성, 컨테이너 네트워크 구성 등에 대한 이해가 필요하며, 익숙하지 않을 경우 초기 설정에 시간이 소요될 수 있음.
        
        디버깅 복잡성
        컨테이너 내부에 발생하는 문제를 디버깅하는 난이도가 호스트 환경보다 높음.
        원활한 디버깅을 위해 추가적인 도구의 사용이 필요.
        ** 디버깅 도구: docker logs, docker exec, 볼륨 마운트 등
        
        빌드 시간 증가 가능성
        도커 이미지를 빌드하는 과정이 추가되므로, 전체 CI/CD 실행 시간이 늘어날 수 있음.
        이를 최적화 하기 위해 도커의 레이어 캐싱, 멀티스테이지 빌드 또는 GitHub Actions의 캐싱 기능과 같은 최적화 전략을 도입할 필요가 있음.
    - - GitHub에서 제공하는 CI/CD 서비스로,
        GitHub의 원격 코드 저장소와 자연스럽게 통합이 되어
        다른 CI/CD 서비스에 비해 진입 장벽이 낮음
        
        Workflow를 정의하여 코드 변경 시 자동화 작업 수행 가능
    - - Workflows
        GitHub Actions의 최상위 개념이며, Events에 의해 실행되는 자동화된 프로세스.
        YAML 파일로 정의되며 .github/workflows/ 에 저장.
        해당 파일을 트리거(실행)할 규칙이나 동작이 작성되어 있음.
      - Events
        Workflow를 트리거하는 리포지토리의 특정한 활동이나 규칙으로,
        일반적으로는 push, pull request, schedule이 해당된다.
        Workflow 파일 내에 정의되며, 특정 요구사항에 의해
        Workflow를 트리거 하는 사용자 정의 이벤트를 만들 수 있음
      - Runners
        Workflow가 실행되는 인스턴스로 클라우드에서 동작.
        GitHub Actions에서 기본 제공하기 때문에, 다른 CI/CD툴처럼 서버가 필요하지 않음.
        기본적으로 Microsoft의 Azure에서 동작하며, self-hosted-runner 등록 가능.
        각 러너는 한 번에 하나의 작업(Job)만 수행할 수 있다.
      - Jobs
        하나의 Workflow를 구성하는 개별 작업 단위.
        Event로 Workflow가 실행되면 Job에 작성된 명령들이 실행됨.
        Workflow 내에 여러 개의 Jobs를 구성할 수 있으며, 각 Job은 별도의 Runner에서 실행됨.
        종속성에 따라 병렬실행(기본) 또는 순차 실행이 가능하고, 서로 의존 관계를 가질 수 있음.
        병렬 실행 시, 다중 러너가 필요
      - Actions
        Workflow에서 공유 및 결합할 수 있는 재사용 가능한 코드 단위.
        일반적으로 별도의 리포지토리에 저장되며, 해당 리포지토리명으로 Workflow 파일에서 참조됨.
        직접 작성 가능하고, Markey에 등록된 Actions를 가져와 사용 가능.
      - Steps
        하나의 Job을 구성하는 태스크이며, 작업 내 작업의 가장 작은 단위.
        각 스텝은 command나 액션을 실행할 수 있음.
        순차적으로 실행되며 서로 종속됨.
        각 스텝은 동일한 러너 내에서 실행되므로, 스텝 간 데이터 공유가 가능하다.
      - 실행 환경 및 데이터 처리
        
        Environment Variables
        환경 변수는 워크플로우 내의 작업 및 스크립트에서 액세스 할 수 있는 데이터를 저장
        
        Secrets
        액세스 토큰 or API 키와 같은 민감 데이터를 저장하는데 사용하는 암호화된 환경변수.
        로그에 노출되지 않으며, 동일한 리포지토리에서 진행되는 작업을 통해서만 접근 가능.
        
        Artifacts
        워크플로우에서 생성된 파일로, 빌드 출력 또는 테스트 결과와 같이 나중에 저장하고 샤용 가능
        
        Caching
        워크플로우 실행 간에 데이터를 저장하고 검색하는데 사용됨.
        기존에 다운로드한 종속성 또는 빌드 출력을 재사용해 프로세스 속도를 향상시킬 수 있음
    - - 여러 OS 에서 병렬 테스트 가능
        self-hosted-runner 구축 시, 원하는 OS를 지정할 수 있음 (Linux, macOS, Windows 등)
        여러 OS에서 동시에 테스트를 실행해, 호환성 체크 및 크로스 플랫폼테스트 가능
      - 서버 설치 불필요
        GitHub Actions는 완전 관리형 서비스로, 기본 제공되는 클라우드(Azure)를 통해 서버 설치 없이 자동으로 작업을 처리할 수 있어,
        Jenkins와 같은 다른 CI/CD 툴처럼 별도의 서버 관리가 필요하지 않음
      - 비동기 병렬 실행
        여러 개의 Job을 병렬 실행함으로써 CI 파이프라인의 실행 속도 최적화
      - 마켓플레이스 활용
        GitHub Actions 마켓플레이스를 이용해 공개된 actions와 workflow를 손쉽게 찾아서 사용할 수 있으며, 사용자가 자체 개발한 action도 업로드 해서 공유 가능
      - 다양한 배포환경 지원
        GitHub Actions는 AWS, Docker, Kubernetes 등 다양한 배포 환경과의 통합을 지원하여, 손쉽게 다양한 플랫폼에 배포할 수 있음
      - 캐싱, 병렬 실행, 매트릭스 전략을 활용한 최적화
        캐싱을 통해 종속성 등을 캐시하여 빌드 시간 단축이 가능하고,
        병렬 실행을 통해 여러 Job을 동시에 실행해 속도의 최적화가 가능하며,
        매트릭스 전략을 활용해 여러 버전의 환경에서 테스트를 병렬로 실행하는 것이 가능
    - - 자체 캐싱 로직 작성 필요
        캐싱 기능이 제공되기는 하지만, 일부 복잡한 캐싱 로직은 자체적으로 작성해야 할 수 있음
        
        수동 개입 필요
        서버에 장애가 일어나거나 리소스가 초과될 경우, 개발자의 직접적인 개입이 필요
        ex) 사용자가 self-hosted 러너를 운영하는 경우, 자원 관리나 장애 복구를 직접 처리해야 할 수도 있음
    - - Event ⇒ Workflow ⇒ Job ⇒ Step ⇒ Action