리눅스 환경에서 버전 관리

한 줄 요약: 블로그 명령어 믿지 말자. 할 거면 링크 주고 이 사이트 보고 진행하겠다고 말하자

서론

팀 문서를 보고 작업하다 버전 업이 필요하단 부분이 있었다.

블로그에서 버전 업에 관한 포스팅을 찾아보고 진행하던 중 굳이 이렇게 해야 하나? 싶은 부분이 있었다

아무리 생각해도 좀 아닌 거 같아서 물어봤지만, 이미 이전 명령어를 수행했던 시점에서 문제가 발생해버렸다.

apt-get(yum)? wget?

패키지 설치 시 apt-get이나 wget으로 설치하는 글 2가지로 나뉜다.

 

예외가 있겠지만 대부분의 상황에선 wget이다.

만약 서버에 구 버전이 있는 경우 버전업 하지 말고 wget으로 다운로드한 폴더의 bin에 들어가서 해당 버전에 맞춰 레포를 빌드하거나 실행하자

 

apt-get 은 삭제해도 잔존물이 남아있거나 설정이 바뀔 수 있어 위험하다.

 

대부분 포스팅들은 그냥 개인 환경에서 끄적거리고 되네? 하는 식으로 작성하기 때문에 이걸 서비스 중인 서버에 그대로 적용하는 건 매우 위험하다

버전 관리는 조심히

당연한 말이겠지만 이론하고 실전하곤 많이 달랐다.

 

버전이 있다면 메이저 버전, 마이너 버전, 패치 버전으로 나누고 각 자릿수마다 특징이 있다.

또한 시맨틱 버전을 사용해 버전 호환을 명시한다.

 

하지만 사용 중인 오픈소스가 업데이트가 느리고 많이 사용되지 않는 경우 패치 버전만 바꿔도 문제가 발생한다.

그런 걸 누가써? 라고 하지만 도메인 특화면 써야 한다.

 

매뉴얼엔 오픈소스를 구동하기 위한 라이브러리 a.b.3 버전을 설치했다 나와있었지만 저장소엔 a.b.12 버전까지 나와있었다.

당연히 버그들이 수정됐으니 해당 마이너 버전 중에선 가장 안정적일 거라 생각했다.

하지만 설치하는데 의존성 쪽에서 command not found 같은 답 없는 오류들이 나왔고, 오류 카피해서 검색하거나 이슈탭을 봐도 관련 내용이 없었다.

결국 a.b.3을 다시 설치했고 오픈소스는 잘 돌아갔다.

왜 이럴까?

뇌피셜이긴 하지만 이런 이유였던 것 같다.

 

라이브러리 a.b.3 버전에서 발생하는 버그를 다른 의존성 패키지에서 거기에 맞춰 수정을 했다.

하지만, 그 이후 버전에서 해당 패치가 이루어졌지만 관련 의존성에선 맞춰서 수정하지 못 했던 것 같다.

예를 들면 나누기 2를 안 하는 버그가 있어서 의존성 쪽에서 넣어줬지만, 버그가 패치되면서 나누기 2가 두 번 됐다고 보면 된다.

 

이런 에러가 있는데 왜 이슈탭에 없을까? 라고 생각을 했지만, 워낙 사용하는 사람이 없으니 다들 체념하고 다운그레이드 한것 같다. 아니면 a.b.12 버전으로 설치한 사람이 없거나

 

레거시 걷어내는 것은 팀원들의 노력도 중요하지만 의존성도 중요하단 것을 알았다.