Page History
| Warning |
|---|
신규기능 추가에서 배포까지 과정을 스토리화 합니다. 이것은 어떠한 개발 프로세스를 학습하고 기술하는게 아닌, 이전에 했던 경험을 바탕으로 개발자 기준으로 2년전 개발자 경험을 바탕으로 개발 프로세스에관련한 내용을 픽션화 하였습니다. 여기에 기술된 내용은 이상적인 개발 프로세스와는 상관없음을 밝힙니다. |
...
모든 문제의 파악은, 직관적인 티켓을 통해서만 하기로 하였으니까요....,
신규기능 추가
신규기능은 어떻게 추가하나? 사업부에서 어떠한 아이디어를 떠올려 초안을 세웁니다.
...
그리고 사업부에서 BA(비지니스분석,기획)에게 이 티켓을 좀더 분석해 구체안(기획서)을 만들라고 할당합니다.
기획초안 작성
이제 BA는 발빠르게 움직입니다. 도대체 이게 무슨 내용이지? 기존 작동법부터 배우기시작합니다.
...
BA와 개발자는 의사소통이 어렵기 때문에, 아케텍트에게 개발가능하게 구체화 해달라고 할당 합니다.
분석
각 개발팀이 모여 어떻게 누가? 어떻게 개발해야할지 분석에 들어갑니다.
...
이때 대부분의 사업요구서와 기획티켓이 연관이되기때문에 여기에 직간접 참여한 모든 개발자및 QA 데브옵스 디자이너등등
자신이 무엇때문에 일을 하고 있는지 그 이유에대해서 이유와 사명감에 대해서 알게됩니다.
아키텍트의 참관하에 BA가 설명을하고 어떤 개발팀이 필요한지 물어봅니다.
개발팀의 거짓말을 방지하기위해 감독역활로 아키텍트는 그냥 참관합니다. 가끔 이건 안되요 하면 아키텍트가 열심히 리서치해서
해법을 찾아주기도 합니다. 아주 자끔입니다가끔입니다.
QA는 QA범위 산정을 위해 미리 참관을하지만, 새롭게 작동되는 방식에대해 의문을 제기하기도 합니다. 기존작동은 아시냐구요?
...
알고싶지는 않지만, 서버두대 추가로 해야되는 고급 일들이 많아 보입니다. 그리고 데브옵스는 임무를 마치고 자기일 하러 갑니다. 아직 프로젝트이프로젝트가
완료되려면 완료 되려면 한참 남았으니까요
| Info |
|---|
QA가 끝나는시점 데브옵스에게 공유합니다. 런칭되어야하니 장비 준비해주세요.....다음주 런칭할겁니다. 사실 이렇게 진행하다가, 런칭일을 준수못해 프로적 메니져에게 꾸중을 많이들은 PM은, 프로젝트 초기단계에 데브옵스도 참관시키거나 공유합니다. |
...
두리뭉실하게 재해석을 하고 파이팅을 외치며 회의는 끝나게 됩니다. 금요일은 빨리 퇴근 해야하기떄문에 이야기가 길어지면
안되기때문입니다.
설계
아키텍트는 이떄부터 개발팀과함께 다이어그램을그리기 시작하며
...
뭣이 중한디? 아무나 빨리하고 일정을 맞추시오. DB에서 영업을뛰어 이 비지니스로직이 DB로 가면 가게되면 공수가생겨 업데이트가 연기가 됩니다
PM이 BA및 아키텍트의 조건부 승인을 받아냅니다. 런칭 날짜가 더 중요하니 이 로직은 그냥 서버에 있게하고 서버가 하게하고 다음에 개선하자
어느정도 아키텍쳐가 그려지는듯 하더니 이러는 동안 PRD(프로덕요구사항)에 수정이 일어나고,
...
QA는 조용하게 이때까지 준비한 테스트 케이스를 모두 폐기하고, 최종 결론본에 맞춰 처음부터 다시작성합니다.
개발
개발 이전에 수많은 분석및 설계 티켓이 먼저 생성되었습니다. 그렇습니다. 그것은 티켓번호 7782입니다.
...
완벽하게 작동됩니다. 라고 이야기하는것입니다.
DEV-QA
개발이 완료되고, release 브랜치를 통해 QA가 시작됩니다. 여기서 여러가지 수정사항이 생깁니다.
...
DEV-릴리즈 프리징이되었으며 이것은 서비스에바로올려도 문제가 없을것이다란 희망입니다. 그리고 통합환경인 INT로 넘어갑니다.
INT-QA
INT환경은 소스통합 테스트를 위한 개발환경이 아닙니다. 소스통합에 따른 문제는 DEV단계 Release 프리징을 통해 이미 완료 되었으며
...
이경우 stable 브랜치를 통해 fix는 가능하나, 굳이 그러지 않습니다.
| Expand | ||
|---|---|---|
| ||
LOADTEST-QAINT-QA가 진행되는 동안 로드테스트가 필요한 프로젝트이면 INT에 배포된 릴리즈를 통해 LOADTEST가 진행됩니다. 개발자에게 불행이지만 LOADTEST장비는 실제 운영 장비수와 같습니다. 가장 최악 시나리오는 LOADTEST에서 실패나서 SIGN-OFF난 INT환경을 수정해야되는 케이스입니다. 다시 INT테스트를 수행하야하며, 다시 LOADTEST도 해야합니다. 이 모든것을 통과하고도 진정한 부하문제는 부하 시나리오에 고려하지 못한것이 운영중에 나오게 됩니다. 그렇다고 최악은 아닙니다. 통과한 9개는 관련이 없으니까요~ 9개를 제외하고 나머지 1~2내외로 용의자가 좁혀질수 있습니다. |
운영
INT-QA/LOAD TEST 가 완료되었다고 운영에 반영할수 있는것은 아닙니다.
...
운영 수동배포는 다음에 빅이슈 되어 처리해야할 개발과제가 됩니다. 대부분 고질적 문제로 자동배포는 빠르게 해결이안됩니다.
빌드관리자의 승인거부는 승인은 릴리즈 날짜를 방해하는 요소가 배포서비스를 안정화하겠다란 의지이며요소가아니며, 배포서비스를 안정화하겠다란 의지입니다.
결국 추후 자동배포처리가 모두 되었습니다. . 이 이후부터 빌드관리자의 승인거부는 절대적인게 됩니다.
-길거리에서 긴급처리한 실제 카톡내용입니다. 다행히 노트북과 버려진 테이블이 있었습니다.
이것은 운영장애 발생이 아닌, 하루전 갑자기 자동빌드가 깨져서 빌드를 정상화하는것입니다.
물론 수동으로 Deploy로 처리할수 있는 부분이지만, 자동배포이후 그것은 허용되질 않았습니다. 등장인물은 PM,데브옵스,개발자,QA ( INT에서 검증후 내보냄)
이제 험난한 과정을 거치고 드디어 런칭하였습니다. 이제부터느 운영이기때문에 집중 테스트가 진행됩니다.
...
디플로이 스냅샷을 통해 롤백이 가능합니다. ( 여기서 디플로이 스냅샷은 자동으로 생성되는것 or 수동으로라도 운영빌드된 패키지가 백업이 됨을 의미)
이러한 문제는 아무문제없어하고 보통 모든 운영 반영 테스트를 마치고 새벽에 잠이들때 발생합니다.
이때 이미 일반적으로 회사는 퇴근후 개인 사생활을 보장했기때문에 개인 휴대폰을 통해 연락할수 없으며
...
어쨋건 이 모든 과정이 끝나면 PKIV-001 멀티로그인 대장정대서사시(EPIC) 티켓이 끝나게 막을 됩니다.
정리
이 긴내용에 언급된 티켓을 생성순으로 리스트업하면
...