12 factor app 시작하기

• 1. codebase
  • Introduction of git flow
  • Start programming with a feature branch
  • release version
  • hotfix
• 2. Dependencies
• 3. Configuration
• 4. Backing services

1. codebase

모든 어플리케이션 코드는 version control system 을 통해 하나로 관리되어야 한다.

가령 여러개의 루트 repository 가 있다면 이것은 앱이 아니라 하나의 분산 시스템에 가까울 것이다.

하나의 코드베이스에서 여러개의 배포를 진행할 수 있고, 각 배포버전별로 코드 버전이 관리된다면 훌륭할 것이다.

Introduction of git flow

일반적인 프로젝트에서 이러한 버전관리는 훌륭한 버전관리 툴인 git 을 사용해서 진행하며 git flow 는 훌륭한 워크플로우를 제공한다.

install git flow on Mac

brew install git-flow

start git flow project

git flow init

다음은 git flow 에서 브랜치의 종류와 그 역할에 대해 알려준다.

master branch 는 실제 공식 배포버전을 관리하며 일반적으로 production deploy 버전을 관리한다.

feature branch 는 실제 각 개발자들이 작업을 하는 브랜치이며, 이는 develop 브랜치에서 갈라져 나오고 추후 다시 develop 브랜치로 병합된다.

develop 브랜치는 각 개발자들이 작업한 브랜치들이 머지되는 장소이며 모든 커밋의 내용이 기록된다.

release branch 는 develop 브랜치로 부터 당겨져오며 여기에서는 오직 버그 수정이나 혹은 documentation 수정 등 release 와 관련된 작업들만 수행된다. 이를 통해 특정 팀에서 해당 release 버전으로 테스트 혹은 출시준비과정을 진행하는 동안 다른 브랜치에서 작업을 수행하며, 다음 release 전까지 해결될 사항들을 정리할 수 있다. 해당 브랜치는 develop 으로부터 갈라져 나온다. 만약 코드리뷰를 한다면 해당 브랜치에서 하는 것이 가장 깔끔해 보인다.

hotfix branch hotfix 브랜치는 바로 master branch 에서 갈라져 나와 빠른 버그 수정 등을 수행하는 branch 이며, 버그가 수정되면 재빨리 다시 master 브랜치로 머지되어야 한다. 이 브랜치는 master 브랜치로부터 갈라져 나오는 유일한 브랜치이다.

Start programming with a feature branch

아래 명령어로 새로운 develop 브랜치로 부터 feature 브랜치를 만들어서 갈라져 나온다.

# 로컬에 새 브랜치 생성
git flow feature start branch_name

# 리모트 브랜치에 배포
git flow feature publish branch_name

# 새로운 내용을 커밋
git add .
git commit -m "content"
git push

# 머지를 요청하기 전에 반드시 리베이스를 받는다
git pull -r origin develop

# feature 브랜치 머지
git feature finish branch_name

release version

새로운 버전을 출시하기 위한 git flow 코드는 다음과 같다.

# from develop branch
git flow release start 0.0.1

# from release branch
git flow release finish 0.0.1

hotfix

공식 배포 버전에서 빠른 버그 수정을 위한 hotfix 브랜치에서 작업을 하는 과정은 다음과 같다.

git flow hotfix start hotfix_branch
git flow hotfix finish hotfix_branch

2. Dependencies

어플리케이션을 작성함에 있어 다양한 외부 라이브러리들에 의존하게 된다.

특히 각 언어별로 존재하는 패키지 매니저를 사용한다면 글로벌하게 설치되는 패키지도 있고 내부적으로 설치되는 패키지도 있는데 이처럼 글로벌하게 설치되는 패키지의 경우 시스템 환경에 어플리케이션이 의존하게 되는 문제가 있다.

12 factor app 에서는 이러한 시스템 환경에 전혀 의존하지 않는 프로그램을 작성함을 원칙으로 한다.

가령 node.js 환경에서 어플리케이션을 개발하는 경우 npm 패키지를 설치함에 있어 package.json 이라는 패키지 관리 documentation 을 하게 된다. 이처럼 의존하는 dependency 를 명확하게 명시하여서 다른 시스템 환경에서도 바로 빌드가 되어 오류없이 프로그램이 실행하도록 한다.

3. Configuration

대부분의 경우 어플리케이션은 배포할때마다 다른 configuration 이 필요하게 된다.

가령 develop server 의 경우 develop database 에 연결되어야 하고, production server의 경우 production database에 연결되어야 하는 것처럼 어플리케이션의 소스코드와는 달리 이러한 설정 값들은 배포마다 달라지게 된다.

때문에, 12 factor app 에서는 이러한 설정값을 코드베이스에 포함시키는 것을 엄격하게 금지하고 있으며, 이러한 모든 설정들을 environment variable 에 저장하는 것을 추천한다.

이러한 env variable 들은 여러 deployment setting 에 대해 혼합된 정보를 절대 가지지 않으며 각 배포환경마다 독립되게 존재하여야 한다.

4. Backing services

가령 이메일 서버나 혹은 데이터 베이스와 같이 어플리케이션이 동작하는데 필요한 부수적인 다른 서비스들을 backing service 라고 부른다.

이러한 backing service 들은 언제나 장애가 생길 수 있으므로 12 factor app 에서는 그 어떤 코드의 변경 없이 백업으로 준비된 backing service 에 붙을 부 있어야 한다.

참조 - 12 factor app