스크럼과 안정적인 개발이 모순을 형성합니까?

저는 5 명의 팀과 총 약 40 명의 개발자로 구성된 개발 그룹의 일원입니다. 3 주 스프린트로 스크럼 방법론을 따르고 있습니다. 지속적인 통합 설정 (Jenkins)이 있으며 빌드 자동화는 몇 시간이 소요됩니다 (광범위한 자동화 테스트로 인해). 기본적으로 개발 프로세스가 잘 작동합니다.

그러나 새로운 스프린트로 며칠이 지나면 빌드가 불안정 해지고 스프린트 엔드 "커밋 중지"까지 흔들리는 경우가 많습니다. 이것의 부정적인 영향은 파이프 라인보다 훨씬 낮은 빌드 단계, 특히 UI / 웹 테스트는 며칠 동안 실행 되지 않는 것입니다 ( '녹색'빌드에서만 트리거되기 때문). 결과적으로 새로 도입 된 버그는 종종 스프린트에서 매우 늦게 감지됩니다.

• 각 커밋은 기본 테스트 세트에 대해 검증됩니다. 확인되면 코드 검토 (Gerrit) 후 변경 사항이 마스터로 푸시됩니다.
• 기본 단위 테스트는 30 분마다 실행되며 지속 시간은 10 분 미만입니다.
• 통합 테스트는 2 시간마다, 지속 시간은 1 시간입니다.
• 성공적인 통합 테스트에서 몇 시간 동안 UI / Webtest 실행

스프린트 동안 빌드 안정성을 담당하는 사람 (스프린트 당 책임이 전달됨)에 따라 빌드를 다시 안정시키기 위해 중간의 임시 "커밋 중지"가있을 수 있습니다.

그래서 우리는 원합니다 :

1. 스프린트 동안 방해받지 않고 변화를 개발하고 커밋하기 위해 개발팀
2. 후속 빌드 결과가 거의 의미가 없으므로 빌드 단계가 실패하면 빌드 프로세스를 포기합니다.
3. 개발자에게 적시에 피드백을 제공하기위한 빌드 프로세스

(2)가 주어지면 (1)과 (3)은 서로 모순되는 것 같습니다. 누구든지 이것을 다루는 좋은 습관이 있습니까?

( 우리는 현재 풀리고있는 지점 (2)이며 실패한 빌드 단계에서도 빌드를 계속할 수 있습니다. 아직 품질에 영향을 미치는 피드백은 없습니다. )

고마워, 사이먼

몇 가지 기본 원칙이 먼저 있습니다.-주요 변경 사항은 항상 VCS의 기능 분기에 있어야합니다.-기능 분기는 트렁크에 병합하기 전에 모든 테스트를 통과해야합니다 . 추가 -커밋은 항상 빌드 해야 함 -깨진 빌드 는 커미터 및 / 또는 나머지 팀의 즉각적인 조치가 필요 합니다 . -실패한 테스트는 중요한 테스트 인 경우 나머지 테스트 만 중단해야합니다 .

팀이 이러한 관행을 따르고이를 수행하는 경우 (예 : 빌드가 중단 될 때 "이름 및 부끄러움") 빌드를 중단 할 수있는 커밋이 기능 분기에 있기 때문에 진행하는 것이 좋습니다. 빌드를 중단시키는 다른 커밋은 즉시 해결되어야하며 다운 스트림 테스트 결과를 얻게됩니다.

또한 아침에 가장 먼저보고하는 야간 실행으로 UI / 웹 테스트를 위해 최신 "성공한"빌드 (통합 테스트를 통과 할 필요 는 없음)의 자동 테스트를 추가 할 수도 있습니다 .

스크럼과는 아무런 관련이 없습니다. 빌드는 항상 안정적입니다.

로컬 빌드를 수행하지 않고 유닛 테스트를 로컬로 실행하지 않는 한 아무도 체크인하지 않아야합니다 (물론 둘 다 통과). 로컬 빌드 및 테스트 프로세스는 수정에 민감해야하며 변경되지 않은 코드 테스트는 건너 뛸 수 있습니다.

빌드가 실패하거나 단위 테스트가 실패하는 원인이있는 사람은 공개적으로 수치심을 가져야합니다 . 빌드가 손상된 경우 즉시 수정해야합니다.

문제는 테스트를 실행하는 데 시간이 너무 오래 걸린 것 같습니다. 다행히 무어의 법칙은 우리에게 그 문제에 대한 해결책을 제공했습니다. 오늘날, 고급 서버 CPU에는 10 개 이상의 코어 (및 10 개 이상의 HyperThread)가있을 수 있습니다. 단일 컴퓨터에 이러한 CPU가 여러 개있을 수 있습니다.

이 테스트에 오랜 시간이 걸린다면 더 많은 하드웨어로 문제를 해결할 것입니다. 고급 서버를 구입 한 다음 테스트를 병렬화하여 테스트에서 모든 CPU 코어를 완전히 활용합니다. 테스트가 오늘날 단일 스레드 인 경우 10 개의 코어와 10 개의 HyperThred를 활용하면 테스트가 15 배 빠르게 실행됩니다. 물론 이는 15 배의 메모리를 사용하므로 컴퓨터에 충분한 RAM이 있어야합니다.

따라서 몇 시간은 10-30 분으로 바뀝니다.

빌드에 시간이 얼마나 걸리지는 않았지만 make와 같은 표준 빌드 도구는 빌드도 병렬화 할 수 있습니다. 단위 테스트를 병렬화하고 일반 개발자 컴퓨터에 4 개의 코어와 4 개의 하이퍼 스레드가 있으면 10 분 미만의 단위 테스트가 2 분 미만으로 바뀝니다. 그렇다면 커밋하기 전에 모두가 단위 테스트를 실행해야한다는 정책을 시행 할 수 있습니까?

테스트 실패 추가 테스트 중지 : 빌드 서버에서 수행하지 마십시오! 실패에 대해 가능한 한 많은 정보를 원하며, 추가 테스트를 통해 중요한 것이 드러날 수 있습니다. 물론 빌드 자체가 실패하면 단위 테스트를 실행할 수 없습니다. 개발자가 자신의 컴퓨터에서 단위 테스트를 실행하는 경우 첫 번째 실패에서 중단 할 수 있습니다.

Scrum과 문제 사이에 관련이 없습니다. 문제는 모든 개발 프로세스에서 실제로 발생할 수 있습니다.

Jenkins를 더 많이 설치하고 개발자가 별도의 Jenkins 인스턴스를 확인하도록 할 수 없습니까?

여기서 가장 좋은 해결책은 코드가 마스터 분기로 체크인되고 기본 Jenkins 인스턴스에서 컴파일 / 테스트되기 전에 모든 테스트를 통과하는 것입니다. 사람들이 빌드를 방해하는 코드를 체크인하지 못하게하십시오.

코드를 개발 브랜치에서 확인하고 테스트를 통과했는지 확인하고 풀 요청을 만듭니다. 그러나 젠킨스가 기능 분기를 가져 와서 테스트 할 수는 있습니다.

포인트 (2)가 가장 고통스러운 포인트 인 것 같습니다. 그래서 나는 그것에 집중할 것입니다.

프로젝트를 여러 모듈로 나눌 때가되었을 것입니다.

https://ko.wikipedia.org/wiki/Dependency_inversion_principle

A. 높은 수준의 모듈은 낮은 수준의 모듈에 의존해서는 안됩니다. 둘 다 추상화에 의존해야합니다.

B. 추상화는 세부 사항에 의존해서는 안됩니다. 세부 사항은 추상화에 따라 달라집니다.

한 모듈이 빌드에 실패하면 다른 모듈이 인터페이스에 의존 할 수 있고 해당 인터페이스를 구성하는 코드가 성공적으로 빌드 된 한 다른 모듈의 빌드를 계속할 수 있습니다.

그러면 다른 빌드 실패가 발생할 수있는 것에 대한 피드백이 제공되므로 다음 빌드가 발생하기 전에 둘 이상의 손상된 모듈을 수정할 시간이 있습니다.

일반적으로 SOLID 원칙은 라이브러리를 다루고 문제를 구축하기 위해 고안되었습니다. 다시 말해,이 원칙들은 당신이 직면하고있는 정확한 종류의 문제를 해결하기 위해 고안되었습니다.

참고로 (유지 스트의 답변 참조) 빌드를 별도의 모듈로 분할하지 않으면 빌드를 더 빨리 (병렬화) 실행할 수 없습니다.

팀에 스크럼의 핵심 원칙 중 하나 인 완성 된 소프트웨어가 누락 된 것 같습니다. 팀이 설정 한 완료 정의를 통과 할 때까지 PBI가 완료된 것으로 표시되어서는 안됩니다. 완료의 정의는 팀마다 다르지만 다음과 같은 내용이 포함될 수 있습니다.

• 코드에는 단위 테스트가 있습니다
• 자동화 된 빌드의 일부로 단위 테스트 통과
• 코드가 메인으로 병합되었으며 충돌이 해결되었습니다.
• 기타

따라서 기본적으로 일어나고있는 일은 팀이 실제로 수행 하지 않은 작업 을 표시하고 있다는 것입니다. 그것은 그 자체의 문제입니다.

그 외에는 적절한 버전 관리 관리로 귀결됩니다. Git을 사용하는 경우 모든 작업은 개발자의 로컬 저장소에서 수행되며 "완료"되어 잠재적으로 릴리스 할 수없는 경우 원격으로 아무 것도 밀어서는 안됩니다. 불완전한 작업을 주 저장소로 푸시해서는 안됩니다. 개발자가 더 오래 사용 된 기능 분기에서 작업해야하고 작업을 잃지 않도록 원격으로 푸시하려는 경우 포크에서 작업해야합니다. 그러면 포크를 메인에 병합합니다 기능은 "완료"되었으며 잠재적으로 릴리스 가능합니다.

TFVC의 경우 모든 것이 "원격"에서 발생하기 때문에 약간 더 복잡합니다. 즉, 빠른 수정이 아니라면 개발자는 항상 지점에서 작업해야합니다. 그러나 불완전한 소프트웨어는 커밋되지 않습니다. 기간. 올바르게 관리되는 버전 관리에서 "main"은 항상 해제 가능해야합니다. borks가 "main"이라는 커밋이 이루어 졌다면 제대로하지 않은 것입니다.