지점 품질 수준에서 회귀를 보장하지 않는 CI 도구가 있습니까?

10

일반적으로 CI 시스템 은 변경 사항이 이미 커밋 된 코드베이스에서 QA 검증을 수행하여 회귀를 관찰하고 사람의 개입에 대한 알림을 보내 통합 지점의 품질 수준 만 모니터링 합니다.

그러나 이러한 회귀가 감지되면 지점은 적어도 각각의 QA 검증이 시작된 이후 이미 문제가 발생했으며 모든 범인이 식별되고 수리가 완료되고 새로운 QA 검증이 이루어질 때까지 그러한 상태를 유지합니다 (또는 악화 될 수도 있습니다). 지점 품질 수준이 복원되었음을 확인합니다. 이 기간 동안 지점은 정상적인 개발을 위해 차단 된 것으로 간주 될 수 있습니다.

이러한 회귀 발생 을 실제로 방지 할 수있는 CI 툴이 있습니까? 사전 커밋 QA 검증을 수행 하고 각 커밋으로 업데이트 된 코드베이스가 사전 커밋 QA 검증을 통과 할 때만 커밋을 허용하므로 최소 보장 지점 품질 수준?

업데이트 : 각 회귀를 탐지 할 수있는 적절한 적용 범위를 갖춘 적합한 자동화 된 QA 검증을 CI 도구에서 호출 할 수 있다고 가정합니다.

continuous-integration software-recommendation

— 댄 코닐 레스 쿠
소스

이 질문을 이해하는 올바른 방법과 자신의 답변에 대한 귀하의 권장 사항에 대해 계속 궁금합니다. "모니터링"을 "사실 후"로 바꾸고 "예방"을 "사고 방지"로 바꾸는 경우, 그와 같은 질문이 되겠습니까? 또한 차이점을 설명하기 위해 예제 시나리오를 추가 할 수 있습니까?

— Pierre.Vriens

@ Pierre.Vriens이게 더 낫습니까?

— Dan Cornilescu

6

내가 알 수있는 한 , 빌드를 중단시키는 커밋을 거부 하는 도구를 찾고 있습니다 . CI 도구는 실제로 코드를 수정하여 회귀를 막을 수는 없지만 잘못된 코드를 추가하지 못하게 할 수 있습니다 저장소에.

Atlassian에는 Git hooks에 대한 몇 가지 흥미로운 응용 프로그램이 있습니다 .

서버 측 사전 수신 후크는 코드가 엘리트 닌자 보호자와 같은 특정 조건을 충족하지 않으면 코드를 마스터로 푸시하지 못하게하여 연속 코드 통합을 특히 강력하게 보완합니다.

Git을 사용하는 경우 후크는 매우 강력하며 SVN , Mercurial 및 기타 버전 제어 시스템에 유사한 후크 가 있습니다.이를 사용하여 커밋 전 검사를 실행하는 것이 유용 할 수 있습니다.

Git 문서 에는 푸시 가 이러한 사용 사례에 쉽게 적용 할 수 있는 특정 기준 을 충족하지 않는 경우 푸시를 거부하기위한 후크 작성 페이지 가 있습니다.

그러나 많은 사람들은 커밋을 거부하는 것이 브랜치 에서 나쁜 생각 이라고 주장합니다 feature. 실제로 버그를 수정하는 대신 어떤 이유로 빌드가 중단되면 CI 시스템과 싸우는 데 시간을 낭비하고 있습니다.

온 master당신은 항상 빌드 확인 할 수 있기 때문에 지점, 그것은 깨진 병합을 거부하는 감각을 만들 수 있습니다. A의 feature지점, 당신은 것입니다 불가피하게 일을 중단하고 코드 생산에 들어가는되지 않기 때문에 지금 , 그것은 실제로는 모두 커밋 거부보다 당신을 경고하는 것이 더 의미가 있습니다.

— Aurora0001
소스

글쎄, 빌드되는 sw 이미지는 무엇이 좋지만 DOA는 예상 테스트에서 나오는가? 개발자는 빌드 한 경우에도 코드 변경 사항을 테스트 할 수 없으므로 차단 될 수 있습니다. 따라서 일반적으로 두 가지 상충되는 요구 사항의 균형을 조정하여 선택한 최소 QA 검사에 실패한 것으로 커밋 거부를 확장합니다. 프로세스를 너무 느리게하지 마십시오.

— Dan Cornilescu

풀 요청의 병합 가능 여부에 대한 특정 제한을 적용 할 수있는 풀 요청 모델이 이에 해당 할 수 있습니다. 예를 들어, 우리 회사는 Atlassian Bitbucket Server를 사용하며 풀 요청을 병합하기 전에 주어진 브랜치에 대해 최소한 N 개의 승인 및 X 개의 통과 빌드를 요구하는 옵션이 있습니다. 이것은 완전히 거부하지 않습니다. 그러나 테스트가 실패하거나 다른 시선이 코드를 아직 보지 못한 경우 우발적 인 병합을 방지합니다.

— Andy Shinn

@AndyShinn : 예, 매우 유용합니다. GitHub는 또한 보호 된 브랜치를 제공 하고 풀 요청에 대한 검사 도 제공하는데 , 이는 종종 도움이됩니다.

— Aurora0001 년

1

기능 브랜치에서 깨진 코드를 허용하는 한 가지 주장은 아직 준비가되지 않았더라도 개발자가 작업중인 코드를 리포지토리로 푸시 할 수 있다는 것입니다. 이 기능은 작업 준비가되기 전에 초기 코드 / 아키텍처 검토를 위해 다른 사람과 코드를 공유하거나 문제를 디버깅하는 데 도움이되거나 휴가를 떠난 사람이 다른 사람이 접근 할 수있는 부분적으로 부분적으로 완료된 작업을 수행하는 데 유용 할 수 있습니다. 기능 브랜치의 경우, 나는 린터와 사전 커밋 후크 같은 것을 넣을 것입니다.

— bradym

2

어떤 도구 도 회귀를 보장 할 수 없습니다. 도구를 실행하는 것보다 테스트에 훨씬 더 의존합니다. 그러나 잡히는 회귀가 통합 분기로 들어가는 것을 방지 할 수 있습니다. 커밋 전 후크를 사용하여이 작업을 수행 할 수 있지만 풀 요청 (피어 코드 검토에 이미 사용하고 있음)을 사용하는 것이 더 쉽습니다.

지점이 업스트림 (PR이 병합되는 위치)으로 최신 상태이고 테스트가 통과 된 경우 병합 후에도 계속 통과합니다. 병합 후 대상 분기의 상태는 병합 전 소스 분기의 상태와 일치합니다.

PR의 소스 분기가 대상의 최신 상태인지 여부와 통과 CI 빌드가 있는지 여부를 나타내는 것은 일반적으로 (사용되는 도구에 따라) 특히 어렵지 않습니다. 풀 요청을 병합하기위한 요구 사항 (정책에 따라 및 / 또는 소프트웨어에서 시행)으로이를 사용할 수 있습니다.

— 아드리안
소스

"지점이 PR (병합 대상)의 업스트림 상태에서 최신 상태이고 테스트가 통과 된 경우 병합 후에도 계속 통과합니다."-왜? 병합은 불연속이므로 알 수 없습니다. 충돌처럼-코드는 해결 될 때까지 빌드되지 않을 수도 있습니다. 당신은 필요 그들이 어떤 지점 병합에 통과하는 테스트 및 확인을 실행합니다. 안전하게 연주하고 싶다면 빨리 감기라고 말하고 싶습니다. 참조 apartsw.com/insights/2016/11/16/...

— 댄 Cornilescu에게

음, 그런 보증이 가능합니다. 제 대답을 확인하십시오. 아마도 회귀를 통해 분기 기준 결과 (및 오 탐지 가능성을 무시하고 기준을 비틀어 전체를 탈선시키고 인간의 개입을 요구할 수 있으므로 해결해야 함)라는 결과가 나빠질 수 있습니다. 간헐적 인 거짓 부정은 성가신 일이며 속도를 늦추지 만 처리 할 수 있습니다.

— Dan Cornilescu

회귀를 보장 할 수 없으며 탐지 된 회귀 만 보장 할 수 없습니다. 변경으로 인해 테스트에 의해 회귀가 발생하지 않으면 CI 도구가 보증 할 수없는 회귀입니다. 두 세트의 변경 사항을 병합하면 알 수없는 결과가 발생하지만 다른 방향을 병합하기 전에 기능 분기 (업스트림 병합)를 통해 변경할 수 있습니다. 소스가 대상과 최신 상태 인 경우 단순 병합 (빨리 감기)이며, 대상 상태는 병합 전의 소스 상태와 동일하므로 테스트가 이전에 통과 한 경우 이후에 전달됩니다.

— Adrian

머리카락 나누기. CI 도구는 테스트를 통해 구성하여 관심있는 회귀를 감지하고 보호 할 수 있습니다. 내가 병합에 대해 너무 주장하지 않습니다 - 내 목표는 가능한 한 그들을 방지하는 것입니다, 그들은 전체 :) 단지 문제가있어

— 댄 Cornilescu

내 요점은 그것이 보호를 제공하는 CI 도구가 아니라 테스트를 작성하는 것입니다. CI 도구는 사용자가 제공 한 테스트 이외의 보증을 제공 할 수 없습니다.

— Adrian

1

Reitveld 및 Zuul과 같은 진정한 지속적인 통합 도구는 지속적인 테스트와는 달리 사용자가 작성하는 테스트 및 코드 검토만큼 우수하지만 도움이 될 수 있습니다.

— 코드 레인저
소스

그러나 Reitveld는 CI 도구가 아닌 협업 코드 검토 도구 인 것 같습니다. 이것이 내가 본 것입니다 : github.com/rietveld-codereview/rietveld

— Dan Cornilescu at

Zuul은 실제로 관련이있는 것으로 보이며 자세히 살펴볼 것입니다.

— Dan Cornilescu

테스트는하지 않지만 게이트 키퍼 시스템 역할을하는 분기 관리의 일부 측면을 처리합니다. 게이트 키퍼 시스템은 병합을 차단하여 잘못된 코드가 들어오는 것을 방지하는 가장 좋은 방법입니다.

— coderanger

무슨 말인지 알 겠어 글쎄, 그것은 전체 코드 품질에 도움이 될 수 있지만 그 자체로는 보장하지 않습니다. 모든 QA 검증을 독립적으로 통과하는 두 가지 완벽하게 좋은 변경 사항은 지점에서 만나도 여전히 파손을 일으킬 수 있습니다.

— Dan Cornilescu

1

GitLAB을 사용하면 파이프 라인이 성공할 때만 병합을 허용하도록 프로젝트 설정에서 설정할 수 있으므로 진정한 연속 통합이 가능하며 QA를 병합 승인 목록에 추가하고 동적 환경과 결합하면 품질을 보장 할 수 있습니다 마스터로 병합하기 전에

— 대니 구센
소스

이전 병합이 완료되기 전에 2 차 병합이 품질 보증 검사를 시작하도록 허용하지 않은 경우에만 작동합니다. 그렇지 않으면 2 차 병합에 첫 번째 병합이 표시되지 않으므로 회귀의 여지가 남습니다. 다시 말해, 병합 (QA 확인 포함)은 완전히 직렬화되어야하며, 이는 대규모 팀에 적합하지 않습니다.

— Dan Cornilescu

0

ApartCI 는 회귀 방지를 위해 정확하게 설계된 CI 시스템으로, 분기 품질 수준이 평평하거나 높아집니다. 아직 베타 버전입니다.

최신 지사 품질 수준을 충족 시키거나 초과하기 위해 변경 사항이 사전에 커밋 된 다른 변경 사항과 함께 확인 된 후에 만 커밋되도록 중앙 집중식 사전 커밋 확인을 오케스트레이션합니다.

이는 종종 병렬로 수행되는 기존의 개발자 주도형 사전 커밋 검증과 비교할 때 중요한 차이점으로, 테스트를 거치지 않은 변경을 방해하여 발생하는 회귀의 여지가 남아 있습니다.

또한이 도구는 확장이 용이하도록 설계되어 매우 빠른 속도로 수신 후보 변경을 유지하고 동일한 통합 지점에서 일하는 100/1000 명의 개발자를 지원할 수 있습니다.

면책 조항 : 나는 도구의 저자이자 도구를 제공하는 회사의 설립자입니다. 광고에 사과드립니다.

— 댄 코닐 레스 쿠
소스

고지 사항을 추가하는 것이 좋지만 개인적으로 회사 나 제품을 스팸 형태로 홍보하여 질문을하고 스스로 대답하는 것이 좋습니다.

— THelper

나는 이것이 메타인지에 대한 질문을했다 : meta.devops.stackexchange.com/q/59

— THelper

SnapCI도이 작업을 수행했습니다. 삼가 고인의 명복을 빕니다.

— paul_h

@paul_h, SnapCI가 누락되지 않는 한 권장 교체 GoCD는 모두 커밋 후 확인 (SCM 폴링으로 트리거 됨)을 기반으로하므로 여전히 모니터링 전용입니다. PR 검사를 제외하고 이러한 검사가 완전히 직렬화되지 않으면 회귀 발생률 만 줄일 수 있지만 완전히 제거 할 수는 없습니다.

— Dan Cornilescu

댄, 여론 조사 안 함. 그리고 아직 트렁크 / 마스터로 통합되지 않은 단기 PR 지점 -trunkbaseddevelopment.com/game-changers/…

— paul_h