준비의 요점은 무엇입니까?

18

나는 이것을 해결할 것이라고 생각했지만 Continuous Delivery (우수한 책)를 읽은 후에 약간 혼란 스럽습니다. 그들은 다음을위한 서버를 갖는 것에 대해 이야기합니다.

개발
다양한 형태의 자동 테스트
UAT (User Acceptance Testing) – 클라이언트와 함께 앉아서 시연하고 탐색 테스트를 수행 할 수 있도록합니다. 사내 테스터는 탐색 테스트에이 설정을 사용할 수도 있습니다.
각색
생산.

스테이징은 항상 UAT 기능을 제공하는 것으로 생각했지만 별도의 레벨로 스테이징 한 것 같습니다. 따라서이 체계에서 준비 서버는 어떤 기능을 제공합니까?

deployment testing release-management

10

나는 그 방법론에 동의한다고 말할 수 없다. UAT는 항상 라이브 시스템에 가능한 한 가까운 사양 (예 : 준비)으로 수행해야합니다. 우리가 UAT를 수행 한 횟수를 셀 수없고 속도 문제에 대해 모든 사람들이 불만을 제기하게했는데, "라이브 시스템이 더 빠를 것"이라고 천 번 설명해야합니다. 그리고 코드의 버그 나 SQL 쿼리로 인해 라이브 시스템이 더 빠르지 않으면 자신의 단어를 먹어야합니다.

— Mark Henderson

UAT = 사용자 승인 테스트, 맞습니까?

— 마틴 토마

13

스테이징은 전체 제품 시스템을 제자리에두고 있지만 실제로는 사용하지는 않습니다. 그들이 사용하게되면 "생산"이 될 것입니다. 사용할 모든 것을 제자리에 놓고 테스트 한 다음 스위치를 뒤집어 야합니다.

UAT는 일반적으로 프로덕션에 사용될 하드웨어 / 소프트웨어 / 구성과 크게 다른 "테스트"환경을 사용합니다.

예를 들어, 내가 일하는 곳에서 고객은 서버에서 실행되는 VM 환경의 모든 것을 테스트하게됩니다. 시스템이 가동되면 하드웨어, 시설에서 실행되며 아마도 기존 시스템과 통합 될 것입니다. 서버 또는 테스트 환경과 전혀 관련이 없습니다 (코드 및 일부 구성이 복사 된 것을 제외하고 ...)

— 크리스 S
소스

프로덕션에 들어가기 직전에 UAT뿐만 아니라 준비 서버에서도 더 많은 테스트가 수행됩니다.

— jftuga

3

@jftuga, 첫 번째 단락의 마지막 문장을 참조하십시오 ...

— Chris S

@Chris S : 내가 당신을 올바르게 이해한다면, "스테이징 서버"와 같은 것은 풀에 있지 않고 현재 최종 사용자에게 제공되지 않는 프로덕션 서버 일뿐입니다. 그것은 말이되고, 내가 따르는 방법론이지만, 그 서버를 "스테이징 서버"라고 부르지 않고, 단지 프로덕션 서버 (풀에 있지 않은)라고합니다. 스테이징 서버를 사용하는 모든 곳에서 스테이징 서버를 별도의 서버로 사용하므로 스테이징 서버에 대한 설명이 해당 용어의 표준 사용이라고 생각하지 않습니다. 좋은 생각이지만 일반적으로 "스테이징 서버"가 의미하는 것은 아닙니다 (제 경험상, 어쨌든).

— iconoclast

1

@Brandon 당신의 경험에서 "스테이징 서버"는 무엇입니까? 서버 "바운스 거부"와 같은 지역별 차이 일 수 있습니다.

— Chris S

조직마다 다른 것 같습니다. 필자는 UAT 서버, 개발자가 프로덕션과 같은 환경에 응용 프로그램을 배치하는 서버 및 다른 것들로 사용하는 서버로 사용하는 것을 보았습니다. (개인적으로는 유일한 전략은 준비를 위해 실제 프로덕션 서버를 사용하는 것이라고 생각합니다.) 다른 조직이 자체 문화를 개발함에 따라 자체 사전과 함께 업계 전반에서 표준 의미를 가져야하는 단어도 개발한다고 생각합니다. 불행히도하지 마십시오.

— iconoclast

17

저는 매우 큰 인터넷 회사의 릴리스 관리 팀에서 일하고 있습니다. 우리는 본질적으로 위에서 설명한 프로세스를 사용하며 의도적으로 해당 프로세스를 선택했습니다. 우리의 방법론에서, 스테이징은 생산의 최종 테스트 수준을위한 분기 메커니즘으로 사용됩니다.

프로덕션에 가기 전에 모든 테스트를 수행하고 싶지만 사용자가 많은 크고 복잡한 환경에서는 도달하기가 매우 어려운 목표입니다. 특히 QA에 테스트 소프트웨어를 적절히로드하는 것은 사실상 불가능합니다. 기능 테스트는로드 테스트보다 자동화하기가 훨씬 쉽습니다. 수천 명의 사용자가 서버를 공격하면 상황이 이상하고 예측하기 어렵습니다.

우리가하는 일은 다음과 같습니다.

개발
- 지속적인 통합 및 자동 테스트 포함
릴리스 테스트
- 내 그룹은 릴리스 자체를 분석합니다
- 설치 로그 검토
- 롤백 테스트
품질 관리
- 사용자 수락 테스트

그것이 우리가 준비 단계와 생산 단계를 구분하는 지점입니다. 우리는 출시를 위해 기차 모델을 사용하며 몇 주마다 새로운 기차가 시작됩니다. 번호가 매겨진 열차도 스테이징 서버 (생산중인)로 이동합니다. 홀수 열차는 그렇지 않습니다.

짝수 열차 사이에서 개발자는 개별 변경 사항을 스테이징 서버에 푸시 할 수 있습니다 ( 물론 QA에서 변경 사항을 테스트 한 후 ). 이를 통해 실제 프로덕션 환경에서 소프트웨어가 예상대로 작동하는지 확인할 수 있습니다. 이것은 일반적으로 더 높은 위험으로 간주되는 구성 요소를 위해 예약되어 있으며 모든 작은 조각을 준비로 푸시하지는 않습니다.

그런 다음 모두 다음 열차가 시작될 때 스테이징 서버의 내용을 지우고 기차 기준선으로 다시 설정한다는 것을 이해합니다. 개발자는 변경 사항이 기차에 도착했는지 확인하거나 아직 일반적인 용도로 준비가되지 않았 음을 결정합니다.이 경우 해당 변경 사항은 준비 서버에서 지워집니다.

요약하면 (적어도 우리에게는) 짧은 대답은 QA에서 복잡한 시스템을 완전히 테스트하는 것이 불가능하다는 것입니다. 스테이징은 제한된 생산 테스트를 수행하는 안전한 방법을 제공합니다.

관련 메모에, 방금 발표 프로세스의 작동 방식에 대해 발표 한 프레젠테이션의 슬라이드가 있습니다.

— 필 홀 렌백
소스

5

준비에 대한 가장 간단한 설명은 배포 프로세스를 테스트하고 실제 데이터 소스를 사용하여 테스트하는 것입니다. 일부 시스템은 스테이징을 테스트 환경과 결합하지만 대규모 시스템의 경우 배치 프로세스가 매우 복잡하거나 라이브 / 프로덕션 데이터 소스에 연결하면 추가 테스트 단계가 필요할 수 있습니다. 이러한 경우 준비 환경을 통해 배포 프로세스를 테스트하고 실시간 데이터를 사용하여 마지막 순간의 버그를 확인할 수 있습니다. 일단 작동하는 것으로 확인되면 준비 환경을 프로덕션 환경으로 빠르게 전환 할 수 있습니다.

이에 대한 예는 Windows Azure입니다. 새 버전을 배포하는 데 5-25 분이 걸리지 만 준비 환경에 배포하고 테스트를 수행 한 다음 프로덕션 환경과 준비 환경 을 즉시 교체 할 수 있습니다 .

— 그렉 브레이
소스

0

난 단지에 대한이 문서를 건너 왔어요 스테이징 환경 말한다

준비는 시스템의 알려진 미지의 유효성을 검사하는 곳입니다.

이 기사는 충분히 읽을 가치가 있습니다.

— 하 미스 다우 너
소스