지속적인 통합 : 어느 주파수?

저는 매번 커밋 한 후에 항상 빌드를 시작했지만이 새로운 프로젝트에서 건축가는 빈도를 "15 분마다 한 번 빌드"로 변경하도록 요청했는데 왜 이것이 좋은 이유인지 " 각 커밋에 구축 ".

우선, 몇 가지 세부 사항 :

• Objective-C (iOS 5) 프로젝트
• 개발자 10 명
• 각 빌드는 실제로 ~ 1 분이 걸리며 빌드 및 단위 테스트가 포함됩니다.
• 통합 서버는 Mac Mini이므로 컴퓨팅 성능은 실제로 문제가되지 않습니다.
  • Xkins 플러그인과 함께 Jenkins를 사용합니다.

내 주장은 커밋마다 빌드하면 다른 개발자를 너무 자주 방해하지 않고 잘못 된 것을보고 오류를 직접 수정할 수 있다는 것입니다. 또한 우리의 테스터는 이런 식으로 UT 오류로 덜 신경 쓰입니다. 그의 주장은 개발자가 "빌드 오류"메일에 의해 범람 될 것이며 (Jenkins가 첫 번째 깨진 빌드에 대해서만 메일을 보내도록 구성 할 수 있기 때문에 완전히 사실이 아님), 빈도가있을 경우 메트릭을 제대로 수행 할 수 없다는 것입니다. 빌드 수가 너무 높습니다.

그래서 이것에 대한 당신의 의견은 무엇입니까?

빨리 실패하는 것이 좋은 원칙입니다. 빌드가 깨 졌다는 것을 빨리 알면 문제가되는 커밋을 더 빨리 식별하고 빌드를 수정할 수 있습니다.

모든 커밋을 기반으로 빌드하는 것이 옳은 일입니다.

프로젝트가 그러한 시간 내에 커밋이 많은 경우 15 분마다 빌드하는 것은 의미가 없습니다. 잘못된 커밋을 추적하는 데 시간이 오래 걸리고 결정하기 어려울 수 있습니다 ( 여러 커밋이 서로 다른 상황에있는 경우도 있음) 빌드를 중단하십시오). 조용한 시간 (야간 시간)에 아무런 변경 사항이 없더라도 재구성 할 가능성이 있습니다.

빌드가 너무 자주 중단되어 문제가되는 경우, 빌드를 중단하지 않는 것의 중요성과이 문제가 발생하지 않도록하는 기술 (빈번한 페치, 댄스 체크인, 컴파일 및 실행 단위 테스트)에 팀을 다시 교육하는 것이 해답입니다. 로컬 등 ...).

아무것도 변경되지 않은 경우 15 분마다 빌드를 수행하는 데 아무런 의미가 없습니다. 그러나 젠킨스는 실패와 성공에 대해서만 전자 메일을 보내지 만 그 사이의 모든 것이 아니라 전자 메일은 실패합니다 (예 : 10 실패).

우리는 모든 커밋마다 그것을합니다. 그러나 우리는 15 분마다 리포지토리를 폴링하고 변경 사항을 확인합니다. 어쩌면 동료들이 언급 한 것일 수도 있습니다.

10 명의 개발자가 15 분마다 한 번 이상 커밋 할 것으로 예상하십니까? 그것은 오히려 높은 평가처럼 들립니다. 10 dev는 150 분마다 같은 사람이 다시 커밋하므로 2.5 시간이 걸립니다. 따라서 평균 하루에 각 개발자는 3 번 커밋합니다. 개인적으로 나는 한 번의 커밋 ~ 2 일을합니다 ... 때로는 더 때로는 적습니다.

15 분마다 메일을 보내면 개발자에게 더 많은 메일이 발송 될 것입니다. 그것은 누가 누가 빌드를 깨뜨려 서 더 많은 사람들에게 메일을 보낼지 모르기 때문입니다.

메트릭과 관련하여 실제로 문제가 있다고 생각할 수없는 문제인 경우 메트릭을 수집하기 위해 다른 작업을 수행 할 수 있습니다.

아마도 요구 사항은 " 최대 15 분마다 한 번 빌드 "입니다. 이는 커밋 활동이 매우 빈번한 프로젝트 (예 : 몇 분 내에 여러 커밋) 및 빌드 시간이 긴 프로젝트에 적합합니다. 물론 빌드가 어떻게 사용되는지에 달려 있습니다. 테스터에게는 15 분 안에 여러 빌드를 얻는 것이 다소 혼란 스러울 수 있습니다 ...

그러나 나는 아무것도 바뀌지 않으면 건축 할 감각이 없다는 것에 동의합니다.

일부 개발자는 하나의 기능 변경에 속하는 파일이 하나의 단일 원자 프로 시저에서 커밋되지 않는 방식으로 커밋을 수행하려고합니다. "물리적 커밋"으로 구성된 "논리 커밋"을 수행하는 데 2-3 분이 필요합니다. 이것은 일반적으로 개발자가 DVCS를 사용하지 않고 중앙 저장소에 직접 커밋하는 경우입니다.

이 경우 새 빌드를 시작하기 전에 마지막 커밋 후 일정 시간 동안 CI 서버가 대기하도록하는 것이 좋습니다. 그러나 15 분은 매우 높은 것으로 보이며 5 분 이하이면 충분합니다.

또는 더 나은 (!), 개발자가 한 번에 한 가지씩 만 작은 부분으로 만 작업하도록 안내하여 "기능적 완전한"물리적 커밋 만 수행하는 것이 훨씬 쉽습니다. 그런 다음 모든 커밋 후 빌드가 겉으로는 효과가 없습니다.

Jenkins가 프로젝트 또는 해당 종속성에 대한 소스 제어 커밋을 빌드하도록 설정하더라도 개발자가 소스 제어를 먼저 커밋하지 않고 아티팩트 저장소에 배치하는 것을 방해하지는 않습니다. 조정되지 않은 API 변경 또는 아티팩트 저장소에 대한 버그를 배치하는 경우 Jenkins 작업을 트리거하지 않고 빌드가 중단 될 수 있습니다. 나는 개인적 으로이 최대한 빨리 알고 싶습니다.

이상적으로는 모든 커밋과 방금 설명한 상황을 확인하는 일정에 따라 빌드하는 것이 이상적입니다. 이것은 개념 적 으로 적어도 15 분마다 한 번씩 빌드하는 것을 의미합니다 .

종속성 아티팩트 배포에서 실행하도록 Jenkins 작업을 설정하고 (Bravo를 수행하는 경우), 단위 테스트가 확실하면 (종속성을 테스트하지 않음을 의미) 예약 된 빌드를 검사 할 수 있습니다. 통합 / 기능 테스트는 Jenkins 작업의 일부가 아닙니다.

"이메일로 인한 홍수"문제에 관해서는 깨진 빌드에서 이메일이 넘치게하는 것이 좋습니다. 개발자가 설명과 함께 이메일에 응답하도록 강요하면 깨진 빌드가 다운되는 것을 볼 수 있습니다.

당신은 그들의 추론을 이해할 수 없다고 말했기 때문에 그들에게 물어봐야합니다. 그들이 원하는 것을 추측하고 구현하려고 시도하지 말고, 요청한 이유를 이해하지 않고 요청한 것을 구현하지 마십시오.

즉, 일반적인 질문에 대답하려면 사용하는 개발 철학에 달려 있습니다. 모든 커밋이 작동 할 것으로 예상되면 모든 커밋을 테스트해야합니다. 모든 푸시 가 작동해야한다는 철학으로 DVCS를 사용하는 경우 모든 푸시 를 테스트하십시오.

일반적으로 사람들에게 모르는 것을 말하고 알고있는 것을 반복하는 것이 좋습니다. 예를 들어 중복 이메일 수를 줄이려면 빌드 빈도가 아닌 이메일 설정을 조정하십시오.