얼쑤의 Android QA 페이지에서는 테스트할 앱 설치 파일인 APK를 고를 수 있습니다. 목록에는 파일을 만든 빌드와 연결된 변경 요청(MR)의 제목과 작성자가 함께 나옵니다. 제목이 비어 있어도 보관된 파일은 내려받을 수 있었지만, 테스터는 어떤 변경이 들어간 빌드인지 목록에서 확인하기 어려웠습니다. 11월 9일 첫 점검에서는 목록에 연결된 MR 136개 중 37개의 상세 정보가 비어 있었습니다.

설치 파일과 설명이 오는 길

Jenkins는 빌드한 APK를 보관하고 어떤 변경 요청과 연결되는지 목록에 남깁니다. 별도의 동기화 작업은 이 목록에 있는 MR 번호로 GitLab을 조회해 제목과 작성자를 채웁니다. APK는 이미 보관된 파일이어서 이 조회가 실패해도 다운로드할 수 있습니다. 빈 제목을 고치려면 APK를 다시 만드는 대신, 설명을 채우는 작업을 확인해야 했습니다.

조사 때 시도한 조회관측한 결과
MR 100개를 한 요청으로 조회HTTP 502가 돌아왔습니다.
MR 99개를 한 요청으로 조회응답이 성공했습니다.
MR 136개를 50개, 50개, 36개로 나누어 조회136개의 상세 정보를 모두 읽었습니다.

이 비교에서 확인한 것은 작은 묶음으로 나누면 당시 필요한 정보를 모두 읽을 수 있었다는 점입니다. 100개를 넘기면 언제나 실패한다거나, GitLab 내부에서 어떤 원인으로 502가 발생했다는 결론까지 내릴 수는 없었습니다.

운영에서 최대 10개씩 조회했습니다

실제 동기화 작업은 한 번에 최대 10개씩 요청하도록 바꿨습니다. 요청 횟수는 늘지만 한 요청이 맡는 항목은 줄어듭니다. 모든 응답에서 요청한 MR의 제목과 작성자가 있는지 확인한 뒤 목록을 한 번에 바꾸는 동작은 유지했습니다. 중간 묶음에서 오류가 나면 기존 목록으로 계속 설치 파일을 찾을 수 있습니다. 조회가 끝난 뒤에는 목록을 다시 읽어, 조회 중 새로 올라온 빌드도 보존합니다.

후속 운영 확인에서는 목록의 MR 138개를 14번에 나눠 읽었습니다. 그때 빠져 있던 상세 정보 39개를 채웠고, 138개 모두 제목과 작성자가 있는지와 다음 예약 실행이 성공했는지 확인했습니다. 최초 조사와 복구 확인의 숫자는 서로 다른 시점의 목록을 센 값입니다.