Go 패키지 생성에서 버전관리까지

개요

GitHub 에서의 go 프로젝트 생성과 versioning 과정을 코드로 정리해 보고자 한다.

Semantic 버전관리

Go에서는 패키지 버저닝을 위해 Semantic Versioning을 사용하길 제안하고 있으며, 간단하게 정리를 하자면 다음과 같다.

  • 기존 버전과 비호환 되며 API가 바뀌면 “MAJOR 버전”을 올리고,
  • 기존 버전과 호환 되면서 새로운 기능을 추가 할 때는 “MINOR 버전”을 올리고,
  • 기존 버전과 호환 되면서 버그를 수정 한 것이라면 “PATCH 버전”을 올린다.

프로젝트 레이아웃 생성

go 프로젝트에 공식적으로 잡힌 표준은 없으나 커뮤니티에서 잡힌 레이아웃은 존재하는 모양이다. 별 다른 제안이 없어서 GitHub에 공유된 “GitHub – Standard Go Project Layout” 프로젝트 레이아웃을 참고해서 사용하고 있고, 몇 가지는 내 입맛에 맞게 사용하고 있다.

아래 링크는 GopherCon 2018에서 발표된 Go 애플리케이션 구조에 대한 발표이고 간단하고 쉽게 참고할 만해서 적어둔다.

아래는 Go 애플리케이션 설계에 대한 번역글

Github 에서 Go 패키지 버전관리 하기

vgo modules 가 1.11.1 에 go mod 내부에 도입 된 이후에, modules 가 패키지 버전을 인식하는 방식에 대해 알아보자.

아래는 go modules 버전관리 방법을 가장 간단하게 나타낸 이미지이며, Defining Go Modules 문서를 참고했다.

 

 

간단하게 설명하면 Major 버전 2.x 대가 되기전까지는 master 에서 tag 를 새로 따서 배포를 하고, 2.x 대가 넘어가게 되는 경우에는 v2 라는 이름으로 새로운 브랜치를 생성한 후에 go.mod 의 모듈패스에 /v2 와 같이 새로운 버전을 표기 하고 태그로 배포를 하는 형식이다.

다시 정리하면 버전 2.x 전까지는 master 에서 tag 로 배포, 2.x 이후 부터는 Major 버전 별로 브랜치를 생성해서 관리 하도록 한다.

hello 패키지 생성

이해를 돕기 위해 hello라는 패키지를 Github 에 생성하고 배포하는 것을 가정하여 작성해봤다.

첫 hello v0.1.0 버전 릴리즈

v2 대 이하에서는 go 소스코드에서 import 도 아래와 같이 그대로 작성하면 된다.

v2.x 릴리즈를 위한 브랜치 생성

v2.x 이상은 브랜치를 새로 생성하여 관리하도록 한다

v2.x 릴리즈를 위한 go.mod 수정

go.mod 상단을 아래와 같이 끝에 브랜치 버전 수정

v2.x 릴리즈 반영

아래와 같이 변경점 반영 후 v2.0.0 릴리즈

위와 같이 v2 대 이상에서는 go 소스코드에서 아래와 같이 브랜치 버전을 같이 표기하여 import 하도록 한다.

버전 표기하여 실행파일 빌드하기

-ldflags 빌드옵션으로 바이너리 파일에 Version이나 빌드일시, Git Revision등을 전역 변수로 넘겨서, 실행 파일이 어떤 버전을 컴파일 한 것인지 표기하도록 해보자

아래는 실행시 간단한 예시이며, 실행 파일의 버전과 빌드일시, 리비전을 확인 할 수 있다.

다음은 Go 실행파일 내부에서 -ldflags 변수 받는 부분

다음은 shell script 또는 Makefile 에서 빌드할때 예시이다. 더 많은 링크 명령어는 다음을 참고

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑