Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

PKIV- 개발티켓에 연결시킵니다. 그리고 자기일 하러 갑니다.  

DB / 서버 / 클라이언트/모바일팀  결국 3팀에서 4팀에서 개발을 하기로 결정하고 기획문서를 재해석하기 시작합니다. 

...

-만약 이때, 운영 Fix가 발생한다면,그것은 지금것 방치되었다란 의미이며  무리하게 Fix하지 않고 다음으로 미룹니다.하지만 이경우도 stable 브랜치를 통해 fix는 가능합니다.


Info

브랜치에 대한 약간의 제약 조건과 유연성

  • feaured 는 개발티켓을 통해서만 땁니다. Git을 통해 수동으로 아니땁니다. 기본으로 master에서 가져오지만 선택가능합니다.
  • feaured/XX 가 Release에 누락되었다면, 다음 Release에 머지하여 DEV-QA과정을 거칩니다.
  • feaured/YY → Release/XX 머지는 기본으로 아키텍,팀장급 에서 소스리뷰 하고, 배포되어야 한다면 데브옵스도 추가합니다.
  • Master가 안정적으로 몇일간 운영되면, 데브옵스는 stable 브랜치를 땁니다. 상태에대한 마크업용입니다.
  • INT/Release/XX 단계는 프리징단계이지만 약간의 변경을 허용함
  • Release/XX → Master 머지된 단계는 소스변경을 허용하지 않음
  • 빌드단계와 디플로이는 분리되어야합니다. 이것은 롤백을 위해 꼭 빌드가 필요한것이 아님을 뜻합니다.
  • 운영이전 개발단계 디플로이에있어서 고정은 없습니다. 디플로이 전략에의해 소스타겟은 변경될수 있기때문에, 다른 브랜치로의 디플로이도 가능해야합니다.



LOADTEST-QA

INT-QA가 진행되는 동안 로드테스트가 필요한 프로젝트이면 INT에 배포된 릴리즈를 통해 LOADTEST가 진행됩니다.

...