신규기능 추가에서 배포까지 과정을 간략하게 설명하려고 합니다.이것은 어떠한 개발 프로세스를 학습하고 기술하는게 아닌, 이전 회사에서 했던 경험을 바탕으로기술하는 것이기때문에, 일반적으로 통용되는 프로세스가 아닐수 있으며제 기억이 잘못되거나 어떠한 단계가 누락될수 있습니다.신규기능 추가 신규기능은 어떻게 추가하나? 사업부에서 어떠한 아이디어를 떠올려 초안을 세웁니다.티켓이름 "PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가" 내용: 다중기기 사용자가 늘고있으니, 멀티로그인을 허용해라~~ 이하 생략,아니 없음왜 시작하는지 아무도 모릅니다. 그냥 BI가 "다중기기를 허용했을때 수익률증가?"라는 리포팅을 했을거같은 의문점이 듭니다. 그리고 프로덕트에서 BA에게 이 티켓을 좀더 분석해 구체안(기획서)을 만들라고 던집니다. 기획초안 작성 이제 BI는 발빠르게 움직입니다. 도대체 이게 무슨 내용이지? 기존 작동법부터 배우기시작합니다.유니크한 로그인이 뭔지 그떄 파악하고 , 멀티로그인이 가능함으로 할수 있는 여러가지 아이디어를 기술합니다.그리고 기획문서가 완성되기 시작하는 시점 관련 개발팀을 소집합니다."기획-001:멀티 로그인을 통한 플래폼 기능개선" 내용: prd에서 내용약간 추가됨BI와 개발자는 의사소통이 잘안되기 때문에, 아케텍트에게 이게 개발가능하게해달라 토쓰합니다.분석 어떻게 누가? 어떻게 개발해야할지 설계및 분석에 들어갑니다. PM은 이때 냄새를 밭고 , 개발관련 스케쥴을 컨트롤 하려고 합니다."PKIV-001-다중기기 사용자를 대비한 멀티 로그인 추가" 일단 티켓을 만들고 봅니다. (여기서 PKIV는 프로덕트기준 개발통합티켓그룹명입니다.)아키텍트의 참관하에 BI가 설명을하고 어떠 개발팀이 필요한지 물어봅니다. 개발팀이 거짓말 못하게감독역활로 아키텍트는 그냥 참관합니다. QA는 QA범위 산정을 위해 미리 참관을하지만, 기존 작동되는 방식에대해 더많은 설명을 하게됩니다.서버팀이 말합니다. "이거 부하 증가가 예상되어 로그인서버 2대더 필요합니다."PM은 잘 쉬고 있는 데브 옵스를 데리고 오고, 결국 데브옵스는 "ITO-001-개발서버두대추가" 티켓을 즉석으로 만들고 PKIV- 개발티켓에 연결시킵니다.그리고 자기일 하러 갑니다. DB / 서버 / 클라이언트 결국 3팀에서 개발을 하기로 결정하고 기획문서를 재해석하기 시작합니다. 설계 아키텍트는 이떄부터 개발팀과함께 다이어그램을그리기 시작합니다. 이 연산은 그쪽팀에서해도 되는데 그쪽에서 하는게 좋지 않겠느냐?분쟁이 시작되며, 아키텍트는 중재를 합니다. 반반씩 해라~~~ DB반 서버반.... 이 단계가 길어집니다. PM이 개입합니다.아무나 빨리해라~~ 어느정도 아키텍쳐가 그려지는듯 하더니 이러는 동안 PRD에 수정이 일어나고, 기획서가 변경됩니다. 기획-001 수정01 - 모바일은 로그인을 허용하고,PC는 냅둡다시 분석단계로 돌아가, 설계 단계를 겨우 마치게됩니다.개발PKIV-001 스토리에대한 서브 티켓으로 PKIV02-DB 다중로그인 추가 , PKIV03-서버 다중로그인추가 , PKIV04-클라이언트 다중로그인추가PKQA-001 다중로그인 QA 각팀에서 담당해야할 메인 티켓들이 만들어집니다. 하부에 어떠한 개발 티켓이 추가되고 그룹핑이 될지는각팀에서 알아서 합니다. 개발팀에서는 소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 완벽하지 않습니다.최신 master로부터 featured-기능 브랜치를 각각 만들고, 개발테스트가 완료되면 release-1 브랜치로 통합하여 QA를 준비합니다.이때 데브옵스는 릴리즈 브랜치를 확인하고 DEV 배포 환경을 준비합니다. (완전 자동화는 아님)DEV배포환경이라고 한대씩에만 하지 않습니다. 실전과같이 L7스위칭 환경 테스팅도 포함되기때문에 적어도 쌍을 이루어 배포합니다.DEV-QArelease 브랜치를 통해 QA가 시작됩니다. 여기서 여러가지 수정사항이 생깁니다. 가끔 끼어들어온 featured빼기로 한다면이미 통합되어 자동으로 뺄수 없습니다.(변경차를 빼는기능이 있는지 모르겠습니다.)release 브랜치를 통해 제거사항을 수정하여 푸시를 통해 해결합니다. 여기서 DEVQA SIGN OFF가 나면 통합 테스트 환경인 INT 단계로 넘어가게 됩니다. INT로 넘어가면 더이상 수정이 일어나면 안됩니다.개발내용에따라, 이중화된 서버중 한대를 내리거나, 인터넷 연결선을 단절하거나 극단의 테스트를 수행하기도 합니다.INT-QA
신규기능 추가에서 배포까지
신규기능 추가에서 배포까지 과정을 간략하게 설명하려고 합니다.
이것은 어떠한 개발 프로세스를 학습하고 기술하는게 아닌, 이전 회사에서 했던 경험을 바탕으로
기술하는 것이기때문에, 일반적으로 통용되는 프로세스가 아닐수 있으며
제 기억이 잘못되거나 어떠한 단계가 누락될수 있습니다.
신규기능 추가
신규기능은 어떻게 추가하나? 사업부에서 어떠한 아이디어를 떠올려 초안을 세웁니다.
티켓이름 "PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가"
내용: 다중기기 사용자가 늘고있으니, 멀티로그인을 허용해라~~ 이하 생략,아니 없음
왜 시작하는지 아무도 모릅니다. 그냥 BI가 "다중기기를 허용했을때 수익률증가?"
라는 리포팅을 했을거같은 의문점이 듭니다.
그리고 프로덕트에서 BA에게 이 티켓을 좀더 분석해 구체안(기획서)을 만들라고 던집니다.
기획초안 작성
이제 BI는 발빠르게 움직입니다. 도대체 이게 무슨 내용이지? 기존 작동법부터 배우기시작합니다.
유니크한 로그인이 뭔지 그떄 파악하고 , 멀티로그인이 가능함으로 할수 있는 여러가지 아이디어를 기술합니다.
그리고 기획문서가 완성되기 시작하는 시점 관련 개발팀을 소집합니다.
"기획-001:멀티 로그인을 통한 플래폼 기능개선" 내용: prd에서 내용약간 추가됨
BI와 개발자는 의사소통이 잘안되기 때문에, 아케텍트에게 이게 개발가능하게
해달라 토쓰합니다.
분석
어떻게 누가? 어떻게 개발해야할지 설계및 분석에 들어갑니다. PM은 이때 냄새를 밭고 , 개발관련 스케쥴을 컨트롤 하려고 합니다.
"PKIV-001-다중기기 사용자를 대비한 멀티 로그인 추가" 일단 티켓을 만들고 봅니다. (여기서 PKIV는 프로덕트기준 개발통합티켓그룹명입니다.)
아키텍트의 참관하에 BI가 설명을하고 어떠 개발팀이 필요한지 물어봅니다. 개발팀이 거짓말 못하게
감독역활로 아키텍트는 그냥 참관합니다. QA는 QA범위 산정을 위해 미리 참관을하지만, 기존 작동되는 방식에대해 더많은 설명을 하게됩니다.
서버팀이 말합니다. "이거 부하 증가가 예상되어 로그인서버 2대더 필요합니다."
PM은 잘 쉬고 있는 데브 옵스를 데리고 오고, 결국 데브옵스는 "ITO-001-개발서버두대추가" 티켓을 즉석으로 만들고 PKIV- 개발티켓에 연결시킵니다.
그리고 자기일 하러 갑니다.
DB / 서버 / 클라이언트 결국 3팀에서 개발을 하기로 결정하고 기획문서를 재해석하기 시작합니다.
설계
아키텍트는 이떄부터 개발팀과함께 다이어그램을그리기 시작합니다. 이 연산은 그쪽팀에서해도 되는데 그쪽에서 하는게 좋지 않겠느냐?
분쟁이 시작되며, 아키텍트는 중재를 합니다. 반반씩 해라~~~ DB반 서버반.... 이 단계가 길어집니다. PM이 개입합니다.
아무나 빨리해라~~ 어느정도 아키텍쳐가 그려지는듯 하더니
이러는 동안 PRD에 수정이 일어나고, 기획서가 변경됩니다. 기획-001 수정01 - 모바일은 로그인을 허용하고,PC는 냅둡
다시 분석단계로 돌아가, 설계 단계를 겨우 마치게됩니다.
개발
PKIV-001 스토리에대한 서브 티켓으로 PKIV02-DB 다중로그인 추가 , PKIV03-서버 다중로그인추가 , PKIV04-클라이언트 다중로그인추가
PKQA-001 다중로그인 QA 각팀에서 담당해야할 메인 티켓들이 만들어집니다. 하부에 어떠한 개발 티켓이 추가되고 그룹핑이 될지는
각팀에서 알아서 합니다.
개발팀에서는 소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 완벽하지 않습니다.
최신 master로부터 featured-기능 브랜치를 각각 만들고, 개발테스트가 완료되면 release-1 브랜치로 통합하여 QA를 준비합니다.
이때 데브옵스는 릴리즈 브랜치를 확인하고 DEV 배포 환경을 준비합니다. (완전 자동화는 아님)
DEV배포환경이라고 한대씩에만 하지 않습니다. 실전과같이 L7스위칭 환경 테스팅도 포함되기때문에 적어도 쌍을 이루어 배포합니다.
DEV-QA
release 브랜치를 통해 QA가 시작됩니다. 여기서 여러가지 수정사항이 생깁니다. 가끔 끼어들어온 featured빼기로 한다면
이미 통합되어 자동으로 뺄수 없습니다.(변경차를 빼는기능이 있는지 모르겠습니다.)
release 브랜치를 통해 제거사항을 수정하여 푸시를 통해 해결합니다. 여기서 DEVQA SIGN OFF가 나면
통합 테스트 환경인 INT 단계로 넘어가게 됩니다. INT로 넘어가면 더이상 수정이 일어나면 안됩니다.
개발내용에따라, 이중화된 서버중 한대를 내리거나, 인터넷 연결선을 단절하거나 극단의 테스트를 수행하기도 합니다.
INT-QA