Page History

...

그 이야기에 대한 하부를 어떻게 그룹핑하고 풀어야 할지는 각 개발팀이 만들어야 하며 이때부터

이때부터 진행사항을 PM이 개입하기 시작합니다.  

개발팀에서는 PM은 스토리 과정에 관심이 없고 스토리가 완료되는것에만 관심이 있습니다.

실질적인 하위 일(TASK)이 빨리끝나 이야기를 끝내어야 하기때문에 당근과 채찍을 준비합니다.

개발팀은 당근과 채찍을 구분을 하지 못합니다. 그냥 일이 생겨 일을 하기 시작하며  

소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 쓸모없습니다.

대부분 버그는 개발자가 안 알려준곳에서만 문제가 생깁니다.

-- 지금부터 개발자의 입장에서 서술합니다.

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

이때 데브옵스는 이와 동시에  데브옵스는 릴리즈 브랜치를 확인하고 DEV 배포 환경을 준비합니다. (완전 자동화는 아님)

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

스위칭이되는 장비는 최소  이중화가되어 쌍을 이룹니다.

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

host를 변경하는 테스트를 DEV테스트라고 하지 않습니다. 이것은 QA에 내보낼수 없는 로컬 테스트입니다.

사용자에게  system 폴더에 있는 host파일을 관리자 권한으로 열어서 따따따.com을 111 로 바꾸면 우리의 솔류션은

완벽하게 작동됩니다. 라고 이야기하는것입니다.

DEV-QA

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

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

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

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

일반적인 Release/XX로의 코드프리징이됩니다

기획서의 내용이 추가되고 개발이 추가됩니다.

동시에 기능 TEST를 하고 A를 FIX하고 문제가 없던 B가 문제가 생깁니다. 

QA는 불평을 합니다. A를  개선하고 FIX 하였는데, B가 왜 문제 생기냐고?

개발자는 쏘리하고 B도 수정해줍니다. 험난한 고비를 넘어 QA의 SING-OFF가 나기직전입니다.

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

이것에 대한 복구도 개발서버가 커버를 해야하는 부분입니다.  이러한 극단 테스트는 

10번 시도하고 8번정도 복구가됩니다.  인터넷 제공업체의 인터넷 품질에 대해 커버를 모두할수는 없기에 테스트 OK하고

넘어갑니다. 

 이제 대서사시(EPIC) 종료를 위해

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

우리끼리 약속한 릴리즈가 프리징단계가 되며 문제가 없을것이라고 희망을 합니다.

INT-QA

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

희망사항이 이어진다고 하면, 여기서 넘어온 릴리즈 환경이 리얼서비스환경에 반영이되어도 문제가 없어야합니다.

여기서 버그를 찾고 머지되고 반복하는 행위는.., 곧 INT를 포기하고 DEV로 넘어가야한다는것을 의미 합니다.

INT환경은 실제 서비스환경과 비슷한 테스트 환경으로,  DB가 서비스수준으로 클린해야 합니다노이즈가 없어야합니다.

DEV 테스트단계에서 여러가지한

설정 조작들이 영향을 끼치는것을 방지하는 목적으로,  DEV단계에서만 추가한 설정사항이 없어서 발생하는 누락사항등도 찾아야 합니다.

즉 INT는 추가기능에 관련되지 않는 그 어떠한 설정 변경도 일어나면 안됩니다이루어진 여러가지 설정은 DB에 반영이되며 , 운영수준에서는 사실 QA수준으로 변경이 발생하지 않습니다.

설정조작방지외에 ,  기능을위해 DEV단계에서만 추가한 설정사항이 없어 발생하는 누락사항도 찾아야 합니다.

기능추가를 위해 중요한 옵션설정을 테스트단계에서 해놓고 운영에 빠트려 발생한 문제가 많았기때문입니다.

SignOff전에는 Release브랜치를 통해 QA버그 FIX가 가능합니다.  SignOFF가 일어나면 INT가 진행되지만,  SignOFF가 일어나도  Release가 바로 운영에 반영되는것이아니라

SignOff는 Release → Master로 통합될수 있다란 의미이자  실반영을 해도 된다란 약속이며 실제로 머지가 됩니다.

...

Master를 통해 실서비스 반영과 똑같은 스텝으로 서비스 실 , 실제 반영  가상 테스트 시나리오 에 돌입하게 됩니다.

...

때로는 논스톱 서비스 진행을 확인을 위해..., 어떠한 설정변경은 백오피스를통해 실시간으로 모든사용자에게 변경을 시킬수 있으며 

서버가 보증하는 기능중에 하나였으며 게임중인 사용자가 서버가 교체되어도, 교체된 사실을 모르고 게임을 진행합니다. 

또한 동시에 푸시를하며

이상적인 보증은 사용자가 업데이트를 감지못하는것이며,  이것은 서버가 최대한 보증을 하려고 합니다.

이것은 마치 민방위 훈련처럼 진행이되며 가상 업데이트 타임시 QA 계속 여러가지 활동을 합니다.

교체과정에  사소한 무슨 문제 확인을 위해

이쯔음 데브옵스는  동시에 Master를 통한 운영 디플로이를 준비합니다. (운영 빌드는 빌드와 배포와 교체실행은  분리되어야하는것으로 빌드를 미리해둡니다.)

-만약 이때, 운영 Fix가 발생한다면운영버그를 발견한다면,그것은 지금것 방치되었다란 의미이며  무리하게 Fix하지 않고 다음으로 미룹니다.

하지만 이경우도 stable 브랜치를 통해 fix는 가능합니다가능하나, 인생에도 그렇듯이 과거를 후회하는것을 되돌리는것(롤백)은 실제로는 타임머신이 없이는 불가능하며

아주 큰 리스크가 따릅니다.

LOADTEST-QA

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

...

LOADTEST에서 실패나서  SIGN-OFF난 INT환경을 수정해야되는 케이스입니다. LOADTEST는 INT-TEST와 별개로INT-RELEASE와 동기화하여 데일리 자동테스트 합니다

다시 INT테스트를 수행하야하며, 다시 LOADTEST도 해야합니다. 이 모든것을 통과하고도

진정한 부하문제는 부하 시나리오에 고려하지 못한것이 운영중에 나오게 됩니다.  그렇다고 최악은 아닙니다.

통과한 9개는 관련이 없으니까요~  9개를 제외하고 나머지 1~2개중에서 용의자로 좁혀질수 있습니다.

운영

 INT-QA가 QA/LOAD TEST 가 완료되었다고 운영에 반영할수 있는것은 아닙니다.

배포단계에 보안에 문제가 있는부분은 없는지? 이상하게 배포하고 있지 않는지?

"DA001-멀티로그인운영반영"  티켓이 만들어집니다.  이곳에는 각종 적용스텝,롤백플랜등이 들어있습니다. (DB는 자동화가 아님자동화제외) 

만약 하나라도 이상한점이 있거나 수동으로 조작하는 사항이 있다고하면있다고 하면, 최고 빌드관리자가 승인거부하여 빌드관리자의  승인거부하여 프로덕에 올라갈수 없습니다.

하지만 사안에따라 프로적트 조건부 승인을 하여.... 운영에 배포가 되어집니다.런칭일정준수상  프로덕트 관리자의 조건부 승인으로 올려 보내게 되며, 수동배포는 다음에 빅이슈가 되어 처리해야할 개발과제가 생기게됩니다. 

이제 겨우 배포후 , 실행을 하였습니다. 

서비스 운영에 반영후, hotfix가 생기면 아직 master가 최신개발반영소스라 master를 통해 hotfix 진행이 가능합니다. 

...

디플로이 스냅샷을 통해 롤백이 가능합니다. ( 여기서 디플로이 스냅샷은 자동으로 생성되는것 or 수동으로라도 운영빌드된 소스를 백업이 됨을 의미)

그리고 여기서 L3정도의 HotFix이면 우선순위 Fix이면 바로 반영하기보다 반영 하기보다, 반영과정에 문제가 없는지 체크가 필요하기 때문에

약소한 INT단계를 한번더 거친후 문제가 없음을 확인하고, 서비스에서 HOTFIX 반영이 이루어집니다.

이 모든 과정이 끝나면  PKIV-001 멀티로그인 대장정(EPIC) 티켓이 끝나게 됩니다.

정리

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

• 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-멀티로그인운영반영
  • 업데이트 절차
  • 롤백방안
  • 서버적용범위
  • 관련 PRD
• OP-001 로그인안됨 심각단계 : L2
  • PKIV-로그인해결개발티켓

위와같이  위와같이 한가지 개발 프로세스가 PRD를 통해서 통하여 연관 작업을 모두 파악할수 있으며

반대로, 장애 이슈를 통해서도 이 이슈의 태초의 이슈인 프로덕 요구사항을 파악할수가 있습니다.폭포수모델로 단점으로 지적 되기도하지만,적어도 폭포가 어떻게 어디까지 떨어지는지 파악정도 가능하게됩니다.

이것의 중요한 의미는 티켓을통한  대장정(epic)이  축적이되어  자산(백과사전)이 된다는 것입니다.

한가지 예로 동일 문제처리를 위한 코드수정이, 기존에도 있었다란 점이며

우리는 2년 축적해서 겨우 알게 되었습니다. 1년짜리 SSL갱신문제가 1년전 같은날짜에 있었음을..

...

현재 개발 프로세스를 다시 공부하면서 다음 4가지를 통합구축하고 통합 구축중에 있습니다.

JIRA : http://jira.webnori.com/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all

...