# 프로젝트 BuildScheme 분리

> `BuildScheme` 이란, 프로젝트 코드 작성 후 Cmd + R 명령으로 빌드작업을 하는데, 이때 어떤 환경에서 빌드를 할 것인지 나타내주는 역할을 합니다. 현재 PIECE 프로젝트에서는 빌드스킴이 `AppStore` 와 `piece-ios` 가 존재합니다. (하지만 piece-ios 는 사용하지 않고 있습니다.)

<사진 1>

>`BuildScheme` 에서는 Build Configuration을 정의해줄 수 있습니다.

>현재 `AppStore` 빌드스킴설정 화면입니다. 상황에 따라 Build, Run, Test, Profile, Analyze, Archive 가 있는데, 저희가 주로 사용하는 것은 Run(Cmd+R) 과 Archive(테스트플라이트 업로드) 입니다.
> 각 상황마다 `Build Configuration` 을 선택해줄 수 있습니다.

<사진 2>

> 현재 프로젝트에 존재하는 Configuration 은 `Debug` 와 `Release` 가 있습니다.

<사진 3>

## AS-IS

저희 피스앱의 서버는 `dev`, `stage`, `live` 세가지로 구분됩니다. 현재는 각 경우를 테스트 하기 위해 코드단(사진<1> 코드 15번 줄)에서 case 를 바꿔주고 있는 형태로 구성되어 있습니다.

//  Api.swift
import Foundation

enum ApiServer {
    case dev, stage, live
}

class Api {
    static var server: ApiServer = .live // 여기서 코드를 바꿔주는 형태 .live, .dev, .stage
    static var apiVersion: String = "v0.0.2"
    
    // Api server
    static var baseUrl: String {
        switch self.server {
            case .dev:
                return "https://fdev-gateway.piece.la/v3"
            case .stage:
                return "https://fstage-gateway.piece.la/v3"
            case .live:
                return "https://gateway.piece.run/v3"
        }
    }
    
    // Web Socket server
    static var baseWebSocketUrl: String {
        switch self.server {
            case .dev:
                return "wss://dev-websocket.piece.la"
            case .stage:
                return "wss://stage-websocket.piece.la"
            case .live:
                return "wss://websocket.piece.run"
        }
    }
    
    // Web View URL
    static var webViewUrl: String {
        switch self.server {
            case .dev:
                return "http://dev.piece.run:0000"
            case .stage:
                return "http://stage.piece.la:0000"
            case .live:
                return "http://prod.piece.run:0000"
        }
    }
    
    static let timeout: Double = 60
}

### 문제점

#### 시나리오

- 개발 결과물 확인을 위해 "개발서버" 또는 "스테이지서버" 또는 "운영서버" 로 말아서 보여달라는 요청
- 서버를 번갈아 가며 확인해야 할 때, "개발서버" 빌드 후 결과물 확인 -> "운영서버" 빌드 후 결과물 확인
- 위 과정 n번 반복 시, 결과물 확인에 걸리는 총 시간 = 빌드시간(약 5분 ~10분) x n

## TO-BE

### 해결방법

- 빌드스킴을 필요에 따라 여러개를 만들 수 있다는 점을 활용하여 필요한 경우를 헤아립니다.
- 현재는 Dev, Stage, Live 세가지로 나눌 수 있습니다. (필요에 따라 QA 버전도 추가가능)
- Dev, Stage, Live 세 개의 빌드스킴에 적용시킬 세 개의 Build Configuration을 정의해줍니다.
- 각 스킴의 차이점은 baseUrl, baseWebSocketUrl, webViewUrl 입니다.


- 위처럼 각 Scheme에 적용시킬 Configurations 파일을 만들어 그 안에 환경변수 리스트를 정의합니다.

// Dev.xcconfig 파일 

BASE_URL = https:/$()/Develop/Server
DISPLAY_NAME = PIEZE(Dev)
APP_IDENTIFIER = com.PIEZE.Dev
APP_FLAG = Dev

-------------------------------------

// Stage.xcconfig 파일 

BASE_URL = https:/$()/Stage/Server
DISPLAY_NAME = PIEZE(Stage)
APP_IDENTIFIER = com.PIEZE.Stage
APP_FLAG = Stage

-------------------------------------

// Live.xcconfig 파일 

BASE_URL = https:/$()/Live/Server
DISPLAY_NAME = PIEZE

APP_IDENTIFIER = com.PIEZE.Live
APP_FLAG = Live

-------------------------------------


Build Settings - Packaging 내부
"Product Bundle Identifier" 에 $(APP_IDENTIFIER) 를 적용 - 각각의 번들ID가 달라야 다른 앱으로 build 됨
"Product Name" 에 $(DISPLAY_NAME) 를 적용 - 각각의 앱의 이름

### 해결

#### 시나리오
- 개발 결과물 확인을 위해 "개발서버" 또는 "스테이지서버" 또는 "운영서버" 로 말아서 보여달라는 요청
- 서버를 번갈아 가며 확인해야 할 때, 개발서버앱, 스테이지서버앱, 운영서버앱 3개를 한번에 빌드후 앱간 이동을 하며 비교 가능


#### 개발 중 Preview 이용 시 주의할 점

- 앱이 3개로 생성되어, 개발 중 Scheme을 변경하면서 Preview를 확인하려면, Scheme을 변경할 때마다 commandline build Configuration도 함께 Switch 해주어야 합니다.


릴리즈 시, 개발자 실수로 인해 아카이빙을 잘못하는 실수발생 방지목적

## References

[참조 블로그](https://ios-development.tistory.com/660)