PreProd와 Prod의 환경은 얼마나 유사해야합니까?

방금 프로젝트에 참여했으며 릴리스 중에 프로덕션에서 작동하지 않는다는 것을 깨달았습니다. 다른 모든 환경에서 작동하지만 별도의 릴리스 팀이 있고 서버와 환경을 직접 설정할 수 없으므로 구성에 대한 가시성이 없습니다.

우리는 Prod가 자신의 계정이나 IIS 설정에서 다른 일부 사용자 권한을 가지고 있다고 의심하여 ​​지금도 작업하고 있습니다.

그래서 저는이 모든 것이 저에게 학습 경험이었고 같은 것을 다시 반복하고 싶지 않다고 생각합니다. 이 환경이 얼마나 다른지 물어보고 싶습니다. 나는 항상 PreProd가 동일한 데이터베이스의 사본을 사용하고 동일한 사용자 계정의 사본을 사용하는 동일한 서버 등에 설치된 Prod 환경과 동일한 사본이어야한다고 생각했습니다.

그러나 얼마나 멀리 가져 가야합니까? 웹 사이트가 외부를 향하고 있다면 PreProd가 외부를 향해야합니까? 웹 사이트에 사용자 계정이나 암호가 필요없는 구성 요소가있는 경우 어떻게해야합니까? 외부 세계에 노출해도 괜찮습니까?

가능하면 프로덕션 서버와 동일한 환경에서 테스트해야합니다. 그렇지 않으면 고객이 사용할 것을 테스트하지 않습니다. 다른 것이 없다면 버그 보고서를 테스트하기 위해 그러한 환경이 필요합니다.

분명히 지불 시스템에 대한 동일한 링크를 원치 않는 것들이 떠오를 것입니다. 그러나 그것들은 마치 실제처럼 조롱해야합니다 . 복제 할 수없는 것 (시스템의 규모)도 있습니다.

외부 URL을 통해 테스트하고 싶을 수도 있습니다. 다시 사용자에게 표시되는 내용을 테스트하고 있습니다. 또한 외부 URL을 통한 테스트는 시스템의 내부 사용과 다른 방식으로 네트워크를 사용합니다. 사용 권한 (예 : 사용 가능한 대역폭, 방화벽 등)이 역할을 수행합니다. 모든 사용자가 직면하게되지만 시스템에 직접 액세스하면 건너 뜁니다.

그래도 계정과 암호가 필요없는 구성 요소에는 문제가 없습니다. 암호가 필요하지 않은 경우 중요 / 민감하지 않고 암호가 중요하지 않은 이유는 무엇입니까?

이에 대한 모범 사례는 Jez Humble 과 David Farley가 Continuous Delivery라는 책 에서 공동 작성했으며 Martin Fowler가 블로그 게시물 Blue Green Deployment 에 설명한 Blue Green Deployment 접근법이라고 생각합니다 .

전제는 매우 간단합니다. Martin Fowler의 게시물에서 :

청록색 배포 방식은 ... 가능한 한 두 개의 프로덕션 환경을 보장합니다. 언제라도 그 중 하나가 파란색이라고 가정 해 봅시다. 소프트웨어의 새 릴리스를 준비 할 때 녹색 환경에서 최종 테스트 단계를 수행합니다. 소프트웨어가 녹색 환경에서 작동하면 모든 들어오는 요청이 녹색 환경으로 이동하도록 라우터를 전환합니다. 이제 파란색 요청이 유휴 상태입니다.

청록색 배포는 또한 롤백하는 빠른 방법을 제공합니다. 문제가 발생하면 라우터를 다시 파란색 환경으로 전환하십시오.

이 접근 방식은 동일한 사전 프로덕션 및 프로덕션 환경이없고 배포 전략을 최적화하는 문제를 해결합니다.

최종 프로덕션 환경은로드 밸런서에서 가져온 라이브 서버 중 하나입니다. 사전 프로덕션 빌드 (기본적으로 데이터베이스 연결 문자열 및 몇 가지 다른 구성 변경을 제외하고 라이브 빌드와 동일 함)를 배포하고 테스트합니다. 정상적으로 작동하면 라이브 코드를 배포하고 마지막으로 정상이면 서버를로드 밸런서로 반환하고 프로덕션 빌드를 나머지 서버에 하나씩 배포합니다.

확장 할 수없는 경우를 제외하고 시스템 내에서 문제를 식별 할 수 있도록 가능한 한 비슷해야합니다. 가능하다면 프로덕션 환경과 사전 프로덕션 / 스테이징 / 테스트 환경 간의 유일한 차이점은 크기 일 것입니다. 프로덕션 환경은 대규모 환경에서 더 많은 시스템으로 구성 될 것으로 예상합니다. 데이터베이스 서버, 웹 서버 등과 같은 시스템의 헌신도 반영해야합니다.

그러나 현재 예산으로는 정확한 복제가 불가능할 수 있습니다. 가까울수록 더 효과적인 테스트가 이루어지고 생산 과정에서 문제가 발생할 가능성이 줄어 듭니다.

이 환경이 대중과 맞 닿아 야하는지 ChrisF 와는 다른 입장을 취합니다 . 나는 그렇게해서는 안된다고 말합니다. 실제 데이터베이스의 사본 또는 실제 실제 데이터베이스의 서브 세트 사본 및 내부 환경에서 실행하도록 선택합니다. 이러한 방식으로 실제 데이터와 실제 데이터를 테스트하고 보안 허점에 대해 걱정할 필요가 없습니다. 물론 데이터를 위생 처리 할 수는 있지만 실제 시스템에서 결함을 발견 할 수있는 환경에서 일부 "더러운 데이터"가 제거 될 수 있습니다.

은행, 통신 등에서 일한 모든 곳에서 데이터베이스는 일주일 정도가 아니라는 것을 제외하고는 직접 생산물 사본이었습니다. 사전 제작 전반에 걸쳐 데이터를 유지 관리하는 것은 엄청난 프로세스 였지만, 내가 사전 제작 한 구현 회사에서 필수적인 것으로 간주되었습니다.

AU 뱅킹 섹션에서 정부는 서비스 실패로 은행에 벌금을 부과합니다 (예 : 웹 사이트 ATM 등). 개발 / 테스트 팀이 사건에 대해 해고 된 것을 듣는 것은 드문 일이 아닙니다. 사전 Prod는 모든 회사 나 개발 프로세스에 해당되는 것은 아니지만 일부에게는 필수입니다.