유니티 빌드 파일 배포 (GitHub Release)

유니티 빌드 파일은 어떻게 공유하는 것이 좋을까...

Git에는 보통 '소스코드'만 올리고 빌드 결과물은 올리지 않는 것이 원칙이다. 따라서, 깃허브에 유니티 프로젝트를 올릴 때, 유니티 빌드 파일 또한 .gitignore에 의해 올라가지 않는다. 애초에 빌드 파일은 용량도 크고, 변경 이력 추적도 안되기 때문에 올리지 않는 편이 좋다.

그래서, 이번에 사용해 본 것이 바로 GitHub Release이다.

이에 대한 사용 방법은 다음과 같다.

1. 아래 사진에 나온 Releases에서 Create a new release를 클릭한다.

2. 빌드와 관련된 정보를 입력한다.
   • tag : 태그를 입력하는 창인데 보통 버전명을 입력한다 (ex. 초기 버전은 v1.0)
   • Release title : 제목을 적으면 된다. (ex. 첫 빌드!)
   • Write : 여기에는 빌드에 대한 설명을 적으면 된다. Preview를 통해 자신이 작성한 Markdown이 어떻게 사람들에게 보이는 지를 볼 수 있다.
   • Attach binaies... : 이곳에 빌드 파일을 .zip 형태로 압축해서 올리면 된다.
   • Set as a pre-release : 체크하면 테스트용 빌드 버전임을 나타낸다.
   • Publish release : 클릭하면 게시가 완료된다.

3. 릴리즈 완료! 이제 다른 사람이 나의 빌드 파일을 플레이할 수 있다.

이렇게 빌드 파일을 올리다 보니까 우리가 흔히 보는 v1.0.0, v2.3.1과 같은 숫자에 어떤 의미가 담겨있을 지가 궁금해져서 이에 대해서도 조사해 보았다.

이 숫자는 버전이 어떤 식으로 발전해 왔는지를 알려주는 공식적인 체계로 시멘틱 버전(Semantic Versioning)이라고 부른다(줄여서 SemVer).

이에 대한 형식은 아래와 같다.

주요버전(MAJOR).기능버전(MINOR).버그수정버전(PATCH)

• 주요버전(MAJOR) : 호환성이 깨지는 큰 변화(기존 기능 삭제, 구조 대수정 등)
• 기능버전(MINOR) : 새로운 기능 추가(기존 기능 유지)
• 버그수정버전(PATCH) : 버그 수정, 자잘한 개선(기능 변화 없음)

따라서, 첫 빌드는 1.0.0, 이후 버그 수정 빌드는 1.0.1, 이후 기능 추가 빌드는 1.1.0이 되는 것이다. 시멘틱 버전은 최종 상태를 기준으로 잡기 때문에 1.1.1은 기능 추가 후에 버그 수정 빌드를 했다는 뜻이 된다.

오늘은 이와 같이 빌드 파일을 배포하는 방법과 시멘틱 버전에 대해서 알아 보았다.