Versions Compared

Key

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

...

"기획-001:멀티 로그인을 통한 플래폼 기능개선"  내용: prd에서 내용약간 추가됨

BI와 개발자는 의사소통이 잘안되기 때문에의사소통도안되고 만나면 싸우기때문에, 아케텍트에게 이게 개발가능하게 해달라 구체화해달라고 토쓰합니다.

분석

 어떻게  각 개발팀이 모여 어떻게 누가? 어떻게 개발해야할지 설계및 분석에 들어갑니다.  PM은 이때 냄새를 맡고 , 개발관련 스케쥴을 컨트롤 하려고 합니다.

"PKIV-001-다중기기 사용자를 대비한 멀티 로그인 추가"  일단 티켓을 만들고 봅니다.  (여기서 PKIV는 프로덕트기준 개발통합티켓그룹명입니다개발 티켓명입니다.)

아키텍트의 참관하에 BI가 설명을하고 어떠 개발팀이 필요한지 물어봅니다.  개발팀이 거짓말 못하게

감독역활로 아키텍트는 그냥 참관합니다. QA는 QA범위 산정을 위해 미리 참관을하지만, 기존 작동되는 방식에대해 더많은 설명을 하게됩니다.서버팀이 하게되며

BI를 가르쳐줍니다.  서버팀은 말합니다. "이거 부하 증가가 예상되어 로그인서버 2대더 필요합니다." 하지만 후회합니다. 괞히 부하이야기 꺼냈다가

로드 테스트팀을 붙여서 로드테스트 티켓 만들어버립니다.

PM은 잘 쉬고 있는 데브 옵스를 데리고 오고, 결국 데브옵스는 "ITO-001-개발서버두대추가" 티켓을  즉석으로 만들고

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

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

...

기획서가 변경됩니다.   기획-001 수정01 - 멀티로그인허용이지만 모바일은 로그인을 허용하고,PC는 냅둡

다시 분석단계를 돌아 설계단계로 와서  아키텍/서버/DB 의 논쟁이 끝나지 않습니다.

...

개발팀에서는 소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 완벽하지 않습니다쓸모없습니다. 개발자가 안알려준곳에서만 문제가 생깁니다.

최신 master로부터  featured-기능 브랜치를 각각 만들고,  개발테스트가 완료되면   release-1 브랜치로 통합하여 QA를 준비합니다.

...

DEV배포환경이라고 한대씩에만 하지 않습니다. 실전과같이  L7스위칭 환경 테스팅도 포함되기때문에 적어도 이중화가되어 쌍을 이루어 배포합니다배포하며

실제 개발서브 도메인을 사용합니다.  host를 변경하여 테스트하는 순간 변질된 테스트이기때문입니다.

host를 변경하는 테스트를 DEV테스트라고 하지 않습니다. 이것은 로컬 테스트입니다.


DEV-QA

release/XX 브랜치를 통해 QA가 시작됩니다. 여기서 여러가지 수정사항이 생깁니다.  가끔 끼어들어온 featured빼기로 featured/YX 빼기로 한다면

이미 통합되어 자동으로 뺄수 없습니다.(변경차를 빼는기능이 있는지 모르겠습니다.)

release 브랜치를 통해 제거사항을 수정하여 푸시를 통해 해결합니다. 여기서 DEVQA DEV QA SIGN OFF가 나면 

통합 테스트 환경인  INT 단계로 넘어가게 됩니다. INT로 넘어가면 더이상 수정이 일어나면 안됩니다.

개발내용에따라, 이중화된 서버중 한대를 내리거나, 인터넷 연결선을 단절하거나 극단의 테스트를 수행하기도 합니다.


Info

브랜치에 대한 약간의 제약 조건

  • feaured 는 개발티켓을 통해서만 땁니다. Git을 통해 수동으로 아니땁니다. 기본으로 master에서 가져오지만 선택가능합니다.
  • feaured/YY → Release/XX 머지는 기본으로 아키텍,팀장급 에서 소스리뷰 하고, 배포되어야 한다면 데브옵스도 추가합니다.
  • Release/XX → Master 머지에대한 리뷰는 데브옵스도 참관합니다. 이때의 상태는 둘다 운영에 반영가능하다란 의미입니다.
  • Master가 안정적으로 몇일간 운영되면, 데브옵스는 stable 브랜치를 땁니다.



INT-QA

INT환경은 소스통합 테스트를 위한 개발환경이 아닙니다. 소스통합에 따른 문제는 DEV단계 Release를 통해 이미 완료 되었어야하며

...

-만약 이때, 운영 HotFix가 발생한다면,그런일은 거의 없지만 Master가 변경되었기때문에 운영적용이 완료되면 tag 브랜치를 따기때문에 tag브랜치를 통해 한후 이후 통합합니다그것은 지금것 방치되었다란 의미이며  무리하게 Fix하지 않고 다음으로 미룹니다.하지만 이경도 stable 브랜치를 통해 fix는 가능합니다.


LOADTEST-QA

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

...

운영과 동일하기 떄문에 INT를 통해 할수가 있습니다. 역시 우리의 만능 데브옵스가 진행합니다. (일부소스 DB제외)


정리

이 긴내용을 언급된 티켓을  생성순으로 리스트업하면


PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가

...

반대로, 장애 이슈를 통해서도 이 이슈의 태초의 이슈인 프로덕 요구사항을 파악할수가 있습니다.

폭포수는 단점으로 지적이되지만, 적어도 폭포가 어떻게 떨어지는지 파악이 가능합니다.