분산 형상관리 통합 및 CI/CD 표준화

동기

형상관리가 세 곳에 흩어져 있었습니다. SVN 을 쓰는 팀, 따로 세운 GitLab 을 쓰는 팀, 개발자 PC 에서 빌드해 서버로 올리는 프로젝트가 함께 있었습니다. 이 상태로도 개발은 돌아갑니다. 각자 자기 방식에 익숙하니까요.

고객이 통합을 요구한 이유는 거버넌스였습니다. 변경이 어디서 어떻게 들어갔는지 한자리에서 볼 수 없었고, 병합 요청에 리뷰어를 세우려면 먼저 모두가 같은 곳에서 병합을 해야 합니다.

내가 담당한 트랙

SVN·자체 GitLab·로컬 빌드로 흩어져 있던 형상관리를 단일 GitLab 으로 통합하고, 저장소 이관·표준 템플릿 체계·저장소별 컨테이너화·C 빌드 자동화·인프라 모니터링을 했습니다. 이관을 개발자들에게 맡기지 않고 우리 쪽에서 옮긴 뒤 넘겼습니다. 항목별 내역은 오른쪽 「주요 업무」에 있습니다.

SVN 이력 이관

커밋을 Git 으로 넘기는 것 자체는 도구가 합니다. 손이 가는 쪽은 저자 정보입니다. SVN 은 커밋을 계정 하나로 남기는데 Git 의 저자는 이름과 이메일 쌍입니다. 그 대응을 만들지 않고 옮기면 이력은 다 살아 있는데 누가 썼는지가 전부 남남이 됩니다. git blame 이 낯선 계정만 뱉으면 옮겨 온 이력은 조회는 되지만 아무도 안 봅니다.

그래서 계정 대조표를 만들어 매핑한 뒤 옮겼습니다.

템플릿과 저장소별 빌드 전제

조합별 템플릿은 금방 끝날 것처럼 보였습니다. OS 와 빌드 시스템과 배포 방식의 조합을 세고 각각에 맞는 템플릿을 두고, include 로 중앙에서 관리하면 새 프로젝트는 몇 줄만 적으면 됩니다. 그 부분은 설계한 대로 됐습니다.

시간을 먹은 것은 그다음입니다. 저장소마다 빌드 전제가 달랐습니다. 어떤 것은 Java 8 이고 어떤 것은 21 이라 JDK 버전별로 이미지를 따로 만들어야 했고, 개발자 PC 나 빌드 서버에 이미 깔려 있어서 아무도 적어 두지 않은 것들이 이미지 안에는 없었습니다. 로컬에서 되던 빌드가 컨테이너에서 안 되는 이유를 저장소마다 찾아 Dockerfile 로 적어 내리는 것이 이 프로젝트에서 제일 오래 걸린 일이었습니다.

빌드는 Kaniko 로 굽습니다. 특권 컨테이너를 쓸 수 없는 환경이었기 때문입니다. 컨테이너 안에서 이미지를 만들려면 보통 호스트의 도커를 빌려 오거나 컨테이너에 특권을 줘서 그 안에 도커 데몬을 띄워야 하는데, 둘 다 빌드 컨테이너에 호스트를 건드릴 힘을 쥐여 주는 일이라 막혀 있었습니다. Kaniko 는 데몬 없이 유저스페이스에서 Dockerfile 명령을 하나씩 실행하고 각 단계 뒤 파일시스템을 스냅숏해 레이어를 만들기 때문에 그 힘이 필요 없습니다.

컨테이너화에서 뺀 것

C 프로젝트는 컨테이너로 들어가지 못했습니다. 빌드가 그 서버에 깔린 것들에 붙어 있어서, 이미지로 옮기려면 서버를 통째로 다시 만드는 일이 됩니다.

그래서 원래 있던 빌드 서버를 그대로 두고 파이프라인만 연결했습니다. 형상관리와 실행 시점은 GitLab 이 쥐고, 빌드는 예전 그 자리에서 돕니다. 전부 같은 모양으로 만들자고 했으면 이 구간이 프로젝트 끝까지 안 끝났을 것이고, 옮길 수 있었던 것들의 일정까지 같이 늦어졌을 겁니다.

배운 점

• 도구가 옮겨 주는 것과 옮긴 뒤에 쓸 수 있는 것은 다릅니다. 이력을 살렸다고 말하려면 그 이력을 조회했을 때 아는 이름이 나와야 합니다.
• 조합 매트릭스를 촘촘히 짜도 저장소마다 그 환경에만 있던 것이 하나씩 나옵니다. 표준화의 작업량은 표준을 정하는 데가 아니라 예외를 하나씩 없애는 데 있었습니다.
• 컨테이너로 못 들어가는 것을 붙들고 있으면 그 하나 때문에 전체가 멈춥니다. 어디까지 옮기고 어디부터는 그대로 두되 자동화만 얹을지를 초반에 정한 것이 이 프로젝트에서 값이 제일 나간 결정이었습니다.