III. 개발/라이브 동일시하기(Dev/prod parity)
개발 버전과 테스트 버전, 그리고 라이브 버전을 가능한한 똑같이 만드세요.
GitHub에서 수정하기역사적으로, 개발 버전(개발자가 로컬에서 실시간으로 수정하는 앱)과 라이브 버전(App Store에 접근하는 엔드 유저에게 배포되는 앱)에 대한 차이가 상당해왔습니다. 이러한 차이는 세 가지로 나눠볼 수 있습니다.
- 시간적 차이: 개발자는 라이브에 추가할 코드를 위해 며칠, 몇 주, 몇 달 동안 작업합니다.
- 인원적 차이: 모든 iOS 개발자는 코드를 작성하고, 단 한 명만이 앱을 배포하는 방법을 알고 있는 경우도 있습니다.
- 도구의 차이: 개발자들은 라이브에서 돌아가는 것과는 다른 스테이지 서버를 사용할 것입니다. 개발자들은 배포에 사용된 Xcode 릴리즈와는 다른 버전을 사용하고 있을 것입니다.
iOS-factor 앱이라면 지속적인 배포를 위해 디자인되어서 개발 버전과 라이브 버전간의 차이를 최소화해야 합니다. 위에서 설명한 세가지에 대해 더 알아보겠습니다.
- 시간적인 차이를 줄이는 방법: 개발자가 코드를 작성한 후 며칠안에 배포하세요.
- 인원적인 차이를 줄이는 방법: 개발자가 코드를 작성했다면 배포하고 라이브 버전에 긴밀하게 관여해서 행동을 관찰하게 하세요. 이것은 iOS 앱의 출시 과정을 완벽하게 자동화하고 문서 대신에 코드 선언시에 노하우를 표시하세요.
- 도구적인 차이를 줄이는 방법: 개발 버전과 라이브 버전을 최대한 비슷하게 유지하세요. 디펜던시 문서에 있는 규칙들을 따르고
.xcode-version
파일을 사용하며 모든 디펜던시를 명시적으로 정의하세요.
위의 내용을 테이블로 요약하자면 다음과 같습니다.
전통적인 iOS 앱 | iOS-factor 앱 | |
---|---|---|
배포간의 시간적 차이 | 몇달 | 며칠 |
코드 작성자 vs 코드 배포자 | 오로지 한 명만이 배포하는 방법을 알고 있음 | 배포가 자동화되어 이상적으로 서버에 배포됩니다 |
개발 vs 라이브 환경 | 다름 | 최대한 비슷하게 |