GoCD에서 GitHub Actions로 마이그레이션

Bahmni CI 파이프라인은 GoCD로 구현되었습니다. GoCD는 호스팅 솔루션이므로 빌드 파이프라인을 실행하려면 EC2 인스턴스를 계속 운영해야 했습니다. GitHub Actions는 필요할 때 실행되는 Runner를 제공하므로 Docker 이미지 빌드와 업로드용 CI 파이프라인을 GitHub Actions로 구현했습니다. 이에 RPM 빌드도 GitHub Actions로 이전하는 계획을 시작했습니다. 다음 다이어그램은 아티팩트와 파이프라인 및 종속 저장소의 관계를 보여 줍니다.

마이그레이션 중 겪은 문제 1: GitHub Actions는 업스트림/다운스트림 파이프라인 구성을 지원하지 않습니다.

이 때문에 아티팩트 빌드 시 일부 의존성을 함께 사용하거나 다운스트림 의존성이 갱신되었을 때 파이프라인을 트리거하기 어려웠습니다.

2. GitHub Actions의 빌드 아티팩트 보존 기간은 최대 90일입니다.

3. RPM을 S3 Yum 저장소에 업로드하려면 워크플로를 실행할 때마다 S3 버킷 전체를 내려받아야 합니다.

Bahmni는 모든 RPM 빌드를 담은 S3 기반 YUM 아티팩트 저장소를 운영하며 크기는 약 400GB입니다. 새 아티팩트를 게시하려면 저장소 메타데이터를 동기화하고 갱신할 수 있도록 전체 내용이 Runner에 있어야 합니다. 매번 이 큰 데이터를 내려받는 것은 현실적이지 않으므로 저장소를 영속화하여 동기화를 빠르게 할 우회책이 필요합니다. 선택지는 다음과 같습니다.관련 문서: artifactory

a. EC2를 GitHub Actions의 Self-hosted Runner로 연결합니다. 보안상 고려가 필요합니다.

b. Nexus를 사용하는 자체 호스팅 Yum 저장소로 이전합니다. 모니터링과 관리가 필요하고 비용이 추가됩니다.

c. 동기화를 수행하는 EC2를 계속 실행합니다. 자동 흐름이 끊기고 수동 개입과 추가 비용이 필요합니다.

위 문제와 향후 몇 차례 릴리스 후 RPM 기반 설치를 종료하고 Docker/Kubernetes 설치만 지원하려는 계획을 고려하여 RPM 빌드 마이그레이션은 보류했습니다.

RPM 빌드는 계속 GoCD에서 수행하지만 GoCD Agent와 CI Server는 릴리스 기간에만 필요에 따라 실행합니다. 릴리스가 끝나면 CI 시스템을 백업하고 EC2 인스턴스를 중지합니다.

다음 표는 개별 RPM 마이그레이션을 완료하고 닫힌 PR 목록입니다.