About us

Visual Studio 2017와 VCPKG로 CMake 프로젝트 빌드하기

서론

Windows 플랫폼에서 개발을 하다보면 CMake 기반의 프로젝트를 빌드해서 사용해야 하는 경우가 생기는데, 최근까지 가장 많이 사용했던 방법은 Windows 버전의 CMake 툴을 사용해서 MSBuild 프로젝트 파일을 생성한 후, Visual Studio로 열어서 빌드하는 것이었다.

그러나, Visual Studio 2017 Update에 ‘Visual Studio tools for CMake’ 기능이 추가되고, ‘Open folder(폴더 열기)’ 기능과 연동되면서 CMake 기반의 프로젝트를 Visual Studio로 직접 관리 할 수 있게 되었다.

그러나, 패키지를 빌드하다 보면 대부분의 경우, 외부 라이브러리를 참조하게 되는데 Microsoft에서 배포하는 VCPKG라는 C/C++ 라이브러리 관리자를 이용해서 쉽게 해결 할 수 있다.

이번 칼럼에서는 MariaDB의 C/C++ 커넥터 소스코드를 Visual Studio에서 직접 빌드하는 과정을 통해서 CMake 기반의 프로젝트를 빌드하면서 VCPKG를 이용해서 외부 라이브러리 의존성까지 해결하는 과정을 살펴보겠다.

개발 환경 셋팅

a. Visual Studio 2017 Community Edition – Version 15.5 이상 15.4.4 버전에서는 CMake 파일이 제대로 열리지 않았기 때문에 15.4.5 이상의 VS 버전을 추천.
인스톨러에서 CMake for Visual Studio 2017 선택해서 설치한다.

1

b. VCPKG 설치
서드 파티 라이브러리를 쉽게 설치 및 관리 할 수 있게 만들어 주는 Windows 커맨드 라인 툴로 상당히 많은 수의 라이브러리를 각 빌드 타겟(x86, x64, debug, release)별로 설치 할 수 있어 편리하다.

설치 방법은 https://github.com/Microsoft/vcpkg 에 자세히 나와 있기 때문에 생략하도록 하겠다.

2

까지 실행했다면, 패키지 설치는 하지 말고 다음 단계로 넘어가도록 하자.

CMake 프로젝트 열기

a. 자, 준비가 되었다면 Visual Studio에서 CMake 파일을 열어보자.
Visual Studio 2017에서 CMake 프로젝트를 여는 방법은 두가지가 있는데, 파일 -> 열기 ->            CMake 와 “오픈 폴더” 기능 (파일->열기->폴더) 어느 쪽을 사용해도 상관없다.
단,  파일 -> 열기 -> CMake의 경우는 CMakeCache 파일로부터 CMakeSettings.json 파일을         생성한다는 것을 기억 해 두자.

b. 프로젝트를 열면, Visual Studio는 디폴트 타겟(x86 Debug)에 대한 CMake cache를 생성  한다.
메뉴바에 CMake 메뉴가 생성되고, Solution Explorer에 CMake 프로젝트의 하위 폴더들이 정상적으로 나타났다면 일단 성공이다.
CMake cache를 생성하는 과정이기 때문에 CMake파일에 오류가 있다면, Output 콘솔과 에러 목록에 오류 메시지가 표시된다.

CMakeSettings 수정

a. CMake 파일을 로드하면, Visual Studio는 CMakeSettings 파일을 기본 생성하게 되는데, CMake -> Change CMake Settings -> ${Project name} 를 선택하자.

b. Solution Explorer에 CMakeSettings.json 파일이 나타나면서 에디터 창에 파일 내용이 보이는데, 다음과 같은 Configuration 항목들이 나타날 것이다.

4-b.jpg

몇 가지 항목에 대해서만 간단히 설명하자면,
* name : VS 설정 타겟에 표시되는 이름. (${name}으로 사용 가능)
* generator : CMake 파일을 읽어서 실제 빌드 관련 정보를 생성한다. Ninja로 실패하는 경우, 다른 값으로 변경한다. (${generator}로 사용 가능)
* configurationType : generator가 인식할 수 있는 빌드 타입.
* buildRoot : 빌드 관련 파일들이 생성되는 경로.
* installRoot : 결과물이 생성되는 경로.

c. buildRoot와 installRoot의 기본값이 ${env.USERPROFILE} 아래로 잡혀 있는데, 이 부분을 프로젝트 폴더에 포함하도록 수정 해 보자.4-c

d. 이제, buildRoot 디렉토리와 installRoot 디렉토리는 프로젝트 내에 위치할 것이다.

변경 내용을 저장하면, CMakeCache를 다시 생성하게 되고, 출력 창에서 아래와 같은 메시지를 확인 할 수 있을 것이다.

4-d.jpg

cURL 라이브러리를 찾지 못했다는 내용이지만, 사용하지 않도록 설정이 바뀌고 빌드는 정상적으로 진행되는 상태이다.

VCPKG로 의존 패키지 설치하기

a. VCPKG 디렉토리로 이동해서 cURL 패키지를 설치하고, 이것을 프로젝트에서 참조할 수 있도록 CMakeSettings.json 파일을 한 번 더 수정하자.

5-a.jpg

b. 저장하면, CMakeCache가 갱신되면서 출력 창에서 아래와 같이 cURL 라이브러리를 참조하는 것을 확인 할 수 있다.

5-b.jpg

여전히 찾지 못할 경우에는 CMake -> Cache -> Delete Cache Folders 로 캐시를 삭제 하고, CMake -> Cache -> Generate 를 실행해서 Cache를 다시 생성 해 보자.

빌드하기

a. 메뉴바에서 CMake -> Build All 을 실행하면, 빌드가 진행된다.
* * Debug -> Run 또는 Build 메뉴나 CMakeList.txt 파일에서 우클릭으로 메뉴를 열어서 빌드해도 상관없다.

b. 빌드를 마치고 나면, 의도한 대로 프로젝트 폴더 내에 ‘build’ 및 ‘install’ 폴더가 생성되고 결과물이 위치한 것을 확인 할 수 있다.

6-b

마치며

Linux나 macOS같은 Unix/Linux 계열 운영체제에서는 외부 저장소를 사용하는 패키지 매니저를 사용하는 것이 보편적인데, 윈도우즈에는 Nuget 패키지 매니저가 있지만, Unix/Linux 계열의 패키지 매니저와는 사용 방법에서 이질감이 있다.

VCPKG는 아직 보완할 점이 많은 것도 사실인데, 특히, 설치하려는 패키지 버전을 지정할 수 없는 부분은 특정 버전의 패키지를 사용해야 하는 상황에서는 꽤나 답답한 부분이기도 하다.

그렇지만, 간단한 라이브러리까지도 직접 빌드해야 하는 번거로움을 당장 해결할 수 있으며, 장기적으로는 윈도우즈 시스템 전반에 걸쳐서 C/C++ 라이브러리를 관리하기 위한 툴로 발전할 수도 있다.

그동안 Windows용 바이너리를 제공하지 않는 오픈소스 라이브러리의 사용을 고민했던 사용자라면 직접 빌드해서 사용 해 보는 것은 어떤가.

참고 링크
https://mariadb.com/kb/en/library/building-connectorc-from-source/
https://blogs.msdn.microsoft.com/vcblog/2016/11/16/cmake-support-in-visual-studio-the-visual-studio-2017-rc-update/
https://docs.microsoft.com/en-us/cpp/ide/cmake-tools-for-visual-cpp
https://docs.microsoft.com/en-us/cpp/vcpkg

아이펀팩토리 이재원 테크니컬 디렉터

분산 웹 서비스와 JWT

들어가며

6월 컬럼 에서, 분산 시스템에서 인증 처리를 위해서 토큰을 사용하는 부분에 대해서 다뤘다.

많은 웹 서비스들이 외부 서비스와 연동할 이유로, 혹은 외부에 API를 제공하기 위해서 OAuth 토큰을 지원한다.

즉, 이렇게 API 공급하는 쪽이,

  • 사용자를 인증하는 일
  • 인증한 사용자가 특정 API를 호출하는 일

두 가지를 쉽게 분리해서 처리할 수 있게 해준다.

인증/접근 토큰의 한계

이전 컬럼에서도 잠시 다뤘듯이, 토큰은 용도가 용도다 보니 다른 용도로 쓸 때는 부적당할 때가 있다.

  • 토큰에 대한 메타 정보가 포함되어 있지 않다.
  • 토큰이 정말로 발급자가 발급한 것인지 바로 확인할 수 없다.

이걸 확인하기 위해서, 발급자에게 토큰에 대한 정보를 확인해, 필요한 메타 정보를 얻고, 정말로 유효한 토큰인지 확인한다. 이 중에서 유효성 확인 부분은 토큰에 대한 전자 서명이 있는 경우에는 별도 통신 없이도 확인할 수 있다. 하지만 표준화된 방법이 있는 것은 아니라서, 널리 쓰기는 쉽지 않다.

지연 시간 문제

토큰을 확인하기 위해서 별도로 통신하는게 어떤 문제인지 생각해보자.
발급자에게 토큰을 확인한다면 다음과 같은 방식으로 통신이 이뤄진다.

Token 기반 메시지 흐름

인증 서버와 API 서버가 토큰을 확인하기 위해 통신하는 4, 5에서 걸리는 지연 시간이 전체 성능에 영향을 준다.
즉, 클라이언트는 순수하게 API호출을 위해 사용하는 시간에 더해서 4, 5 단계에 걸리는 시간 — 두 서버가 같은 네트워크에 있다면 1ms 정도, 서로 다른 네트워크라면 수십-수백 ms 정도 — 의 지연 시간을 겪게 된다.

JWT 를 OAuth 토큰으로 사용하기

JSON Web Token

RFC 7519 JSON Web Token (JWT) 에서는 JWT를 다음과 같이 설명한다.

JSON Web Token (JWT) is a compact, URL-safe means of representing
claims to be transferred between two parties. The claims in a JWT
are encoded as a JSON object that is used as the payload of a JSON
Web Signature (JWS) structure or as the plaintext of a JSON Web
Encryption (JWE) structure, enabling the claims to be digitally
signed or integrity protected with a Message Authentication Code
(MAC) and/or encrypted.

  • 두 주체 사이에 전달할 용도의 가볍고, URL 에 사용하는데 문제 없게 특정 사항을 표현할 수 있는 방법
  • 이 JWT의 내용은 서명 (MAC) 을 포함한 JWS 나 암호화한 JWE 에 담아서 넘긴다.

이 두 가지 부분을 통해서 위에서 말한 두 가지 한계를 극복할 수 있다.

  • 즉 JWT의 내용 (claim) 에 메타 데이터를 넘길 수 있다.
  • JWS 서명 혹은 JWE 암호화를 이용해서 보낸 주체가 보낸 것을 변조하지 않았음을 알 수 있다.

어떻게 이런 용도로 쓰는지에 대해선 뒤에서 다시 설명하도록 하겠다.

JWT barer 토큰을 OAuth 인증 용도로 이용하기

RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants 에서는 아예 이런 용도로 쓰는 것에 대해서 제안하기도 했다.

예를 들어, POST https://api.example.com/v1/token.oauth2 가 있다면 다음과 같은 요청을 전송한다.

POST /v1/token.oauth2 HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0.
eyJpc3Mi[...생략...].
cC4hiUPo[...생략...]

JWT가 해결하는 문제들

JWT를 API 호출에 이용하기

우선 간단한 예로, 좀 더 단순하고, JWT 원래 목적에 좀 더 부합하게 bearer token 으로 API에 써보겠다.
예를 들어 GET https://api.example.com/v1/cat/ 이라는 APi가 있다고 치자.

GET /v1/cat/ HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: bearer eyJhb[...생략...].eyJpc[...생략...].cC4hi[...생략...]

이런 형식으로 호출하면 고양이 목록을 보내준다고 치자.

JWT 구조

Auth0 의 JWT 페이지 를 이용해서 디버깅해보면 쉽게 따라갈 수 있는 내용이다.
우선 JWT는 세 부분으로 이뤄져 있다.
JWT (JWS) 토큰 하나는 eyJhbGciOiAiUlMyNTYiLCAidHlwIjogIkpXVCJ9.eyJp[...생략...].rnHW[...생략...] 처럼 생겼다.
이 내용은 . 을 기준으로 세 부분으로 분리해서,

  • JOSE header (JSON object signature and encryption header)
  • Claim: JWT 가 포함하는 내용에 대한 것
  • Signature: JWT 헤더와 claim 부분에 대한 서명 (MAC)

이렇게 구분하며, 각각 base64 (URL safe한 변형) 으로 인코딩되어 있다.
흔히 쓰는 (표준) base64 대신에 URL safe 한 변형 — / 대신 _, + 대신 - 를 사용 — 을 쓰는 것은, JWT 가 URL의 일부 (GET param 이라거나)나 HTTP header 로 넘기려는 목적이라서다.

Header

JOSE 헤더를 보면,

{
"typ": "JWT",
"alg": "RS256"
}

대부분 간단한 두 가지 내용만 포함된다. 우선 이게 JSON web token이라는 typ 필드. 그리고 어떤 방식의 서명을 쓰는지에 대한 alg 필드가 있다. 여기서는 RSA + SHA2 (256) 을 사용한다. 가능한 algorithm (=alg) 에 대해서는 서명 부분에서 다시 설명하겠다.

참고로, compact 한 표현형을 쓰는게 표준의 목적이라, 정의하고 있는 필드 명은 대부분 짧다. (3자이하)

Claim

토큰이 어떤 내용 을 가지고 있는지에 대한 부분이다. 꼭 필요한 필드는 따로 없으며, 대부분 포함하는 필드 — 예를 들어 만료 시간인 exp — 가 있기는 하다.. 예를 들면, 아래와 같은게 가능하다.

{
"iss": "john.doe",
"aud": "client-id",
"iat": 1212050400,
"exp": 1512054000,
"permissions": [{"type": "cat", "action": ["read", "create", "updtae"]}]
}

발행 주체 (iss) 가 아무개이고, 만료 시간은 12-01이다. 위에 보이는 permissions 는 따로 표준으로 정하는 주체가 없는 private claim 이라고 부르는 맘대로 정해서 쓴 부분이다. (iat, aud 등도 흔히 쓰이는 공개 필드이지만, 여기서의 설명은 생략한다.)

Signature

서명이라고하기엔 조심스러운게, 여기에 올 수 있는 것은 전자 서명이 아니라 MAC (메시지 인증 코드; message authentication code) 다. 그래서 알고리즘에 따라서는
메시지가 변경되었는지 (tampered) 확인하려면 인증 서버에 다시 물어봐야할 수 있다.

여기서 alg 에 해당하는 알고리즘으로 사용하는 것은

  • HS256: HMAC + SHA256
  • RS256: RSA + SHA256
  • ES256: ECDSA + SHA256

같은 값이다. (MAC 알고리즘과 HASH bit 수에 따라 몇 가지 버전이 더 있다.)
이 중 RS256, ES256 만 전자 서명 알고리즘이고, HS256은 HMAC 알고리즘이다. 만약 HS256 혹은 이와 유사한 알고리즘을 쓰면 발행 주체와, 토큰 처리하는 주체가 같은 비밀 값을 공유해야 서명을 처리할 수 있다. (공개키 서명 방식인 RS256, ES256 같은 류는 공개키만 미리 전달받으면 직접 검증할 수 있다)

JWT + 공개키 서명을 쓴 경우의 흐름

JWT 공개키 서명 처리

이전 다이어그램과 비교해보면 토큰 확인을 위해서 인증 서버와 API서버가 통신하는 부분이 빠졌다.
JWT claim 을 해석하고 서명을 검증하는 작업은 수십-수백 us 정도의 작업이라, 이전과 비교하면 지연 시간에 상당한 이득이 있다.

문제 해결

즉, 위 내용의 claim 으로 메타 정보가 없는 문제를 해결한다.
그리고 (특정 서명 알고리즘에 한해서) 원격 서버에 다시 물어보지 않고도 토큰이 올바른지 확인할 수 있다. 다만 exp 부분을 써서 만료 시한을 따로 관리하지 않는다면 이 부분은 문제가 될 수 있으니 구현할 때 확인해보길 권장한다.

맺으며

일정 규모 이상의 게임 서비스든 웹 서비스든, 우리가 만드는 시스템은 더 많은 요청을 처리하기 위해서 결국 분산 시스템의 형태를 갖게 된다.
컴퓨터 공학의 많은 문제가 “추상화 계층”을 추가하는 방식으로 문제를 해결하는데 (혹은 숨기는데), 여기서도 인증 부분을 별도 서비스로 분리시키는 방법을 쓰는 경우가 흔하다.
이런 서비스 간 분리가 있으면 필연적으로 통신에 따른 지연 시간이 문제가 되는데, 표준화된 토큰인 JWT와 공개키 서명 방법을 이용해서 어느 정도 이 문제를 줄일 수 있다.

 

아이펀팩토리 김진욱 CTO

[G-STAR 2017] B2B관에서 아이펀팩토리를 만나세요!

 

11월 16일부터 부산에서 열리는 국내 최대 게임쇼, G-STAR 2017에 아이펀팩토리가 참가합니다!

★ 서버 개발, 무엇이든 물어보세요!  아이펀팩토리 부스 이벤트(B2B관 3층 #T09)

아이펀팩토리 부스에서는 현재 제작 중인 게임의 서버에 대한 궁금증을 속 시원하게 날려줄 ‘서버 무료 컨설팅’과 함께 다양한 이벤트가 준비될 예정이랍니다. 이벤트 참여하시고 알찬 선물 받아 가세요! 

★ 네이버 클라우드 플랫폼 세미나 – 아이펀팩토리 세션 진행!

11/16(목) 벡스코 제1전시장에서 열리는 네이버 클라우드 플랫폼 세미나에서는 ‘클라우드 환경에서 게임서비스 개발/런칭 쉽게 하기’라는 주제로 아이펀팩토리의 세션이 진행됩니다. 많은 참여 부탁드립니다!


홍보디자인_뉴스레터_블로그_사이즈수정

Jenkins 와 Unity3D 의 headless build 를 이용한 build 자동화

이 번 글에서는 Unity 로 만들어진 프로젝트를 Jenkins 를 통해 빌드 자동화 하는 것을 알아보도록 하겠다.
이 예제에서는 Mac 에 설치된 Unity 를 호출해서 빌드하는 것을 가정한다. 전체 흐름은 다음과 같다.

1. Jenkins 의 빌드 번호 등 빌드 환경 정보를 JSON 파일로 저장한다
2. Jenkins 가 Unity 의 editor script 를 batch mode 로 실행하고, editor script 는 앞의 JSON 형태의 정보를 넘겨 받아 빌드 결과물을 생성한다.
3. Jenkins 에서 Google drive 나 windows 공유 폴더 등에 결과물을 복사한다.
4. 팀원들이 다 같이 즐겁게 새 빌드를 플레이한다.

아래에 각 단계별로 좀 더 자세한 설명을 하도록 하겠다. 설명 중에 인용되는 코드는 좀 더 쉽게 읽히게 하기 위해서 에러 처리 등을 제외하고 단순화시켰다.

Step 1. 빌드 정보를 JSON 파일로 넘겨주기

빌드 자동화를 하게 되면 여러 빌드 파일이 생성되는데 이를 구분하기 위해서는 각 결과물에 빌드 번호를 포함하는 것이 편리할 것이다. 빌드 번호는 Jenkins 가 자동으로 생성해주는데, 이 정보를 활용하기 위해서는 Jenkins 의 빌드 번호 정보를 뒤에서 설명하는 Unity script 에 넘겨줄 필요가 있다. 여기서는 간단하게 JSON 파일 안에 빌드 정보를 포함하게 하고 Unity script 에서 이를 읽어서 빌드 번호를 추출하는 것으로 하겠다.

먼저 Jenkins 상에서 새로 아이템을 만들어준다.
Jenkins 설정에 따라 소스 저장소를 모니터링 하다가 새로 소스 저장소에 커밋되는 내용이 있으면 자동으로 빌드 아이템이 실행되게 할 수도 있고, 아니면 몇시간에 한 번씩 주기적으로 빌드를 만들어내게 설정할 수도 있다. 이 부분은 Jenkins 의 표준적인 설정 환경이니 Jenkins 매뉴얼을 참고하길 바란다.

해당 아이템에서 shell command 설정 부분이 핵심적인 부분인데, 다음과 같은 내용을 포함시킨다.

cat > convert.py <<EOF2
import json

conf = {}
conf[‘build_number’] = $BUILD_NUMBER
conf[‘apk’] = {
 “sdk_relative_path” : “NVPACK/android-sdk-macosx”   # android sdk 의 주소를 기입한다.
}

print json.dumps(conf, indent=2)
EOF2

python ./convert.py > build_config.json2
mv build_config.json2 build_config.json

그리고 나서는 별도의 shell command 로 아래에 설명되는 Unity editor script 를 호출해준다.

<code>
/Applications/Unity/Unity.app/Contents/MacOS/Unity -batchmode -logFile build.log -projectPath \$PWD -quit -nographics -executeMethod iFunFactoryEditorScript.BuildApk
</code>

Step 2. Unity editor script 에서 빌드 번호 받아서 실제 APK 파일 생성하기

Unity 의 Assets/Editor 디렉토리 아래 ScriptableObject 를 상속받은 C# class 를 포함하는 C# 스크립트를 추가함으로써 editor script 를 포함시킬 수 있다.

아래는 아이펀팩토리에서 사용되는 ifunfactory.cs 내용이다. 앞 단계에서 호출한 BuildApk 라는 함수가 static 으로 선언된 것을 확인할 수 있을 것이다.

1

우리는 이 스크립트에서 앞서 JSON 으로 넘겨준 build 번호를 넘겨 받아서 PlayerSettings 에 세팅함으로써, 최종 생성될 APK 에 포함될 version 번호를 지정할 수 있다.
아래는 이 코드의 예시이다.

<code>
JSONClass conf = JSON.Parse(System.IO.File.ReadAllText(“build_config.json”)).AsObject;
JSONClass backup = new JSONClass();

int build_number = conf[“build_number”].AsInt;
PlayerSettings.bundleVersion = “1.0.0.” + build_number;

JSONClass apk_conf = conf[“apk”].AsObject;
PlayerSettings.Android.bundleVersionCode = conf[“build_number”].AsInt;

string product_name = PlayerSettings.productName;
string output1 = product_name + “-” + conf[“build_number”].AsInt + “-unaligned.apk”;
string apk_name = product_name + “-” + conf[“build_number”].AsInt + “.apk”;
</code>

이제 기본적인 준비가 끝났으니 실제 APK 를 생성한다. 이 과정은 다음과 같이 BuildPipeline.BuildPlayer() 를 호출하는 것만으로 가능하다. 이 때 첫번째 인자로 빌드할 scene 의 리스트를 문자열 배열로 넘겨준다.

<code>
string[] scenes = [“scene1”, “scene2”];
BuildPipeline.BuildPlayer(scenes, output1, BuildTarget.Android, BuildOptions.None);
</code>

그런데 생성되는 APK 는 jarsigner 와 zipalign 을 거쳐야된다. 그렇기 때문에 다음과 같은 코드를 추가한다.

<code>
// Runs jarsigner on the generated apk file.
UnityEngine.Debug.Log(“Running jarsinger”);
Process jarsigner = new Process{StartInfo = new ProcessStartInfo{FileName = “jarsigner”, Arguments = “-verify -verbose ” + output1, UseShellExecute = false, RedirectStandardOutput = true}};
jarsigner.Start();
jarsigner.WaitForExit();

// Makes the generated apk file aligned.
UnityEngine.Debug.Log(“Running zipalign”);
string android_sdk_path = Environment.GetFolderPath(Environment.SpecialFolder.Personal) + “/” + apk_conf[“sdk_relative_path”].Value;
Process zipalign = new Process{StartInfo = new ProcessStartInfo{FileName = android_sdk_path + “/tools/zipalign”, Arguments = “-f -v 4 ” + output1 + ” ” + apk_name, UseShellExecute = false, RedirectStandardOutput = true}};
zipalign.Start();
zipalign.WaitForExit();
</code>

이렇게 생성된 APK 파일은 빌드 번호가 파일 이름에도 포함되고, 실제 apk 를 설치했을 때도 제대로 된 build 번호가 표시될 것이다.

끝으로 Jenkins 의 post-build action 으로 apk 파일을 archive 하게 해서 Jenkins 상에 저장할 수 있다. 여기까지로 작업을 완료할 수도 있지만, 만일 공유 폴더로 파일을 복사하고 싶은 경우 Jenkins 상에서 별도의 shell command 로 cp 명령을 추가해주면 된다.

단순한 Jenkins script 와 Unity editor script 로 손쉽게 unity project 의 빌드 자동화를 완성했다. 유사한 방식으로 APK 뿐만 아니라 iOS 용 IPA 를 생성하는 것도 가능한데, 이 부분은 여러분이 직접 시도해보면 좋을 것 같다.

아이펀팩토리 문대경 CEO

[유니티 로드쇼 2017] 아이펀팩토리가 전국 개발자 여러분을 찾아갑니다!

아이펀팩토리가 ‘유니티 로드쇼 2017(Unity Roadshow 2017)’의 외부 강연자로 전국의 개발자 여러분을 찾아갑니다!

오는 10월 17일 부산을 시작으로 전국 6개 도시에서 개최되는 유니티 로드쇼에서 아이펀팩토리가 함께 하는 기술 강연! 생생한 개발 실무와 노하우를 들을 수 있는 기회를 놓치지 마세요!

★ 강연시간: 전국 6개 지역 14:50~15:20
★ 강연제목:
쾌적한 서비스 운영을 위한 모니터링 시스템 구축
★ 강연소개:
게임 서버의 성능 지표 모니터링은 실제 라이브 단계에서 뿐만 아니라, 게임 출시 전 스트레스 테스트 단계에서 잠재적인 병목을 찾아내기 위해서도 필요한 기능입니다. 성능 지표 모니터링은 크게 OS 수준에서의 성능 지표, 서버 프로세스 수준에서의 성능 지표, 그리고 게임 수준에서의 성능 지표로 구분할 수 있습니다. 이 발표에서는 이 중 내부 counter 를 이용해 게임 수준에서의 성능 지표 모니터링을 구현하고 이를 활용하는 방법에 대해서 설명합니다.

 온라인홍보2