테스트 환경에서 지속적인 통합으로 인한 불안정성을 피하는 방법은 무엇입니까?

일부 대상 환경을 자주 업데이트하는 지속적인 통합 프로세스를 사용하고 있으므로 변경 사항이있을 때마다 "변경 사항"을 즉시 테스트 할 수 있습니다. 이것이 CI 목표의 일부입니다.

그러나 테스트주기에 다른 사람 (예 : 관리자 또는 고객)이 있다고 가정합니다. 다가오는 변경 사항을 검토 (중단?)하려고 다른 사람들이 참여하도록하는 것이 합리적입니까?

그러나 다른 사람들이 심각하게 테스트를 시도하는 환경에서 지속적으로 변경 사항을 계속 제공하면 다음과 같은 여러 가지 문제가 발생할 수 있습니다.

• they (심층적 인) 보고서를 저장할 때까지는 더 이상 자체적으로 문제를 재현 할 수없는 문제를보고하는 데 시간을 낭비 할 수 있습니다 (예 : 실수로 동일한 문제가 발생하여 이미 환경에서 수정 되었기 때문에).
• you 일부 문제가 발생한 환경이 더 이상 동일하지 않기 때문에보고 된 문제를 재현하지 못할 수 있습니다 (!!!)가 해당 환경을 오버레이했을 수 있습니다).

그렇다면 그러한 실망스러운 상황을 피하기 위해 무엇을 할 수 있습니까?

나는 이것에 대해 내 경험을 줄 것이다. 주로 왜 일부 답변이 항상 적용 가능한 것은 아님을 보여주기 때문이다.

시작할 문맥 :

• 약 80 개의 응용 프로그램을 호스팅 할 수있는 7 개의 환경이 있으며 대부분 db2-iSeries의 웹 서비스 또는 공유 테이블을 통해 서로 의존합니다.
• 좋든 나쁘 든 iSeries는 DB 참조 시스템입니다.
• 이 마지막 요점은 격리 된 환경에서 앱에 의존성을 갖는 앱을 가져 오는 아이디어를 무효화합니다. 각각에 대해 AS400을 가져 오면 비용이 너무 많이 들고 어쨌든 실행할 하드웨어가 없기 때문입니다.

우리가하는 일은 완전 자동화 된 Continuous Delivery가 아니며, 일반 운영을위한 일관된 많은 응용 프로그램을 제공하기위한 릴리스 일정이 있습니다. 이 외에도 각 테스트 팀은 테스트중인 애플리케이션에 대한 Q / A 환경 중 하나에서 릴리스를 트리거 할 수 있으며 다른 팀 요청이 테스트를 중단하지 않도록 일부 애플리케이션 버전을 잠글 수 있습니다.

응용 프로그램의 종속성은 릴리스 전에 확인되므로 다른 응용 프로그램을 업데이트 할 수 없거나 필요한 종속성과 일치하지 않으면 시스템에서 무언가를 해제하지 않습니다. 주요 아이디어는 누군가에게 영향을 미치지 않을 때 업데이트를 허용하는 것이며, 계획된 테스트가없는 경우 이전 환경에서 흘러 나와야합니다 (그리고 우리는 지금 중반 5 초 환경에서 예정된 릴리스를 제거하는 것을 목표로하고 있습니다 이 '주문형'방법 시스템을 검증했습니다.)

짧은 버전은 환경의 응용 프로그램을 중심으로 '세마포'시스템을 사용하는 것이므로 팀은 수동 테스트 시간에 대상 응용 프로그램을 해당 종속성 (및 전이 종속성)으로 잠글 수 있어야합니다.
이 세마포어의 구현은 자동화 시스템에 크게 의존하므로 확장하지는 않겠습니다.

물론 쉬운 방법은 위에서 언급 한 세마포를 피하기 위해 모든 종속성이있는 응용 프로그램을위한 새로운 환경을 만드는 것입니다.

테스트 실행마다 안정적으로 다시 초기화 하지 않고 지속적으로 재사용되는 테스트 환경에 대해 이야기하는 것처럼 들립니다. 이것은 그러한 테스트를 신뢰할 수없는 것으로 만듭니다. 원하는 경우 수동 테스트로 안정성 측면에서 비슷합니다.

이럴 당신은 테스트를 사용해서는 안 내부에 효율적으로 (그 지역에서 적어도) 자격 취득 과정을 무효화과 당신의 CI / CD 자격 목적. 소프트웨어가 제공된 모든 소프트웨어 버전에 대해 실제로 테스트 X를 실행하지 않고 또는 테스트 pass결과가 우발적이지 않다고 확신하지 않고 테스트 X를 통과한다고 말하는 것은 테스트의 신뢰 수준을 손상시킵니다. 허위 부정은 신뢰성을 손상 시키지는 않지만, 불필요한 "소음"으로 인해 바람직하지 않습니다.

CI / CD 인증 프로세스 외부에서 이러한 테스트를 수행 하는 것이 좋습니다. 그러나 고객이 발견 한 버그와 같이 이러한 테스트에서 실패한 결과를 처리해야합니다. 문제를 해결하기 위해 문제를 안정적으로 재현하고 문제가 해결되었는지 확인해야합니다. 테스트가 신뢰할 수 없다면 실제로 그렇게 할 수 없습니다.

문제를 해결하려면 먼저 문제를 재현하기위한 신뢰할 수있는 자동화 된 테스트 사례를 개발하는 것이 이상적입니다. 수정 프로그램을 개발하고 유효성을 확인하는 데 사용합니다 (테스트 결과는 FAIL에서 PASS로 전환해야 함). 또한이 테스트 케이스를 CI / CD 검증 프로세스에 배치하여 원하는 경우 향후 재발을 방지하여 전반적인 소프트웨어 릴리스 품질 수준을 높일 수 있습니다.

일반적인 접근 방식은 다른 환경을 만드는 것입니다.

DEV-개발자 팀이 문제를 해결하는 곳입니다. 다음은 모든 변경 조정 작성, 새 버전 배치 등입니다. CI가 완전히 통합 된 곳입니다.

PREPROD / QA – 이곳은 "플레이"QA / 테스트 / 검증 팀이 테스트를 수행하는 곳입니다. 이 환경은 일반적으로 테스트 중에 동결됩니다. 이 환경과 CI의 통합은 새로운 버전의 제품, 구성 등을 제공하기위한 것입니다.

생산-설명이 필요합니까? :)

CI / CD를 수행하는 경우 배포 (CD) 전에 일부 자동 테스트 (CI)가 있음을 의미합니다. 테스트 환경에서 많은 문제가 발견되면 배포 전에 실행되는 테스트에서 문제가 발생하지 않는다는 의미입니다. 이것은 자동 테스트가 충분하지 않음을 나타냅니다. 개발자가 테스트 환경에서 결함이 발생하는 문제가있는 경우이를 방지하기 위해 자동화 된 테스트 스위트를 개선해야합니다. 이를 통해 생산에 이르기까지 전반적인 품질과 안정성을 향상시킬 수 있습니다.

내부적으로 환경 내에서 Romeo Ninov의 답변에 추가하려면 가능한 한 응용 프로그램을 분리하여 시도해야합니다. 이것이 부분적으로 docker가 dev / test에 대해 성공적인 이유입니다. 환경을 전혀 공유하지 않는 것으로 가장합니다.

다른 옵션은 환경을 구성하는 나머지 인프라와 분리 된 응용 프로그램이 실행되는 서버를 매우 명확하게 정의하는 것입니다. 즉. 모든 환경 관리 또는 인 에이블먼트 기계는 오래 지속되는 별도의 서버에 있습니다. 그런 다음 알려진 이미지를 기반으로 새로운 단기 서버를 연결하여 응용 프로그램을 테스트하고 기본 이미지를 변경 한 경우 모든 새 구성 요소의 모든 위치 에 해당 변경 사항을 적용해야합니다 . 이는 모든 것에 대한 변경 사항을 테스트하는 것을 의미합니다.

appdev 팀이 다른 사람의 응용 프로그램을 손상시키는 변경을 요청하면 운이 좋으면 내부적으로 코드에서 완화제를 작성하고 특정 요구 사항을 환경 제공과 분리해야합니다.