Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

DEV배포환경이라고 한대씩에만 하지 않습니다. 실전과같이  L7스위칭 환경 테스팅도 포함되기때문에 적어도 쌍을 이루어 배포합니다.


DEV-QA

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

...

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

INT-QA

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

INT환경은 실제 서비스환경과 비슷한 테스트 환경으로,  DB가 서비스수준으로 클린해야 합니다. DEV 테스트단계에서 여러가지한

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

즉 INT는 개발에 관련되지 않는 그 어떠한 설정 변경도 일어나면 안됩니다.

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

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

여기서 끝이아니고...

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

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

데브옵스는 그동안 INT가 Release대상으로 디플로이 된것을 , Master로 변경합니다. 

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

또한 동시에 Master를 통한 운영 디플로이를 준비합니다. (운영 빌드는 미리해둡니다.)

-만약 이때, 운영 HotFix가 발생한다면,그런일은 거의 없지만 Master가 변경되었기때문에 운영적용이 완료되면 tag 브랜치를 따기때문에 tag브랜치를 통해 한후 이후 통합합니다.


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"

아주 큰 결정력이 따르지만 , 만약 긴급 롤백이 생긴다면, 개발소스를 통해 하는게 아니라... 이미 운영에 빌드완료되고 디플로이 셋트가 있기때문에

디플로이 스냅샷을 통해 롤백을 진행합니다.  하지만 이경우도 INT를 통해 진행하려고 하는 롤백 스텝으로 문제가 복구가능한지 INT가 현재의

운영과 동일하기 떄문에 INT를 통해 할수가 있습니다. 역시 우리의 만능 데브옵스가 진행합니다. (일부소스 DB제외)


정리

이 긴내용을 언급된 티켓을 리스트업하면

PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가

기획-001:멀티 로그인을 통한 플래폼 기능개선

PKIV-001-다중기기 사용자를 대비한 멀티 로그인 추가
PKIV02-DB 다중로그인 추가
PKIV03-서버 다중로그인추가
PKIV04-클라이언트 다중로그인추가

ITO-001-개발서버두대추가

PKQA-001 다중로그인 QA
여러가지 이슈

DA001-멀티로그인운영반영

OP-001 로그인안됨 심각단계 : L2


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

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