테스트에 오랜 시간이 걸리면 트렁크를 안정적으로 유지하는 방법은 무엇입니까?

우리는 세 세트의 테스트 스위트를 가지고 있습니다 :

• 실행하는 데 몇 시간 밖에 걸리지 않는 "작은"제품군
• 여러 시간이 걸리는 "중간"제품군으로, 매일 밤 (매일) 실행됩니다.
• 일주일 이상 걸리는 "대형"스위트

우리는 또한 더 짧은 테스트 스위트를 보유하고 있지만 여기서는 그에 초점을 맞추지 않습니다.

현재 방법론은 트렁크에 커밋하기 전에 작은 제품군을 실행하는 것입니다. 그런 다음 중형 스위트는 매일 밤 실행되며 아침에 실패로 판명되면 어제의 커밋 중 하나를 비난하고 격리를 롤백하고 테스트를 다시 시도합니다. 야간 스위트 대신 매주 비슷한 프로세스가 대형 스위트에 대해 수행됩니다.

불행히도, 중간 스위트는 자주 실패합니다. 그것은 트렁크가 종종 불안정하다는 것을 의미하며, 수정하고 테스트 할 때 매우 성가시다. 트렁크에서 체크 아웃 할 때 안정적인지 알 수 없기 때문에 테스트가 실패하고 테스트가 실패하면 내 잘못인지 확실하지 않기 때문에 성가신 일입니다.

내 질문은, 트렁크를 항상 최고의 모양으로 유지하는 방식으로 이러한 상황을 처리하는 알려진 방법이 있습니까? 예를 들어 "야간이 지나갈 때마다 정기적으로 트렁크를 업데이트하는 특별한 사전 커밋 지점으로 커밋"합니다.

그리고 SVN과 같은 중앙 집중식 소스 제어 시스템 또는 git과 같은 분산 시스템인지 여부는 중요합니까?

나는 물건을 바꿀 수있는 능력이 제한된 주니어 개발자 인 반면, 나는이 고통을 처리 할 수있는 방법이 있는지 이해하려고 노력하고 있습니다.

불안정성의 근본 원인을 해결하는 유일한 방법은 다른 답변에서 제안한 것처럼 변경 사항이 더 격리되도록 코드를 분리하는 것입니다.

그러나 개별 개발자로서 개인적으로 작업하기 위해보다 안정적인 빌드를 원하면 비교적 쉽게 해결할 수 있습니다. 팁에서 작업하는 대신 야간 테스트 스위트를 통과 한 마지막 빌드 만 작업 트리로 가져옵니다. 각 변경에 대해 기능 분기를 작성할 수있는 경우 마지막 안정적인 빌드에서 분기하십시오.

그렇습니다. 나무는 며칠이 지났지 만 대부분의 시간은 중요하지 않습니다. 안정적인 빌드에 대해 작업을 수행하여 변경 사항이 테스트를 중단 한 것으로 확인한 다음 체크인하기 전에 최신으로 업데이트하고 정상적인 통합을 수행하십시오. 그런 다음 체크인 한 후 마지막 안정된 빌드로 다시 백업하십시오.

여전히 지저분한 통합 작업을 수행해야하지만이 방법에 대해 내가 좋아하는 것은 통합 작업을 더 편리한 시간으로 격리하고 개발이 편리하지 않을 때 안정적인 코드 기반을 제공한다는 것입니다. 내 변경이 다른 사람과 비교하여 빌드를 깨 뜨렸을 때 훨씬 더 나은 아이디어가 있습니다.

나는 당신이 이것을 피하려고 노력하고 있다는 것을 알고 있지만, 여기에서의 실제 통찰력은 코드베이스에 심각한 문제가 있다는 것을 깨닫는 것입니다. 코드가 안정되어 있는지 확인하려면 일주일이 걸리는 전체 테스트 스위트를 실행해야합니다!

이 문제를 해결하는 가장 유리한 방법은 코드 기반과 테스트를 (독립된) 하위 유닛으로 분리하는 것입니다.
이것에 큰 장점이 있습니다 :

• 이러한 각 장치에 대한 테스트는 더 빨리 실행되며 (단순히 더 적습니다) 독립 또는 다운 스트림 장치 중 하나에서 문제가 발생해도 중단되지 않습니다.
• 실패한 테스트는 특정 장치에 정확하게 표시되므로 문제의 원인을 훨씬 쉽게 찾을 수 있습니다.
• 서로 다른 유닛의 VCS 위치를 분리하여 "안정된"브랜치가 성공적으로 테스트 된 각 유닛의 최신 빌드를 선택하여 혼합 할 수 있으므로 깨진 유닛이 "안정한"버전을 불안정하게하지 않습니다. .

VCS 구조의 반대쪽 관리는 더 복잡해 지지만 전체 테스트를 위해 일주일 내내 어려움을 겪을 수 있다고 생각합니다!

"안정한"및 "개발"브랜치 전략을 어떤 형태 나 다른 형태로 사용하는 것이 여전히 권장되지만, 그 방법에 대해 여러 가지 방법이 있으며 조직에 가장 적합한 전략을 선택할 수 있습니다 (고정 버전이 각 유닛, 안정적인 브랜치 및 dev 브랜치, 기능 브랜치에 대한 별도의 리포지토리 ....)

SVN의 경우 "사전 커밋"과 같은 것을 알지 못합니다. 테스트가 실패하면 커밋 및 롤백이 발생할 가능성이 있다고 생각합니다. doc-brown이 말한 것처럼 임시 지점을 커밋하고 나중에 트렁크와 병합하는 유일한 방법입니다.

git 또는 mercurial과 같은 분산 된 것을 사용하면 가능할 것이라고 생각합니다. "테스트"저장소 및 "안정된"저장소 사용 당신은 테스트 담당자를 밀어 밤마다 테스트하고 모든 것이 잘 작동하면 테스트에서 안정으로 밀어 넣습니다. 그렇지 않으면 테스트 담당자를 롤백합니다. 테스트에서 안정적인 버전으로 푸시 할 때 버전 기록이 어떻게 보일지 확신 할 수 없지만 그렇게 할 때 깨진 롤백 된 항목을 제외 할 수 있다고 생각합니다. 약간 실험을 먼저하는 것이 가장 안전합니다.

대안은 또한 밤마다 각 사람의 지역 트렁크를 테스트하는 것입니다. 그런 다음 테스트를 통과 한 사람들은 아침에 중앙 서버로 테스트를 푸시 할 수 있습니다.

IMHO 이것은 사용중인 VCS와 아무 관련이 없습니다. "테스트 중"브랜치를 사용하는 것이 중앙 집중식 또는 분산 VCS로 구현할 수있는 솔루션 일 수 있습니다. 그러나 솔직히 말해서, 귀하의 상황에서 가장 좋은 것은 중간 테스트 스위트를 최적화하는 것입니다 (가장 중요한 테스트가 포함되어있는 것으로 간주 됨) 훨씬 더 빨리 실행되므로 사전 커미트 투 트렁크에 사용할 수 있습니다 "작은 제품군"으로 지금하는 것처럼 테스트하십시오.

실패한 매체 테스트 : 동일한 테스트가 대부분 실패하는 것이 사실입니까?

실패가있는 경우 항상 실패하는 동일한 관련 테스트가 있습니까?

참인 경우 : 자주 실패하는 중간 테스트 (모든 오류 클래스에 대해 하나의 테스트)를 선택하여 작은 세트 내에서 실행할 수 있습니다.

실제 데이터베이스를 사용하는 대부분의 테스트 통합 테스트입니까? 그렇다면 모의 데이터베이스가있는 단위 테스트로 대체 할 수 있습니까?

테스트를 더 빨리 실행해야 하며이 원을 제곱하는 다른 방법은 없습니다.

문제점을 고려하십시오. 체크 아웃 할 때 작업 코드가 있는지 확인하려고합니다. 물론, 커밋을 지연시키고 릴리스 전까지 분기를 수행 할 수 있지만 통합까지 문제의 시작 만 지연시킵니다. 마찬가지로 매 병합 후 1 주일 동안 스위트를 실행해야합니까? 방법론은 솔루션이 아니며 솔루션은 순수한 기술적입니다.

여기 내가 제안하는 것이 있습니다.

1) 가능한 한 대기 테스트를 수행하고 환경 재사용을 최대화하십시오.

2) 테스트 스위트 팜을 실행하십시오. 8 개의 큰 모듈이 아니라 50 개로 끝나는 경우 Amazon EC2 스팟 인스턴스를 스핀 업하고 전체 제품군을 병렬로 실행할 수 있습니다. 나는 이것이 약간의 비용이들 것이라 확신하지만, 개발자 시간을 크게 절약 할 것입니다.

귀하의 질문에 당연한 것으로 여겨지는 핵심 사항은 모든 커밋이 테스트를 통과해야한다는 것입니다. 이것은 따라야 할 좋은 규칙이며 의미가있는 것처럼 보이지만 때로는 실용적이지 않습니다. 귀하의 사례는 (MadKeithV가 지적하지만) VCS 지점을 유지하는 것이 개발자들 사이에 충분한 협력이 없다면 깨끗하지 못할 수 있다고 상상할 수 있습니다.

실제로 원하는 것은 어떤 커밋이 합격 또는 불합격인지를 아는 것입니다. 제안한 "커밋 전 지점"은 효과가 있지만 커밋을 할 때 개발자의 노력이 더 필요할 수 있습니다.

더 쉬운 방법은 사람들이 원하는대로 트렁크를 남겨두고 부서지지 않는 커밋을위한 분기를 갖는 것입니다. 자동화 된 스크립트는 트렁크에 커밋이 수행 될 때 커밋을 수행하고 테스트를 실행하고 통과하면 브랜치에 추가 할 수 있습니다.

또는 터무니없이 단순하고 텍스트 파일에 전달 커밋을 나열하는 스크립트가있을 수 있습니다 (자체적으로 버전이 제어 될 수도 있고 아닐 수도 있음).

또는 분기 / 수정 요청 (트리의 어느 곳에서나)에 대한 요청을 수락하고 테스트하여 통과 할 경우이를 트렁크 (또는 다른 지점)에 커밋하는 배치 시스템을 갖추십시오.