형이 바빠서 다이나믹 대 스태틱을 못 싸주고 잇다.

지금 일터 개발 프로세스가 이제까진 중구난방 카오스 라도  문제 안되는 수준이었는데, 조금씩.틀을 갖추면서 때가 되어서 형이 과감히 메쓰를 들었다.

오늘은 그런 형의 노하우를 공개해주니, 니들은 잘 숙지했다가 필요할 때 잘 써먹도록.


보통 서비스를 개발하면 세네개 정도 유사 환경을 끌고 나가야 된다.

1. 로컬 개발 환경
2. 네트워크에 설치된 개발/테스트 환경
3. 프로덕션 가기 전 스테이징 환경
4. 프로덕션

니가 위 각각의 환경을 개발 단계 및 버전 컨트롤에 잘 맵핑하면 그게 소프트웨어 개발 프로세스가 됨.

형은 단순한걸 조아라 해서 위 환경에서 크게 두 단계로 구분

1. 개발 단계
2. 릴리즈 단계

개발 단계는 로컬 및 네트워크 개발 환경에서 일하는 것이고 릴리즈 단계는 스테이징 및 프로덕션에서 버그를 해결해주는 단계.

이러면 버전 컨트롤 전략은 비교적 명확해 진다. 눈에 명확히 보이게 하기 위하여 브랜치로 구분하면
1. develop
2. staging
3. production

세개의 브랜치가 항상 존재한다.

develop 브랜치에선 항상 일회용 feature 브랜치를 만들어 특정 기능을 구현하고 다시 develop 브랜치로 머지 함

이렇게 일주일간 개발을 하고 나면 개발을 잠시 멈추고 그때까지의 develop 브랜치를 staging 브랜치로 머지하고 그걸 스테이징 환경에 설치해서 일주일간 집중 테스트. 릴리즈 단계의 시작.
만일 문제가 발생하면 일회용 bug 브랜치를 만들어 거기서 고치고 완성후 staging 브랜치에 머지.

일주간의 숙성이 끝나면 staging을 production과 develop 브랜치로 머지. 프로덕션  태그를 붙이고 그걸 정식 릴리즈.

그다음 다시 개발 단계로 돌아옴. 이때부터 production 브랜치에 bug 브랜치가 생겻다 머지하며 추가적 일이 발생할 수 있음. production에서의 머지는 어느 단계에 있냐에 따라 develop 혹은 staging 브랜치로 바로 머지


형의 오래된 경험을 단순화한 가장 최신판 버전 컨트롤 전략이다.