빌드 환경을 정리해야 했는데 운영에서 쓰는 런타임 버전으로는 패치 없이 빌드가 안 됐다. 손으로 관리하는 패치가 여러 개 쌓여 있었고 누가 언제 왜 넣었는지 알 수 없었다.
Table of contents
Open Table of contents
쌓여 있던 패치 스택
패치들은 네이티브 애드온 빌드를 우회하거나 플랫폼 전용 패키지를 강제로 설치하는 내용이었다. 패치 없이 되는 버전이 있는지를 찾기로 했다.
의존 목록을 보고 각 패키지가 요구하는 런타임 범위를 정리했다. 요구가 위아래로 갈려 있었다.
위아래가 다 막혔다
한 CLI 패키지가 특정 버전 미만을 거부하고 있었다. 그것이 아래쪽 경계였다.
빌드 도구는 오래된 스타일 컴파일러를 하드 의존으로 물고 있었고 그것이 낮은 버전까지만 지원했다. 위아래가 동시에 막혀 있는 상태였다.
하나뿐인 교집합
두 조건을 겹치니 가능한 구간이 아주 좁았다. 그 안에서 실제로 배포된 안정 버전은 하나뿐이었다.
운영은 그 구간 밖의 버전을 쓰고 있었고 그래서 컴파일러가 거부했다. 패치 스택은 그 거부를 우회하려고 쌓인 것이었고 교집합을 계산하고 나서야 패치의 이유가 설명됐다.
정적 분석의 한계
여기까지가 문서와 설정 파일을 읽어 낸 결론이었다. 그런데 확신이 서지 않았다.
의존의 의존까지 다 봤는지와 선택적 의존이 어떻게 되는지와 실제로 네이티브 바인딩이 컴파일되는지가 설정 파일에는 안 나오기 때문이다. 읽어서 얻은 것은 될 것 같다는 수준까지였다.
실제 설치로 한 확정
그래서 컨테이너를 띄워 실제로 설치를 돌렸다. 빌드에 필요한 도구를 깔고 잠금 파일 그대로 설치하니 4분 만에 정상 종료했다.
종료 코드만으로는 부족해서 네이티브 바인딩 디렉터리가 실제로 생겼는지와 그 모듈이 로드되는지까지 확인했다. 그것으로 확정하고 패치 스택을 전부 제거했으며 다른 플랫폼 전용 패키지는 이 환경에서 건너뛰면 되는 것이라 억지 설치도 없앴다. 정적 분석으로 결론이 갈릴 때는 실제 설치를 돌리는 것이 유일한 확정 수단이고 읽어서 후보를 좁힌 뒤 실행해서 확정한다.
정리
- 의존들의 요구 범위를 겹치면 가능한 버전이 나온다
- 교집합이 하나뿐일 수 있고 그러면 선택지가 없다
- 운영이 그 밖의 버전을 쓰면 패치가 그 이유다
- 정적 분석은 될 것 같다까지만 말한다
- 실제 설치를 돌려 확정한다
- 종료 코드와 생성된 바인딩과 로드까지 확인한다
- 이유가 없어진 패치는 남길 이유도 없다
- 툴체인 전체를 명시적으로 고정한다