소프트웨어 빌드를 깨뜨릴 때 싫어하지 않습니까? 빌드 문제는 계획되지 않은 추가 작업을 만듭니다. 그들은 항상 다른 문제를 해결하기 위해 서두르고있을 때 발생하는 것 같습니다. 종종 빌드는 현재 수행하는 모든 요소와 관련이 없는 몇 가지 요소에 대해 중단됩니다. 따라서 수행 중인 작업을 삭제하고 빌드가 중단된 원인을 파고 그 문제를 해결하며 빌드를 다시 시작해야 하는 것이 오히려 실망스러울 수 있습니다(해결해야 할 문제가 하나뿐임).
나는 오픈 소스 패키지를 재건하면서 오늘이 문제에 부딪혔다. 몇 달 전, 우리는 버전 1.0.0에 OpenSSL의 사본을 업데이트하지만, 우리는 그것에 의존하는 모든 패키지를 다시 하지 않았다. 버그 수정을 선택하기 위해 전복 클라이언트를 다시 빌드하러 갔을 때 OpenSSL 1.0.0이 호환되지 않는 변경 사항을 도입했기 때문에 전복 빌드가 깨진 것으로 나타났습니다. 이 문제가 몇 달 전에 수정되었기 때문에 수정 사항을 찾는 데 오래 걸리지 않았으며 간단한 웹 검색에서 버그 보고서와 수정 프로그램을 모두 찾았습니다. 하지만 제품을 재건하려고 할 때이 문제에 실행하는 것은 여전히 오히려 자극적이었습니다.
나는 여기에 만들 수있는 훌륭한 제안이 없습니다. 그러나 나는 기계 시간이 지금 풍부하다는 것을 관찰을 가지고 있다. 어쩌면 우리는 단순히 매일 밤 우리의 모든 소프트웨어를 다시 구축해야합니다. 문제는 여전히 모든 사람의 마음에 신선한 때 그 빌드 문제를 잡을 것이다.
또한 빌드 프로세스에 몇 가지 수동 단계가 있는 경우 자주 다시 빌드하기로 결정하는 것이 이를 제거하는 데 좋은 인센티브가 될 것입니다. 수동 단계는 오류의 일반적인 소스입니다.
소프트웨어 테스터는 소프트웨어를 테스트한 후 재구축하는 것을 싫어하는 경향이 있습니다. 그들은 새로운 결함을 소개 할 수있는 기회로 그것을 볼 수 있습니다. 빌드 도구(컴파일러, 링커, 메이크파일)에 대한 확신을 가지고 언제든지 다시 빌드할 수 있는 것을 좋아합니다. 우리는 높은 수준의 언어로 일하고 있다는 점을 감안할 때, 우리는 우리의 빌드 도구에 대한 확신을 가져야합니다. 그러나 단계적 개발 프로세스에서 두 견해모두에 충분한 여지가 있습니다.
빌드를 위반하거나 빌드 문제를 해결하는 데 필요한 노력을 최소화하기 위해 소프트웨어 개발을 관리하는 방법에 대한 제안이 있는 경우 이 게시물에 의견을 추가하십시오.
회사