이기종 환경 전사 CI/CD 플랫폼 구축

동기

고객사 요구로 시작했습니다. SVN 에 코드를 두고 배포는 사람이 하는 상태였고, 그걸 GitLab CI/CD 로 옮기는 것이 과제였습니다.

옮길 대상이 한 가지였다면 어렵지 않았을 텐데, 팀마다 쓰는 것이 달랐습니다. 언어가 Java 와 C# 으로 갈리고, 그에 따라 빌드가 Gradle·Maven·MSBuild 로 갈리고, 도는 OS 도 Linux 와 Windows 로 갈립니다. 팀별로 파이프라인을 하나씩 써 주면 40개를 쓰고 40개를 유지보수하게 되므로, 조합을 흡수하는 템플릿 체계가 필요했습니다.

내가 담당한 트랙

분석·설계부터 템플릿, Nexus, Runner 인프라, 40개 프로젝트 이행, 워크숍과 운영팀 이양까지 전부 제가 했습니다. 항목별 내역은 오른쪽 「주요 업무」에 있습니다.

빌드를 아는 사람이 없었다

Windows 쪽이 가장 오래 걸렸습니다. 파이프라인을 쓰려면 그 빌드를 다른 서버에서 똑같이 돌릴 수 있어야 하는데, 그 빌드가 무엇을 필요로 하는지 아는 사람이 없었습니다. 지금 도는 서버에서는 돌아가지만, 새 서버에서 재현할 수 있는 개발자가 없었습니다.

그래서 반대 방향으로 갔습니다. 새 VM 을 하나 만들어 놓고 빌드를 돌려서, 깨지는 지점마다 무엇이 없어서 깨졌는지를 확인해 하나씩 채웠습니다. 라이선스가 필요한 소프트웨어가 그 과정에서 드러났고, 참조가 걸린 DLL 들도 그렇게 찾아 제자리에 놓았습니다. 빌드가 통과할 때까지 반복해서 만든 그 VM 이 곧 Windows Runner 의 사양이 됐습니다.

의존성이 어디 있었는지가 이 상황의 원인이었습니다. 팀 빌드 서버에 손으로 넣어 둔 것이 있고, SVN 저장소 안에 같이 커밋해 둔 것이 있고, 개인 PC 에만 있는 것도 있었습니다. 그러면 그 PC 나 그 서버에서만 빌드가 되고, 다른 데서 되는지는 아무도 확인해 본 적이 없습니다. Nexus 를 세워 흩어진 것을 한곳으로 모은 이유가 이것입니다.

망이 갈린 채로 같은 템플릿을 쓰기

고객사 망 정책이 개발과 운영을 갈라 놨습니다. 그래서 Runner 를 양쪽에 따로 두고, 각 망에 Linux 와 Windows 를 각각 놓았습니다. 네 종류가 됩니다.

같은 파이프라인이 어디서 돌지는 태그로 고릅니다. 잡마다 어느 망의 어느 OS 를 쓸지 태그로 지정하고, 템플릿은 그 태그를 파라미터로 받습니다. 그러면 개발용과 운영용 파이프라인을 따로 쓰지 않고 같은 템플릿에 값만 다르게 넣게 됩니다. Runner 는 종류마다 이중화해서 한 대가 빠져도 큐가 멈추지 않게 했습니다.

배운 점

• 템플릿화는 문법 작업이 아니라 재현성 작업이었습니다. .gitlab-ci.yml 을 잘 쓰는 것보다, 그 파일이 가리키는 빌드가 아무 서버에서나 같은 결과를 내게 만드는 것이 먼저였습니다. 개인 PC 에만 있는 DLL 이 남아 있으면 템플릿을 아무리 잘 써도 그 프로젝트는 편입되지 않습니다.
• 조합이 늘어날 때 파이프라인을 늘리지 않는 방법을 배웠습니다. 언어·빌드시스템·OS·망을 각각 축으로 두고 축의 값을 파라미터로 받으면, 새 프로젝트가 들어올 때 쓰는 것이 아니라 고르는 일이 됩니다. 40개를 옮기면서 템플릿 수가 프로젝트 수를 따라 늘지 않은 것이 이 방식의 값이었습니다.