OSS (Open Source S/W) - 릴리즈 관리

프로그램 가능한 인터페이스를 제공

 

 

 

도도 포인트 같은 서비스처럼 뚜렷한 버전 번호 없이 업데이트를 해서는 안되고, 프로그램 사이의 호환성에 대한 암시를 줄 수 있는 버전 번호를 제공해야 합니다.

 

따라서 릴리스에 의한 버전 구분이 메인테이너와 이용자 모두에게 뚜렷합니다. 유의적 버전(Semantic Versioning) 같은 규칙이 유용한 까닭도 그러한 배경에 있겠습니다.

 

새 버전 릴리스는 생각보다 신경 쓸 데가 많습니다. 호환성을 고려해서 적절한 버전 번호를 정해야 하고, 이용자들이 어떤 변화가 있었는지 알 수 있어야 합니다.

 

라이브러리 패키지라면 패키지 저장소에도 새 버전을 등록한 뒤 타볼을 업로드해야 하고, 애플리케이션이라면 빌드된 실행 바이너리 파일도 함께 올려야 합니다. 릴리스 프로세스는 생각보다 해야 할 부분 과업이 많고, 부분 과업이 많다는 것은 사람이 실수할 기회도 많다는 뜻입니다. 실수를 줄이려면 많은 부분을 자동화하고, 실수하기 어려운 순서로 프로세스를 개선해야 합니다.

 

---

 

먼저 시스템 내 가장 취약한 부분 혹은 가장 중요한 요소가 무엇인지 파악하고, 중요도의 우선순위를 정하라.

 

또한 어떠한 기준으로 ‘중요도’가 결정되는지도 분명하게 해두라고 한다. 그래야 성능의 리스크를 안고 보안 패치를 적용할 것인지, 아니면 좀 더 지켜본 다음에 패치를 적용할 것인지 결정할 수 있게 된다는 것이다. “즉, 회사 전체적인 패치를 하는 게 아니라 세분화시켜 부분 부분 시행하라는 겁니다.

(http://m.boannews.com/html/detail.html?idx=66314)

---

 

 

체인지로그

이용자들이 문제를 겪을 때 특히 활용도가 높습니다.

 

버전 정책

버전 문자열도 코드

 

하스켈의 카발 같은 몇몇 패키지 시스템은 해당 패키지 시스템이 패키지 메타데이터에 적힌 버전 번호를 런타임에 알 수 있게 API를 제공하기도 합니다.

소프트웨어 버전 번호는 여러 곳에서 나타납니다.

 

 

릴리스한 버전마다 태그 달기

대부분의 버전 관리 시스템에는 태그 기능이 있습니다.

 

 

버전 번호를 올리는 작업을 흔히 버전 범프(version bump)라고 합니다.

 

 

버그 패치를 위한 별도 브랜치 운영

 

패키지 저장소에 업로드 자동화

빌드 자동화

네이티브 바이너리

파이썬이나 자바스크립트 같은 스크립트 언어의 경우 소스 코드 형태로 라이브러리나 애플리케이션을 배포하는 것이 일반적이지만, 고(Go)나 하스켈, 러스트 같이 네이티브 바이너리로 컴파일되는 언어의 경우에는 경우 소스 코드 뿐만 아니라, 이용자가 직접 빌드하지 않고도 손쉽게 써볼 수 있도록 미리 빌드된 바이너리를 제공하는 것이 일반적입니다.

 

요즘에는 저장 공간의 비용이 저렴해진 덕에 애플리케이션이 의존하는 모든 라이브러리까지 통째로 정적 링크하여 배포하는 프로젝트도 늘고 있습니다. 최근에는 도커처럼 가상화된 환경에서 애플리케이션을 쓸 일이 많다보니, glibc 대신 musl 같은 가벼운 대안을 쓰는 환경도 많습니다. 이런 부분도 고려하다 보면 C 런타임까지 모두 정적 링크하여 이용자의 실행 환경과 최대한 독립적으로 쓸 수 있는 실행 바이너리를 만드는 게 도움이 됩니다.

 

빌드 매트릭스

 

네이티브 바이너리를 제공한다면 이용자에게는 편하겠지만, 메인테이너에게는 큰 짐이 됩니다. 예를 들어 32비트 및 64비트 윈도, 맥OS, 리눅스를 지원해야 한다면 어떨까요? 그런데 파이썬 확장 모듈이어서 파이썬 2.7부터 최신의 파이썬 3.6까지 지원해야 한다면? (win32, win64, darwin, linux) ✕ (python2.7, python3.4, python3.5, python3.6) 조합에 해당하는 총 16개의 네이티브 바이너리를 만들어내야 합니다.

이럴 때 쓰기 위한 기능이 빌드 매트릭스입니다. 위에서 말한 것과 같이, 여러 언어 버전, 플랫폼 종류 등을 나열하면, 그 모든 조합에 대한 빌드를 실행하게 해주는 기능입니다. 트래비스 CI도 빌드 매트릭스 기능을 제공하고, 앱 베이어도 제공합니다.

 

 

 

문서화

매 릴리스마다 준비해야 하는 것은 바이너리나 패키지 외에도 많습니다. 그 중 하나가 바로 문서입니다.

문서의 용도에 따라 정도의 차이는 있으나, 소프트웨어 제품의 문서는 소프트웨어 자체의 업데이트와 발을 맞추어야 합니다.

 

문서와 소프트웨어의 변경을 발 맞추기 위해서 꼭 강조하고 싶은 원칙이 하나 있습니다. 문서를 소스 코드 저장소와 함께 보관하세요!

 

 

https://www.servicenow.com/kr/products/itsm/what-is-release-management.html

릴리스 관리란? - ServiceNow

https://asana.com/ko/resources/release-management

릴리스 관리: 성공적인 프로세스를 위한 5가지 단계 [2022] • Asana