소프트웨어 테스팅 노트

출처: Continuous Delivery, Jez Humble and David Farley, 2010년, 18~19페이지

미흡한 형상관리(configuration management)로 인해 발생하는 문제 사례를 제시

1바이트가 만드는 차이

몇 년 전, 저자는 유명 소매업체를 위한 대규모 POS 시스템 작업을 하고 있었다. 그때 우리의 배포 프로세스(deployment process)가 자동화를 시작하는 초기 단계였기 때문에 일부 측면은 꽤 잘 자동화되었지만 다른 측면은 그렇지 않았다. 프로덕션 환경에서 매우 불쾌한 버그가 불쑥 나타났다. 어떤 알 수 없는 상황에서 로그의 에러 추적(error traces)이 갑자기 폭발적으로 증가한 것이다. 우리의 모든 테스트 환경에서 이 문제를 재현할 수 없었다. 성능 환경에서 로드 테스팅이나 프로덕션 실패 사례처럼 보이는 것을 시뮬레이션 하는 등의 온갖 종류의 작업을 시도했지만 이 문제를 재현할 수 없었다. 마지막으로, 여기서 기술하는 것보다 훨씬 더 많은 조사를 거친 후 우리는 두 시스템 간 다를 수 있다고 생각되는 모든 것에 대한 감사(audit)를 하기로 결정했다. 결국 애플리케이션이 의존하는 애플리케이션 서버 소프트웨어에 속하는 단일 바이너리 라이브러리가 프로덕션 환경과 테스트 환경에서 다르다는 것을 발견했다. 프로덕션에서 이 바이너리의 버전을 변경하자 문제가 사라졌다.

이 이야기의 요점은 우리가 부지런하지 않았다 거나 또는 충분히 조심하지 않았다는 것이 아니다. 심지어 시스템 감사라는 방법을 생각해 낸 우리가 정말 똑똑했다는 것도 아니다. 진짜 요점은 소프트웨어가 엄청나게 취약할 수 있다는 것이다. 이것이 수만 개의 클래스, 수천 개의 라이브러리, 외부 시스템과의 많은 통합 지점을 갖춘 상당히 큰 시스템이었다. 그러나 제3업체 바이너리 파일 버전 간의 약간의 바이트 차이로 인해 프로덕션에서 심각한 에러가 발생했다.

수동 형상관리의 비용

저자가 참여한 또 다른 프로젝트에는 수많은 전용 테스트 환경이 있었다. 각각은 잘 알려진 EJB 애플리케이션 서버를 실행했다. 이 애플리케이션이 애자일 프로젝트로 개발되었으며, 우수한 수준의 자동화된 테스트 커버리지를 달성했다. 로컬 빌드가 잘 관리되었기 때문에 개발자가 코드를 로컬에서 빠르게 실행하고 개발하는 것이 비교적 쉬웠다. 그러나 이는 애플리케이션 배포 자동화에 대해 우리가 더 주의를 기울이기 전의 일이었다. 각 테스트 환경(test environment)이 애플리케이션 서버 공급업체의 콘솔 기반 도구를 사용하여 수동으로 구성되었다. 개발자가 로컬 설치를 구성하는 데 사용한 형상 파일의 복사본은 버전 콘트롤하에 보관되었지만 각 테스트 환경의 형상은 그렇지 않았다. 이들 각각이 서로 달랐다. 속성(properties)의 순서가 다르거나, 일부는 누락되었으며, 일부는 다른 값으로 설정되고, 일부는 이름이 다르며, 일부는 다른 환경에서는 발생하지 않는 속성이 있었다. 각 테스트 환경이 모두 동일하지 않았고 프로덕션 환경과도 모두 달랐다. 어떤 속성이 필수인지, 어떤 속성이 중복되는지, 어떤 속성이 환경 간에 공통되어야 하는지, 어떤 속성이 고유해야 하는지 결정하는 것은 엄청나게 어려웠다. 결과적으로 해당 프로젝트는 이러한 다양한 환경의 형상 관리를 담당하는 5명의 팀을 고용했다.