WCF 서비스를 컴파일하고 테스트하는 팀 빌드 (업그레이드 템플리트, tfs2010, msbuild)가 있습니다. 우리는 psexec과 exec 태스크를 사용하여 통합 테스트 스위트를 실행하기 전에 웹 서버에 서비스 (wix installer)를 원격 설치합니다. 그러나 때로는 야간 빌드가 컴파일 오류로 실패 할 수도 있습니다. 첫 번째 1024 바이트 만 볼 수 있으며 대부분은 CSS 스타일입니다. 긴 JIT로 인한 것일 수 있다고 생각하여 잠을 자다가 테스트를 지연 시키려고했습니다. 그러나 모든 600+ 통합 테스트가 실패합니다. 빌드 로그에서 psexec를 사용한 exec 작업은 예상대로 동기식으로 실행되고 출구 0을 반환하는 것으로 보입니다. 이제는이 문제가 왜 발생하는지 이유를 생각해 낼 수 있습니까?팀 빌드 및 psexec -> 통합 테스트 오류로 배포
이것은 TFS, msbuild 또는 psexec에만 해당하는 것 같지 않습니다. 서비스에 임시 설치, 구성 또는 코딩 문제가있는 것 같습니다. CI 및 통합 테스트의 요점은 프로세스에 대한 초기 피드백을 얻는 것이고 분명히 잘못된 것이 있습니다. 트릭은 문제를 조사하고 문제가있는 곳을 배제하는 것입니다.
Psexec은 WiX 배포가 훌륭하다고 주장하지만 그랬습니까? 모든 파일이 있습니까? 이전 버전의 설치가 제대로 제거 되었습니까? 아니면 올바르게 업그레이드 되었습니까?
모든 600 개의 테스트가 실패하지만 테스트에 적절한 스택 추적이 포함되어 있지 않습니다. 테스트 외부에서 문제를 재현 할 수 있습니까? 예를 들어, 테스트가 실패하면 수동으로 테스트를 에뮬레이션하거나 동일한 스택 추적을보기 위해 디버거를 첨부하여 기존 테스트 중 하나를 실행 할 수 있습니까? 하나의 전략은 배포를 정확하게 검증하는 하나 또는 두 개의 특정 테스트를 식별하는 것일 수 있습니다. 배포 후에 이러한 테스트를 실행하고 이러한 테스트가 실패하면 빌드를 중단 한 다음 서버를 더 심층적 인 분석을 위해 실패한 상태로 유지해야합니다. 빌드 템플리트의 사용자 정의가 필요할 수 있지만 그럴만 한 가치가있을 수 있습니다.
로깅을 WCF 서비스에 추가 할 수 있습니까? 테스트에 더 나은 로깅?
마지막으로 위에서 언급 한 CI는 초기 피드백에 관한 것입니다. 일반적인 규칙은 "무언가가 고통 스럽다면 더 자주해야합니다." 고통 점에 초점을 맞추고,이를 격리하고 반복적으로 향상시킵니다. 통증이 줄어들면 다른 통증에 집중하십시오. 귀하의 경우에는 "야간"빌드를 롤링 방식으로 실행하는 것을 고려하십시오. 주보다는 몇 번 실행하면 간헐적으로 문제가 발생할 수 있습니다.
흠 - msi 로그 파일에서 오류를보고합니다. 그러나 많은 바이너리가 bin 폴더에 없습니다 (오래된 것들은 삭제됩니다). 내가 설치를 완료하지 못한 이유를 알아야합니다. – jaspernygaard