신규기능 추가에서 배포까지 과정을 스토리화 합니다. 이것은 어떠한 개발 프로세스를 학습하고 기술하는게 아닌,이전에 했던 경험을 바탕으로 개발자 기준으로 픽션화 하였습니다. 현재의 상황을 풍자한것을 아님을 밝힙니다. 하루에도 여러차례 서비스코드를 개선하기위해 커밋을하고, 그 커밋은 어떠한 결정에 의해 이루어졌으며또한 서버재부팅도 어떠한 원인 파악을 통해 이루어졌지만 지식및 운영에 관련하여 그어떠한 노하우도 쌓이지않고높아지지 않았습니다. 1년전과 똑같은 오늘을 보내고 있다라고 생각한 상위 관리팀에서 이러한 지침이 내려왔습니다.그냥 놀아라, 너가 노는것을 보장해주겠다.하지만 활동을 하고 싶은면 너가 하는일이무엇인지? 사소한 일도 티켓을 만들어라~티켓:특정한 것을 할 수 있는 자격. (네이버사전)그렇게 이야기는 시작이 됩니다.신규기능 추가 신규기능은 어떻게 추가하나? 사업부에서 어떠한 아이디어를 떠올려 초안을 세웁니다.티켓이름 "PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가" 내용: 다중기기 사용자가 늘고있으니, 멀티로그인을 허용해라~~ 이하 생략,아니 없음하지만 어딘가 이러한 티켓이 발견이 됩니다. "BI-001 다중기기를 허용했을때 수익증가율 분석"그리고 사업부 에서 BA에게 이 티켓을 좀더 분석해 구체안(기획서)을 만들라고 던집니다.비지니스 분석가가 기획서를 만들어야하는것인가?에 대해서는 개발자는 알수없습니다.기획자라고 부르지 않았으니까요~~ 기획초안 작성 이제 BA는 발빠르게 움직입니다. 도대체 이게 무슨 내용이지? 기존 작동법부터 배우기시작합니다.유니크한 로그인이 뭔지 그떄 파악하고 , 멀티로그인이 가능함으로 할수 있는 여러가지 아이디어를 넣기시작합니다.충돌이나는 기존 기능에대해 고려하지 못할수도 있습니다.그리고 기획문서 초안이 완성되는 시점 관련 개발팀을 소집합니다."기획-001:멀티 로그인을 통한 플래폼 기능개선" 내용: prd에서 내용약간 추가됨BA와 개발자는 의사소통이 어렵기 때문에, 아케텍트에게 개발가능하게 구체화 해달라고 토쓰합니다.분석 각 개발팀이 모여 어떻게 누가? 어떻게 개발해야할지 분석에 들어갑니다. PM은 이때 냄새를 맡고 , 개발관련 스케쥴을 컨트롤 하려고 합니다."PKIV-001-다중기기 사용자를 대비한 멀티 로그인 대장정(EPIC)" 일단 티켓을 만들고 봅니다. (여기서 PKIV는 프로덕트기준 그들만이 사용하는 개발관련 티켓명이며 자동으로 붙습니다.)아키텍트의 참관하에 BA가 설명을하고 어떤 개발팀이 필요한지 물어봅니다. 개발팀의 거짓말을 방지하기위해감독역활로 아키텍트는 그냥 참관합니다. QA는 QA범위 산정을 위해 미리 참관을하지만, 기존 작동되는 방식에대해 더많은 설명을 하게되며BI를 가르쳐줍니다. 이것은 문제가 될것 같은데요 라구~~ 서버팀더 한마디 합니다. "이거 부하 증가가 예상되어 로그인서버 2대더 필요합니다." 하지만 뒤늦게 후회합니다.괞히 부하이야기 꺼냈다가 아키텍트가 로드 테스트팀을 붙여서 로드테스트 티켓도 만들어버립니다.PM은 잘 쉬고 있는 데브 옵스를 데리고 오고, 데브옵스는 "ITO-001-개발서버두대추가" 티켓을 즉석으로 만들고PKIV- 개발대장정(EPIC) 티켓에 연결시킵니다. 물론 이 서브티켓에는 BIGIP등록및 SSL인증서 라우터룰셋팅등 잡다한 티켓이 생성됩니다.알고싶지는 않지만, 서버두대 추가로 해야되는 고급 일들이 많아 보입니다. 그리고 데브옵스는 임무를 마치고 자기일 하러 갑니다. 결국 DB / 서버 / 클라이언트/모바일팀 4팀에서 개발을 하기로 결정하고 숨겨지고 함축된 의미에 대해기획문서를 두리뭉실하게 재해석을 하고 파이팅을 외치며 회의는 끝나게 됩니다.설계 아키텍트는 이떄부터 개발팀과함께 다이어그램을그리기 시작하며어떠한 기능에대해 비지니스 로직이 어디에 있어야 하는가에 대해 분쟁이 시작됩니다.DB냐? 서버냐? 게으른 서버개발자는 이것을 클라이언트에게 넘기기도 합니다.아키텍트는 아름다운 중재를 합니다. 반반씩 해라~~~ DB반 서버반.... 이 단계가 길어집니다. PM이 개입합니다.뭣이 중한디? 아무나 빨리하고 일정을 맞추시오. 어느정도 아키텍쳐가 그려지는듯 하더니 이러는 동안 PRD(프로덕요구사항)에 수정이 일어나고,기획서가 변경됩니다. 기획-001 티켓을 은근슬쩍 수정하여 공지합니다멀티 로그인 허용이지만 모바일은 허용하고,PC는 비허용다시 분석단계를 돌아 설계단계로 와서 아키텍/서버/DB 의 논쟁이 끝나지 않습니다.이런문제는 충돌자 3명다 수용을 시켜야 해결이되며, 이때 영웅이 등장하여 그 문제를 해결을 합니다. 이러한 티켓번호는 분쟁이 심하면 내용으로 기억되지 않습니다.숫자로 기억됩니다. 7782번 티켓이라고 ..... 개발시간을 다 까먹었지만 릴리즈 날자는 변경없이 다음 단계로 돌입하게 됩니다.개발PKIV-001 대장정(EPIC) 에대한 서브 티켓으로 스토리가 생성됩니다.PKIV02-DB팀의 다중 로그인 추가에 대한 이야기(STORY)PKIV03-서버팀의 다중 로그인 추가에 대한 이야기(STORY) PKIV04-클라이트팀의 다중 로그인 추가에 대한 이야기(STORY)PKIV05-다중로그인 테스트에대한 아름다운 QA의 이야기(STORY)각팀에서 해야할 스토리들이 만들어집니다. 하부에 어떠한 개발 STORY가 추가가되고그 이야기에 대한 하부를 어떻게 그룹핑하고 풀어야 할지는 각 개발팀이 만들어야 하며 이때부터진행사항을 PM이 개입하기 시작합니다. 개발팀에서는 소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 쓸모없습니다. 개발자가 안 알려준곳에서만 문제가 생깁니다.최신 master로부터 featured-기능 브랜치를 각각 만들고, 개발테스트가 완료되면 release-1 브랜치로 통합하여 QA를 준비합니다.이때 데브옵스는 릴리즈 브랜치를 확인하고 DEV 배포 환경을 준비합니다. (완전 자동화는 아님)DEV배포환경이라고 한대씩에만 하지 않습니다. 실전과같이 L7스위칭 환경 테스팅도 포함되기때문에 적어도 이중화가되어 쌍을 이루어 배포하며실제 개발서브 도메인을 사용합니다. host를 변경하여 테스트하는 순간 변질된 테스트이기때문입니다.host를 변경하는 테스트를 DEV테스트라고 하지 않습니다. 이것은 로컬 테스트입니다.DEV-QArelease/XX 브랜치를 통해 QA가 시작됩니다. 여기서 여러가지 수정사항이 생깁니다. 가끔 끼어들어온 featured/YX 빼기로 한다면이미 통합되어 자동으로 뺄수 없습니다.(변경차를 빼는기능이 있는지 모르겠습니다.)release 브랜치를 통해 제거사항을 수정하여 푸시를 통해 해결합니다. 여기서 DEV QA SIGN OFF가 나면 통합 테스트 환경인 INT 단계로 넘어가게 됩니다. INT로 넘어가면 가급적 수정이 일어나면 안됩니다.일반적인 Release/XX로의 코드프리징이됩니다.개발내용에따라, 이중화된 서버중 한대를 내리거나, 인터넷 연결선을 단절하거나 극단의 테스트를 수행하기도 합니다.이것에 대한 복구도 개발서버가 커버를 해야하는 부분입니다.INT-QAINT환경은 소스통합 테스트를 위한 개발환경이 아닙니다. 소스통합에 따른 문제는 DEV단계 Release를 통해 이미 완료 되었어야하며INT환경은 실제 서비스환경과 비슷한 테스트 환경으로, DB가 서비스수준으로 클린해야 합니다. DEV 테스트단계에서 여러가지한설정 조작들이 영향을 끼치는것을 방지하는 목적으로, DEV단계에서만 추가한 설정사항이 없어서 발생하는 누락사항등도 찾아야 합니다.즉 INT는 추가기능에 관련되지 않는 그 어떠한 설정 변경도 일어나면 안됩니다.SignOff전에는 Release브랜치를 통해 QA버그 FIX가 가능합니다. SignOFF가 일어나면 INT가 바로 운영에 반영되는것이아니라SignOff는 Release → Master로 통합될수 있다란 의미이자 실반영을 해도 된다란 약속이며 실제로 머지가 됩니다.하지만 여기서 끝이아니고 실제 가상 업데이트 시나리오를 최소 하루를 잡아 수행합니다.데브옵스는 INT의 모든 배포 변경사항을 현재 운영 서비스와 동일하게 롤백하고그동안 INT가 Release대상으로 디플로이 된것을 , Master로 변경합니다. Master를 통해 실서비스 반영과 똑같은 스텝으로 서비스 실 반영 가상 테스트 시나리오 에 돌입하게 됩니다.이상적으로 운영 순서에따른,혹은 설정사항 순서 적용에따른 문제를 미리 찾을수 있습니다.때로는 논스톱 서비스 진행을 확인을 위해..., 어떠한 설정변경은 백오피스를통해 실시간으로 모든사용자에게 변경을 시킬수 있으며 서버가 보증하는 기능중에 하나였으며 게임중인 사용자가 서버가 교체되어도, 교체된 사실을 모르고 게임을 진행합니다. 또한 동시에 Master를 통한 운영 디플로이를 준비합니다. (운영 빌드는 미리해둡니다.)-만약 이때, 운영 Fix가 발생한다면,그것은 지금것 방치되었다란 의미이며 무리하게 Fix하지 않고 다음으로 미룹니다.하지만 이경우도 stable 브랜치를 통해 fix는 가능합니다.LOADTEST-QAINT-QA가 진행되는 동안 로드테스트가 필요한 프로젝트이면 INT에 배포된 릴리즈를 통해 LOADTEST가 진행됩니다.개발자에게 불행이지만 LOADTEST장비는 실제 운영 장비수와 같습니다. 가장 최악 시나리오는LOADTEST에서 실패나서 SIGN-OFF난 INT환경을 수정해야되는 케이스입니다. LOADTEST는 INT-TEST와 별개로INT-RELEASE와 동기화하여 데일리 자동테스트 합니다.운영 INT-QA가 완료되었다고 운영에 반영할수 있는것은 아닙니다. 배포단계에 보안에 문제가 있는부분은 없는지? 이상하게 배포하고 있지 않는지?"DA001-멀티로그인운영반영" 티켓이 만들어집니다. 이곳에는 각종 적용스텝,롤백플랜등이 들어있습니다. ( DB는 자동화가 아님) 만약 하나라도 수동으로 조작하는 사항이 있다고하면, 최고 빌드관리자가 승인거부하여 프로덕에 올라갈수 없습니다.하지만 사안에따라 프로적트 조건부 승인을 하여.... 운영에 배포가 되어집니다. 서비스 운영에 반영후, hotfix가 생기면 아직 master가 최신개발반영소스라 master를 통해 hotfix 진행이 가능합니다. 운영에 발생한 버그는 , QA와 분리하여 올라옵니다 "OP-001 로그인안됨 심각단계 : L2"아주 큰 결정력이 따르지만 , 만약 긴급 롤백이 생긴다면, 개발소스를 통해 하는게 아니라... 이미 운영에 빌드완료되고 디플로이 셋트가 있기때문에디플로이 스냅샷을 통해 롤백이 가능합니다. ( 여기서 디플로이 스냅샷은 자동으로 생성되는것 or 수동으로라도 운영빌드된 소스를 백업이 됨을 의미)그리고 여기서 L3정도의 HotFix이면 바로 반영하기보다 , 반영과정에 문제가 없는지 체크가 필요하기 때문에정리이 긴내용을 언급된 티켓을 생성순으로 리스트업하면PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가기획-001:멀티 로그인을 통한 플래폼 기능개선PKIV-001-다중기기 사용자를 대비한 멀티 로그인 추가PKIV02-DB 다중로그인 추가SP A 수정SP B 추가PKIV03-서버 다중로그인추가LS변경GS변경DC변경TMS변경PKIV04-클라이언트 다중로그인추가관련 메시지추가ITO-001-멀티로긴 운영서버 두대추가ITO-002-잡다한 설정하기PKIV-005 다중로그인 QA여러가지 아주 많은 이슈DA001-멀티로그인운영반영업데이트 절차롤백방안서버적용범위관련 PRDOP-001 로그인안됨 심각단계 : L2PKIV-로그인해결개발티켓위와같이 한가지 개발 프로세스가 PRD를 통해서 연관 작업을 모두 파악할수 있으며반대로, 장애 이슈를 통해서도 이 이슈의 태초의 이슈인 프로덕 요구사항을 파악할수가 있습니다.폭포수모델로 단점으로 지적 되기도하지만,적어도 폭포가 어떻게 어디까지 떨어지는지 파악정도 가능하게됩니다.현재 개발 프로세스를 다시 공부하면서 다음 4가지를 통합구축하고 있습니다.JIRA : http://jira.webnori.com/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all빌드/배포 CI툴 : http://bam.webnori.com/allPlans.actionGIT툴 : http://git.webnori.com/dashboard개발 프로세스와 연동되는 문서화 기능 : http://wiki.webnori.com/
신규기능 추가에서 배포까지
신규기능 추가에서 배포까지 과정을 스토리화 합니다.
이것은 어떠한 개발 프로세스를 학습하고 기술하는게 아닌,
이전에 했던 경험을 바탕으로 개발자 기준으로 픽션화 하였습니다.
현재의 상황을 풍자한것을 아님을 밝힙니다.
하루에도 여러차례 서비스코드를 개선하기위해 커밋을하고, 그 커밋은 어떠한 결정에 의해 이루어졌으며
또한 서버재부팅도 어떠한 원인 파악을 통해 이루어졌지만 지식및 운영에 관련하여 그어떠한 노하우도 쌓이지않고
높아지지 않았습니다. 1년전과 똑같은 오늘을 보내고 있다라고 생각한 상위 관리팀에서 이러한 지침이 내려왔습니다.
그냥 놀아라, 너가 노는것을 보장해주겠다.
하지만 활동을 하고 싶은면 너가 하는일이무엇인지? 사소한 일도 티켓을 만들어라~
티켓:특정한 것을 할 수 있는 자격. (네이버사전)
그렇게 이야기는 시작이 됩니다.
신규기능 추가
신규기능은 어떻게 추가하나? 사업부에서 어떠한 아이디어를 떠올려 초안을 세웁니다.
티켓이름 "PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가"
내용: 다중기기 사용자가 늘고있으니, 멀티로그인을 허용해라~~ 이하 생략,아니 없음
하지만 어딘가 이러한 티켓이 발견이 됩니다. "BI-001 다중기기를 허용했을때 수익증가율 분석"
그리고 사업부 에서 BA에게 이 티켓을 좀더 분석해 구체안(기획서)을 만들라고 던집니다.
비지니스 분석가가 기획서를 만들어야하는것인가?에 대해서는 개발자는 알수없습니다.
기획자라고 부르지 않았으니까요~~
기획초안 작성
이제 BA는 발빠르게 움직입니다. 도대체 이게 무슨 내용이지? 기존 작동법부터 배우기시작합니다.
유니크한 로그인이 뭔지 그떄 파악하고 , 멀티로그인이 가능함으로 할수 있는 여러가지 아이디어를 넣기시작합니다.
충돌이나는 기존 기능에대해 고려하지 못할수도 있습니다.
그리고 기획문서 초안이 완성되는 시점 관련 개발팀을 소집합니다.
"기획-001:멀티 로그인을 통한 플래폼 기능개선" 내용: prd에서 내용약간 추가됨
BA와 개발자는 의사소통이 어렵기 때문에, 아케텍트에게 개발가능하게 구체화 해달라고 토쓰합니다.
분석
각 개발팀이 모여 어떻게 누가? 어떻게 개발해야할지 분석에 들어갑니다. PM은 이때 냄새를 맡고 , 개발관련 스케쥴을 컨트롤 하려고 합니다.
"PKIV-001-다중기기 사용자를 대비한 멀티 로그인 대장정(EPIC)" 일단 티켓을 만들고 봅니다.
(여기서 PKIV는 프로덕트기준 그들만이 사용하는 개발관련 티켓명이며 자동으로 붙습니다.)
아키텍트의 참관하에 BA가 설명을하고 어떤 개발팀이 필요한지 물어봅니다. 개발팀의 거짓말을 방지하기위해
감독역활로 아키텍트는 그냥 참관합니다. QA는 QA범위 산정을 위해 미리 참관을하지만, 기존 작동되는 방식에대해 더많은 설명을 하게되며
BI를 가르쳐줍니다. 이것은 문제가 될것 같은데요 라구~~
서버팀더 한마디 합니다. "이거 부하 증가가 예상되어 로그인서버 2대더 필요합니다." 하지만 뒤늦게 후회합니다.
괞히 부하이야기 꺼냈다가 아키텍트가 로드 테스트팀을 붙여서 로드테스트 티켓도 만들어버립니다.
PM은 잘 쉬고 있는 데브 옵스를 데리고 오고, 데브옵스는 "ITO-001-개발서버두대추가" 티켓을 즉석으로 만들고
PKIV- 개발대장정(EPIC) 티켓에 연결시킵니다. 물론 이 서브티켓에는 BIGIP등록및 SSL인증서 라우터룰셋팅등 잡다한 티켓이 생성됩니다.
알고싶지는 않지만, 서버두대 추가로 해야되는 고급 일들이 많아 보입니다. 그리고 데브옵스는 임무를 마치고 자기일 하러 갑니다.
결국 DB / 서버 / 클라이언트/모바일팀 4팀에서 개발을 하기로 결정하고 숨겨지고 함축된 의미에 대해
기획문서를 두리뭉실하게 재해석을 하고 파이팅을 외치며 회의는 끝나게 됩니다.
설계
아키텍트는 이떄부터 개발팀과함께 다이어그램을그리기 시작하며
어떠한 기능에대해 비지니스 로직이 어디에 있어야 하는가에 대해 분쟁이 시작됩니다.
DB냐? 서버냐? 게으른 서버개발자는 이것을 클라이언트에게 넘기기도 합니다.
아키텍트는 아름다운 중재를 합니다. 반반씩 해라~~~ DB반 서버반.... 이 단계가 길어집니다. PM이 개입합니다.
뭣이 중한디? 아무나 빨리하고 일정을 맞추시오. 어느정도 아키텍쳐가 그려지는듯 하더니 이러는 동안 PRD(프로덕요구사항)에 수정이 일어나고,
기획서가 변경됩니다. 기획-001 티켓을 은근슬쩍 수정하여 공지합니다
멀티 로그인 허용이지만 모바일은 허용하고,PC는 비허용
다시 분석단계를 돌아 설계단계로 와서 아키텍/서버/DB 의 논쟁이 끝나지 않습니다.
이런문제는 충돌자 3명다 수용을 시켜야 해결이되며, 이때 영웅이 등장하여 그 문제를 해결을 합니다.
이러한 티켓번호는 분쟁이 심하면 내용으로 기억되지 않습니다.
숫자로 기억됩니다. 7782번 티켓이라고 ..... 개발시간을 다 까먹었지만 릴리즈 날자는 변경없이 다음 단계로 돌입하게 됩니다.
개발
PKIV-001 대장정(EPIC) 에대한 서브 티켓으로 스토리가 생성됩니다.
각팀에서 해야할 스토리들이 만들어집니다. 하부에 어떠한 개발 STORY가 추가가되고
그 이야기에 대한 하부를 어떻게 그룹핑하고 풀어야 할지는 각 개발팀이 만들어야 하며 이때부터
진행사항을 PM이 개입하기 시작합니다.
개발팀에서는 소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 쓸모없습니다. 개발자가 안 알려준곳에서만 문제가 생깁니다.
최신 master로부터 featured-기능 브랜치를 각각 만들고, 개발테스트가 완료되면 release-1 브랜치로 통합하여 QA를 준비합니다.
이때 데브옵스는 릴리즈 브랜치를 확인하고 DEV 배포 환경을 준비합니다. (완전 자동화는 아님)
DEV배포환경이라고 한대씩에만 하지 않습니다. 실전과같이 L7스위칭 환경 테스팅도 포함되기때문에 적어도 이중화가되어 쌍을 이루어 배포하며
실제 개발서브 도메인을 사용합니다. host를 변경하여 테스트하는 순간 변질된 테스트이기때문입니다.
host를 변경하는 테스트를 DEV테스트라고 하지 않습니다. 이것은 로컬 테스트입니다.
DEV-QA
release/XX 브랜치를 통해 QA가 시작됩니다. 여기서 여러가지 수정사항이 생깁니다. 가끔 끼어들어온 featured/YX 빼기로 한다면
이미 통합되어 자동으로 뺄수 없습니다.(변경차를 빼는기능이 있는지 모르겠습니다.)
release 브랜치를 통해 제거사항을 수정하여 푸시를 통해 해결합니다. 여기서 DEV QA SIGN OFF가 나면
통합 테스트 환경인 INT 단계로 넘어가게 됩니다. INT로 넘어가면 가급적 수정이 일어나면 안됩니다.
일반적인 Release/XX로의 코드프리징이됩니다.
개발내용에따라, 이중화된 서버중 한대를 내리거나, 인터넷 연결선을 단절하거나 극단의 테스트를 수행하기도 합니다.
이것에 대한 복구도 개발서버가 커버를 해야하는 부분입니다.
INT-QA
INT환경은 소스통합 테스트를 위한 개발환경이 아닙니다. 소스통합에 따른 문제는 DEV단계 Release를 통해 이미 완료 되었어야하며
INT환경은 실제 서비스환경과 비슷한 테스트 환경으로, DB가 서비스수준으로 클린해야 합니다. DEV 테스트단계에서 여러가지한
설정 조작들이 영향을 끼치는것을 방지하는 목적으로, DEV단계에서만 추가한 설정사항이 없어서 발생하는 누락사항등도 찾아야 합니다.
즉 INT는 추가기능에 관련되지 않는 그 어떠한 설정 변경도 일어나면 안됩니다.
SignOff전에는 Release브랜치를 통해 QA버그 FIX가 가능합니다. SignOFF가 일어나면 INT가 바로 운영에 반영되는것이아니라
SignOff는 Release → Master로 통합될수 있다란 의미이자 실반영을 해도 된다란 약속이며 실제로 머지가 됩니다.
하지만 여기서 끝이아니고 실제 가상 업데이트 시나리오를 최소 하루를 잡아 수행합니다.
데브옵스는 INT의 모든 배포 변경사항을 현재 운영 서비스와 동일하게 롤백하고
그동안 INT가 Release대상으로 디플로이 된것을 , Master로 변경합니다.
Master를 통해 실서비스 반영과 똑같은 스텝으로 서비스 실 반영 가상 테스트 시나리오 에 돌입하게 됩니다.
이상적으로 운영 순서에따른,혹은 설정사항 순서 적용에따른 문제를 미리 찾을수 있습니다.
때로는 논스톱 서비스 진행을 확인을 위해..., 어떠한 설정변경은 백오피스를통해 실시간으로 모든사용자에게 변경을 시킬수 있으며
서버가 보증하는 기능중에 하나였으며 게임중인 사용자가 서버가 교체되어도, 교체된 사실을 모르고 게임을 진행합니다.
또한 동시에 Master를 통한 운영 디플로이를 준비합니다. (운영 빌드는 미리해둡니다.)
-만약 이때, 운영 Fix가 발생한다면,그것은 지금것 방치되었다란 의미이며 무리하게 Fix하지 않고 다음으로 미룹니다.하지만 이경우도 stable 브랜치를 통해 fix는 가능합니다.
LOADTEST-QA
INT-QA가 진행되는 동안 로드테스트가 필요한 프로젝트이면 INT에 배포된 릴리즈를 통해 LOADTEST가 진행됩니다.
개발자에게 불행이지만 LOADTEST장비는 실제 운영 장비수와 같습니다. 가장 최악 시나리오는
LOADTEST에서 실패나서 SIGN-OFF난 INT환경을 수정해야되는 케이스입니다. LOADTEST는 INT-TEST와 별개로
INT-RELEASE와 동기화하여 데일리 자동테스트 합니다.
운영
INT-QA가 완료되었다고 운영에 반영할수 있는것은 아닙니다. 배포단계에 보안에 문제가 있는부분은 없는지? 이상하게 배포하고 있지 않는지?
"DA001-멀티로그인운영반영" 티켓이 만들어집니다. 이곳에는 각종 적용스텝,롤백플랜등이 들어있습니다. ( DB는 자동화가 아님)
만약 하나라도 수동으로 조작하는 사항이 있다고하면, 최고 빌드관리자가 승인거부하여 프로덕에 올라갈수 없습니다.
하지만 사안에따라 프로적트 조건부 승인을 하여.... 운영에 배포가 되어집니다.
서비스 운영에 반영후, hotfix가 생기면 아직 master가 최신개발반영소스라 master를 통해 hotfix 진행이 가능합니다.
운영에 발생한 버그는 , QA와 분리하여 올라옵니다 "OP-001 로그인안됨 심각단계 : L2"
아주 큰 결정력이 따르지만 , 만약 긴급 롤백이 생긴다면, 개발소스를 통해 하는게 아니라... 이미 운영에 빌드완료되고 디플로이 셋트가 있기때문에
디플로이 스냅샷을 통해 롤백이 가능합니다. ( 여기서 디플로이 스냅샷은 자동으로 생성되는것 or 수동으로라도 운영빌드된 소스를 백업이 됨을 의미)
그리고 여기서 L3정도의 HotFix이면 바로 반영하기보다 , 반영과정에 문제가 없는지 체크가 필요하기 때문에
정리
이 긴내용을 언급된 티켓을 생성순으로 리스트업하면
위와같이 한가지 개발 프로세스가 PRD를 통해서 연관 작업을 모두 파악할수 있으며
반대로, 장애 이슈를 통해서도 이 이슈의 태초의 이슈인 프로덕 요구사항을 파악할수가 있습니다.
폭포수모델로 단점으로 지적 되기도하지만,적어도 폭포가 어떻게 어디까지 떨어지는지 파악정도 가능하게됩니다.
현재 개발 프로세스를 다시 공부하면서 다음 4가지를 통합구축하고 있습니다.
JIRA : http://jira.webnori.com/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all
빌드/배포 CI툴 : http://bam.webnori.com/allPlans.action
GIT툴 : http://git.webnori.com/dashboard
개발 프로세스와 연동되는 문서화 기능 : http://wiki.webnori.com/