일일 빌드는 얼마나 중요합니까? [닫은]

Joel 테스트 의 기준 중 하나 는 일일 빌드입니다. 아이디어는 빌드가 망가 졌을 때 누군가가 그것을 고치기 위해 주위를 돌렸다는 것입니다. 빌드를 수정할 수 없으면 모든 사람이 이전 버전을 체크 아웃하고 작업해야합니다. 가능한 한 병합 및 분기를 피하는 것이 중요한 중앙 집중식 버전 제어에서 이것이 얼마나 나쁜지 이해할 수 있지만 분산 버전 제어에는 약간의 성가신 것 같습니다. 이것에 동의하십니까? 일일 빌드가 중요한 다른 이유가 있습니까?

여기서 주목해야 할 것은 정기적 인 빌드 가 나중에보다 빨리 오류 를 포착하는 데 도움 이된다는 것 입니다. 그것은하지 않습니다 이 자주 일일 수 있지만. 이상적으로는 단위 테스트를 실행할 수도 있습니다.

목표는 최종 테스트 단계 이전에 빌드가 중단되는시기를 찾아 가능한 빨리 찾는 것입니다.

기본 개발 지점을 구축하도록 설정하기 만하면됩니다.

우리는 직장에서 (매시간 구축하지만) 사용하며, 설정을 잊어 버릴 때 종종 몇 시간 전에 문제를 발견합니다.

이것에 (그리고 @GoodEnoughs) 비트를 추가해야합니다 :

그러나 이것은 분산 버전 제어에 약간의 성가신 것 같습니다.

"서버"빌드가하는 일은 트렁크가 깨끗한 상태에서 테스트를 어느 정도 빌드하고 통과한다는 것을 말해줍니다 (환경에서 수행해야하는 구성의 양이 적습니다).

DVCS 로의 전환을 고려하고 있지만 그렇게하더라도 냉혹 한 손에서 지속적인 통합을 끌 수 있습니다.

간단한 예를 들어-당신은 기능 "a"를 개발하고 있습니다. 그는 기능 "b"를 배포하고 있거나 어느 시점에 함께 묶어야 할 필요가 없습니다. 커밋 할 때 앱이 빌드 할 파일을 추가하는 것을 잊어 버린 경우 당신의 컴퓨터에 있지만 다른 곳은 아닙니다. 따라서 빌드를 "트렁크"로 푸시하면 Continuous Integration이 트리거되고 빌드가 실패하며 사용자가 완전히 완성되지 않은 코드를 가져 오기 전에 단계를 수행 할 수 있습니다.

여러 개발자와 함께 프로젝트를 수행하는 경우 릴리스 버전이 어디에서 제공되는지 정의 할 수 있어야합니다 (효과적인 트렁크). 이는 버전 관리의 작동 방식에 관계없이 적용됩니다.

기능 (특히 다른 사람들이 의존하는 기능)을 추가 한 경우 "실시간"으로 푸시 할 때 개발 환경 이외의 다른 곳에서 테스트를 빌드하고 통과한다는 확신을 가질 수 있습니다. 그 이상으로, 나는 빌드 서버의 빌드에서 배포합니다. "정확한"빌드를 지정하는 방식입니다. 궁극적으로 사용자가 배포 빌드를 트리거하도록하겠습니다. 그 당신이 그것의 둘레에 작업 할 수 있다는 말을 더 좋은 - 당신은 당신이 그것을 필요로 할 수없는 경우 (내가 한 찾아 누락 된 파일을 커밋 사무실에서 라운드 dev에 상자를 스크램블).

그게 다 강해? 모름-빌드 서버는 되돌려주고 싶지 않은 것들 중 하나입니다.

내가 믿는 일일 빌드는 매우 중요합니다. 다른 시간대에 분산 된 팀이있는 경우 대부분의 팀에서 '종료'인 시간을 찾는 것이 가장 좋습니다. 또한 일일 빌드에 자동화 테스트 구성 요소가 있으면 더 바람직합니다.

중앙 소스 제어 시스템 시대에는 소스 코드에서 변경 사항이있을 때 5-10 분마다 실행되는 연속 빌드를 옹호합니다. 컴파일 오류로 인해 대부분의 팀이 느려질 수 있습니다. 분산 소스 제어 시스템을 실행하는 조직의 경우 개발자가 '원시적 인'코드베이스를 직접 덜 자주 접하므로 지속적인 빌드가 필요하지 않을 수 있습니다.

이상적으로, 빌드하는 데 반나절이 걸리는 대규모 건물을 건설하지 않으면 하루에 한 번 이상 건축 할 수 있습니다. Hudson 또는 TeamCity 와 같은 지속적인 통합 서버를 설정하면 일반적으로 매시간 또는 커밋마다 빌드가 자동으로 수행되며 문제가있는 경우 알림을받습니다.

특히 빌드의 일부로 자동화 된 테스트를 실행하는 경우 오류를 조기에 포착하는 좋은 방법입니다. 한 개발자의 컴퓨터에서는 빌드가 작동하지만 저장소 나 환경에서 무언가가 생략되어 다른 곳에서는 작동하지 않는 구성 오류를 찾는 데 특히 유용합니다.

고급 통합 통합 서버를 사용하면 시간이 지남에 따라 메트릭 (예 : 코드 적용 비율, 빌드 시간, 코드 라인 등)을 추적 할 수 있습니다.

일일 빌드는 괜찮습니다. 정직하게 말하면, 요엘의 시험은 요즘 조금 오래되었다고 생각합니다.

내 의견으로는 당신은 하루 종일 지속적으로 구축하고, 단위, 시스템 및 기능 수준 테스트 사례를 실행하고, 이상적인 환경과 같은 단계에 동시에 패키징하고 배포하면서 DB 및 환경 버전 관리 메커니즘이 있는지 확인해야합니다. 예상대로 작동합니다.

빌드 또는 배포 시간이 너무 길면 물리적 또는 소프트웨어 램 디스크, 빠른 인터넷 연결, 병렬 빌드 빌드 등에서 이러한 문제 중 일부를 제거하는 것을 고려하십시오. 빌드 중단을 신속하게 식별하여 절약 할 수있는 시간은 하드웨어 비용을 상당히 빠르게 증가시킵니다. .

일일 빌드는 중요하지 않습니다. 항상 성공적인 일일 빌드 (또는 한 시간 동안 고장난 빌드 )입니다. 빌드가 70 % 중단 될 때 CI를 갖는 것은 그다지 유용하지 않습니다. 문제가 대부분 중단되면 오류를 식별하는 데 도움이되지 않기 때문입니다.

스테이징 서버에 매일 빌드, 테스트 및 배포해야한다고 생각합니다.

'일일 빌드'의 아이디어는 테스터와 프로젝트 관리자가 실행할 수있는 무언가를 항상 준비하여 모든 사람이 프로젝트의 실제 상태를 알 수 있도록하는 것입니다.

과거 '데일리 빌드'이후 데스크톱 앱의 경우 테스터 또는 프로젝트 관리자가 즉시 앱을 실행할 수 있으므로 배포 단계를 언급 할 필요가 없었습니다.