가끔 깨지는 빌드(flaky build)를 18분의 1로 줄이기
(github.blog)GitHub에서 같은 코드인데 어떤 경우에는 빌드가 깨지고 어떤 경우에는 통과하는 빌드를 flaky 빌드라고 정의하고 flaky는 해당 코드를 작성한 사람한 사람이 해결해야 하고 다른 사람한테 영향을 주지 않도록 자동화를 도입해서 flaky 빌드를 1/18로 줄였다고 한다.
GitHub 내부 CI에 flaky 빌드를 추적하고 문제 상황을 정리한 뒤에 해당 문제를 만들었을 것으로 추정되는 사람에게 할당한다.
- flaky 빌드를 추적해 보니 빈도가 달랐는데 100번 이상 실패하는 flaky 빌드는 전체의 0.4%였다. 그래서 이 0.4%에 집중하기로 했다.
- 2016년에 도입했을 때는 다음 두가지 방법으로 접근했다.
- 빌드가 끝나면 같은 커밋으로 실행된 빌드를 찾아서 결과가 다를 경우 flaky 빌드라고 표시
- 같은 빌드에서 재시도 했는데 결과가 다르면 flaky 빌드 표시
- 이 방법으로는 전체 flaky 빌드 중 25%만 구별할 수 있었다.
## 개선하기
- 3번 재실행하는 방법을 사용
1. 같은 프로세스에서 재시도한다. 이 flaky 빌드는 코드의 우연성이나 레이스 컨디션 때문에 발생한다.
2. 같은 프로세스이지만 시간이 지나서 재시도한다. 이 flaky 빌드는 시간에 관해 잘못된 가정을 했을 때 발생한다.
3. 완전히 다른 호스트에서 재시도한다. 이 flaky 빌드는 테스트 순서 의존성이나 공유 상태때문에 발생한다.
이 방법을 통해서 90%를 자동으로 탐지할 수 있게 되었다.
## 영향도 측정
우선순위를 정하기 위해 영향도를 정량화하는 방법이 필요했다.
빌드, 브랜치, 작성자, 커밋등의 정보를 이용해서 얼마나 많이 실패하고 다른 브랜치나 개발자에 영향을 주는지 영향도 점수를 매긴다.
일정 점수가 넘으면 개발자들이 수정할 수 있도록 이슈를 만들어서 개발자한테 할당한다.
저같은 경우에는 gradle의 unittest에서 flaky build 가 자주 발견되어서 아래의 솔루션들을 적용했었습니다.
* https://plugins.gradle.org/plugin/org.gradle.test-retry 플러그인을 이용하면 unittest에 대한 flaky build를 추적하는데 큰 도움이 됩니다.
* https://docs.gradle.org/current/dsl/… 을 이용하면, 일정기간 이후 새로운 프로세스에서 수행되므로 flaky build가 완화될 수 있습니다.
* gradle enterprise를 도입하면 flaky build의 추이를 쉽게 볼 수 있습니다. https://gradle.com/blog/flaky-tests/