Page History

...

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

 QA완료된 릴리즈 프리징 된 배포버젼이 리얼에 올라가도 문제가 없는게 우리의 희망사항이나

이상은 그렇지 않습니다. 그래서 DEV에 했던 단편적인 테스트를 모두 집합시켜 INT에 한방에 반영하여 풀테스트를 진행합니다. 

가끔 이런 문제제기를 합니다.  INT에서 10%를 빼겠다고, 왜 이런것이 깔끔하게 안되냐고?

답은 간단합니다  INT를 포기하고 DEV단계로 다시 가야하는 이슈입니다. 소스머지가 완벽한다고 해도 안될일입니다.

애시당초 INT에서는 머지를하거나 뺄려고 만든 환경이 아니기 때문입니다. 이것은 SVN,GIT과 상관없이 형상관리를 초월하는 문제입니다.

애시당초  기능활성 미지수인것은 실시간 옵션화로 미리 계획되어야 되는일이며 실제로 수많은 예상기능들이

그렇게하여 소스와 머지된상태로 비활성화되어 올라갔습니다. 또한 옵션 활성/미활성에따른 이중 테스트도 포함이 되었구요

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

...

 코드프리징이 일어난 Release라 할지라도,DEV에 가지않고  중요한 작은범위의 변경정도는 할수가 있습니다. 적어도 변경범위에따른 QA 변화량을측정후 변경이 일어나야합니다. 이 경우도 심각도에따라 크지 않는이상, 그냥 올리는 경우도 발생합니다. 

추가 변경 테스트를  INT에서 해야하고 소스차가 생겼기때문에 이상황에서는 DEV의 가치는 없어졌습니다. 

그리고 일정상 어떠한 문제에대해서 안올리는게 좋다란 QA판단을 합니다.

A를 고치니...더 중요한 B문제를 놓치는 케이스가 분명 있기때문입니다있기때문에 코드변경시 일정내에 QA에서 검증을 할수 없다라고 합니다.  

이것은 이미 보고된 문제임으로 프로덕트 조건 승인이 이루어져야 가능한 일입니다.

자 모든 QA활동을 마쳤습니다.

까지 이루어지면 다음에 개선하기로하고 넘어가는 경우도 있으며

분명 무리하게 고친것보다 , 더 안정적이게 됩니다.

이제 힘든 QA활동을 마쳤습니다. 이것이 바로 프로덕에 갈꺼같지만 몇가지 단계가 더 남았습니다.

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

하지만 여기서 끝이아니고 실제 운영반영 민방위 훈련을 최소 하루전  수행합니다운영반영을 위한 민방위 훈련이 하루종일 시행이됩니다.

데브옵스는 INT의 모든 배포 변경사항을  현재 운영 서비스와 동일하게 롤백하고

...

이상적으로 운영 순서에따른,혹은 설정사항 순서 적용에따른 문제를 미리 찾을수 있습니다.

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

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

교체과정의 문제확인을 위해, 교체과정중에도 QA는 이것을 위한 테스트 활동을 합니다QA는 모든 업데이트 타임을 보고받고, 그 타이밍에 맞는 스모크 테스트를 합니다. 

한가지 예로 로그인서버가 순차 교체가 된다고하면,  그 타이밍에 로그인을 계속 시도하는것입니다.

이쯔음 데브옵스는  동시에 Master를 통한 운영 빌드및 디플로이를 준비합니다.

...

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

이경우 stable 브랜치를 통해 fix는 가능합니다가능하나, 굳이 그러지 않습니다.

...

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

"DA001-멀티로그인운영반영멀티로그인 추가에따른 운영반영"  티켓이 만들어집니다.  이곳에는 각종 적용스텝,롤백플랜등이 들어있습니다.

만약 하나라도 이상한점이 있거나 수동으로 조작하는 사항이 있다고 수동조작으로 악성코드를 심을수 있는 상황을 개발자에게 제공할 기회를 준다고 하면,

최고 빌드관리자의  승인거부하여  승인거부하에 프로덕에 올라갈수  올라갈수 없습니다.

하지만 이경우 런칭일정준수상  프로덕트 관리자의 조건부 승인으로 올려 보내게 되며, 승인이 추가로 필요합니다. 

운영 수동배포는 다음에 빅이슈가 빅이슈 되어 처리해야할 개발과제가 생기게됩니다됩니다. 대부분 고질적 문제로 자동배포는 빠르게 해결이안됩니다.

빌드관리자의 승인거부는 릴리즈 날짜를 방해하는 요소가 배포서비스를 안정화하겠다란 의지이며

결국 추후 자동배포처리가 모두 되었습니다. 

이제 험난한 과정을 거치고 드디어 런칭하였습니다.  이제부터느 운영이기때문에 집중 테스트가 진행됩니다.

QA에선 테스트기간 1주일동안 못찾은 문제를, 1분만에 찾는 초능력을 발휘하기도 합니다.

INT가에도 나면 QA에서 누락, 리얼에서만 나면 무엇인가 환경이 잘못된것이기때문에 양방향 테스트합니다.

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

...

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

이러한 문제는 퇴근후 잠자려고할때 발생하고, 롤백후 개발복구는 기존 개발과 QA를 다 다시해야된다란 의미 이기때문에 권장되지 않으며최소한의 범위내에서 문제를 찾으려고 합니다. 아무문제없어하고 모든 운영 반영 테스트를 마치고 새벽에 잠이들때 발생합니다.

이때 이미 회사는 퇴근후 개인 사생활을 보장했기때문에 개인 휴대폰을 통해 연락하지 않으며연락할수 없으며

개인 전화번도또한 리스트업을 하지 않았습니다. 참 좋은 회사죠......

그래서  그래서 회사가 준비했습니다. 운영대응 개발자에게 폰을 하나씩 지급했습니다. 휴대폰비도 내줘서 잘썻습니다무제한 데이터로 아주 잘사용했습니다.

하지만 이 전화는 새벽에 울립니다. L2일때 말이죠 

...

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

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

...

• PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가
  • 기획-001:멀티 로그인을 통한 플래폼 기능개선
  • 7782
  • 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-새벽에 잠깨는 ,로그인해결개발티켓

...

반대로, 장애 이슈를 통해서도 이 이슈의 태초의 이슈인 프로덕 요구사항을 파악할수가 있습니다.

새벽에 나의 잠을 깨운 티켓및 담당자 추적도 가능합니다. 

이야기가 정리없이 길었지만

이것의 중요한 의미는 서사시(epic)가  축적이되어 우리의 자산(백과사전)이 된다라는 것입니다....

...

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

...