Page History
신규기능 추가에서 배포까지 과정을 간략하게 설명하려고 스토리화 합니다.
이것은 어떠한 개발 프로세스를 학습하고 기술하는게 아닌, 이전 회사에서 했던 경험을 바탕으로기술하는 것이기때문에, 경험을
기억을 바탕으로 사실을 베이스로 서술을 하려고 했습니다.
일반적으로 통용되는 프로세스가 아닐수 있으며아니며 제 기억이 잘못되거나 어떠한 단계가 누락될수 있습니다누락되거나 잘못 설명될수있습니다.
신규기능 추가
신규기능은 어떻게 추가하나? 사업부에서 어떠한 아이디어를 떠올려 초안을 세웁니다.
...
BI를 가르쳐줍니다. 서버팀은 말합니다. "이거 부하 증가가 예상되어 로그인서버 2대더 필요합니다." 하지만 후회합니다. 괞히 부하이야기 꺼냈다가
아키텍트가 로드 테스트팀을 붙여서 로드테스트 티켓 티켓도 만들어버립니다.
PM은 잘 쉬고 있는 데브 옵스를 데리고 오고, 결국 데브옵스는 "ITO-001-개발서버두대추가" 티켓을 즉석으로 만들고
PKIV- 개발티켓에 연결시킵니다. 그리고 자기일 하러 갑니다.
DB / 서버 / 클라이언트/모바일팀 결국 3팀에서 개발을 하기로 결정하고 기획문서를 재해석하기 시작합니다.
...
아키텍트는 이떄부터 개발팀과함께 다이어그램을그리기 시작하며
개발팀의 분쟁이 시작됩니다. 이 연산은 DB가 해라? 서버가해라? 클라이언트에서해라?
아키텍트는 아름다운 중재를 합니다. 반반씩 해라~~~ DB반 서버반.... 이 단계가 길어집니다. PM이 개입합니다.
...
기획서가 변경됩니다. 기획-001 수정01 - 멀티로그인허용이지만 멀티로그인 허용이지만 모바일은 로그인을 허용하고 허용하고,PC는 냅둡비허용
다시 분석단계를 돌아 설계단계로 와서 아키텍/서버/DB 의 논쟁이 끝나지 않습니다.
이때 이런문제는 3명다 수용을 시켜야 해결이되며, 이때 영웅이 등장하여 그문제를 그 문제를 해결을 합니다. 이러한
이러한 티켓번호는 분쟁이 심하면 내용으로 기억되지 않습니다.
...
개발팀에서는 소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 쓸모없습니다. 개발자가 안알려준곳에서만 안 알려준곳에서만 문제가 생깁니다.
최신 master로부터 featured-기능 브랜치를 각각 만들고, 개발테스트가 완료되면 release-1 브랜치로 통합하여 QA를 준비합니다.
...
통합 테스트 환경인 INT 단계로 넘어가게 됩니다. INT로 넘어가면 더이상 수정이 일어나면 안됩니다. Release/XX의 코드프리징이됩니다.
개발내용에따라, 이중화된 서버중 한대를 내리거나, 인터넷 연결선을 단절하거나 극단의 테스트를 수행하기도 합니다.
...
브랜치에 대한 약간의 제약 조건
...
.
...
INT-QA
INT환경은 소스통합 테스트를 위한 개발환경이 아닙니다. 소스통합에 따른 문제는 DEV단계 Release를 통해 이미 완료 되었어야하며
...
설정 조작들이 영향을 끼치는것을 방지하는 목적으로, DEV단계에서만 추가한 설정사항이 없어서 발생하는 누락사항등도 찾아야 합니다.
즉 INT는 개발에 추가기능에 관련되지 않는 그 어떠한 설정 변경도 일어나면 안됩니다.
...
여기서 끝이아니고...
데브옵스는 INT의 모든 배포 변경사항을 현재 운영 서비스와 동일하게 롤백하고
QA를 Master를 통해 실서비스 반영과 똑같은 스텝으로 서비스 실 반영 가상 테스트 시나리오 에 돌입하게 됩니다.
데브옵스는 그동안 INT가 Release대상으로 디플로이 된것을 , Master로 변경합니다.
이상적으로 운영 순서에따른,혹은 설정사항 순서 적용에따른 문제를 미리 찾을수 있습니다.
또한 동시에 Master를 통한 운영 디플로이를 준비합니다. (운영 빌드는 미리해둡니다.)
-만약 이때, 운영 HotFix가 Fix가 발생한다면,그것은 지금것 방치되었다란 의미이며 무리하게 Fix하지 않고 다음으로 미룹니다.하지만 이경도 stable 이경우도 stable 브랜치를 통해 fix는 가능합니다.
| Info |
|---|
브랜치에 대한 약간의 제약 조건
|
LOADTEST-QA
INT-QA가 진행되는 동안 로드테스트가 필요한 프로젝트이면 INT에 배포된 릴리즈를 통해 LOADTEST가 진행됩니다.
...