This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
implemented @DylanGriffith @None @rymai @tigerwnz devops tenant scale 2023-10-18

GitLab 하우스키퍼 - 병합 요청 자동화

요약

이 설계안은 “GitLab Housekeeper” gem 에 관한 철학을 문서화합니다. 이 gem은 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/139492에 소개되었으며 이미 많은 병합 요청을 생성하는 데 사용되었습니다.

이 도구는 자동화될 수 있는 단조롭고 반복적인 작업에서 개발자들을 구해야 합니다. 이 도구는 개발자가 앞으로 알고 있어야 하는 간단한 병합 요청을 작성해야 하는 모든 작업에 적용됩니다.

이 도구는 최소한으로 다음과 같은 일반적인 단조로운 병합 요청에 유용해야 합니다:

  1. 특정 날짜 이후에 기능 플래그 삭제
  2. 사용되지 않는 인덱스 삭제(사용되지 않는 인덱스는 일부 자동화에 의해 식별됨)
  3. ignore_column을 특정 날짜 이후(열 이름 변경/제거의 일부 프로세스)에 삭제
  4. 조직/셀의 샤딩 키에 대한 테이블에서 셔딩 키를 누락한 경우 셔딩 키 채우기

동기

우리는 개발자들이 완전히 예측 가능하고 자동화할 수 있는 작업을 위해 많은 수동 작업을 하는 경우가 많다는 것을 관찰했습니다. 이러한 수동 작업은 종종 알려진 기간을 기다린 후에 수행됩니다. 일반적으로 우리는 이슈를 작성하고 미래 마일스톤을 설정합니다. 그런 다음 미래에 개발자들은 그 이슈를 따르기로 기억하고 수동 변경을 위해 MR을 엽니다.

최근 우리가 보았던 가장 큰 예는 다음과 같습니다:

  1. 플래그 삭제: https://gitlab.com/groups/gitlab-org/-/epics/5325. 우리는 기능 플래그를 자동화하는 많은 기회를 가지고 있지만, 이 설계안은 주로 플래그가 완전히 롤아웃된 후 플래그를 제거하는 데 초점을 맞추고 있습니다. 종종 기술적 부채가 증가하게 되는 잊혀진 단계입니다.
  2. Postgres에서 중복되거나 사용되지 않는 인덱스 삭제: https://gitlab.com/gitlab-org/gitlab/-/issues/385701. 현재 우리는 이슈를 생성하고 그룹에 할당하여 수동으로 MR을 열도록 자동화를 개발 중입니다. 이 설계안은 한걸음 더 나아가, 식별된 후 이를 삭제하기 위해 자동화가 MR을 생성할 것입니다.
  3. 오래된 ignore_column 참조 삭제: https://docs.gitlab.com/ee/development/database/avoiding_downtime_in_migrations.html#removing-the-ignore-rule-release-m2. 현재로서는 코드에 이것을 제거해야 하는 날짜를 알리는 메모를 남기고 종종 이를 기억하기 위한 이슈를 작성합니다. 이 설계안은 자동화가 이 메모를 읽고 날짜 이후에 이를 제거하기 위해 MR을 열도록 제안합니다.
  4. 조직/셀을 위한 sharding 키 추가 및 백필링: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133796. 셀 아키텍처는 모든 테이블이 조직에 속한 샤딩 키를 가져야 함에 따라 우리는 ~300개의 테이블에 대해 이를 백필링해야 합니다. 이는 우리가 자동화로 수행할 수 있는 반복적이고 단조로운 작업이 많을 것이며, 그룹들이 샤딩 키의 이름과 그것을 어떻게 백필링할지를 식별하기만 하면 자동으로 MR을 생성할 수 있습니다. 따라서 책임 그룹이 이 MR을 확인하고 수정할 수 있도록 자동으로 샤딩 키를 추측하고 열거나 데이터를 백필링하는 MR을 생성할 수 있습니다. 이러한 자동화가 이 작업을 합리적인 시간 내에 완료하는 데 필요할 것입니다.

목표

  1. 개발 시간이 소요되는 일반적인 작업을 식별하고 자동화합니다.
  2. 이슈 생성보다는 MR 생성에 집중합니다. MR은 우리가 원하는 결과이고, 이슈는 그 결과를 얻기 위한 프로세스입니다.
  3. 자동화가 번거로운 작업을 수행하는 동안, 우리는 도전적이고 창의적인 작업을 할 수 있다는 것을 개발자들에게 잘 알려줍니다.
  4. 개발자들은 패턴을 발견하면 수동 작업을 문서화하는 대신에 자동화 프레임워크에 기여할 것을 권장받아야 합니다.
  5. 자동화 MR은 매우 쉽게 식별되고 신속하게 검토되며 다른 MR보다 훨씬 빨리 병합되어야 합니다. 우리의 자동화 MR이 리뷰어들에게 너무 많은 노력을 요구한다면 이 이득이 상쇄될 것입니다. 이것은 일부 자동화가 시끄러울 때 비활성화될 수도 있음을 의미합니다.

솔루션

“GitLab Housekeeper” gem은 단조로운 병합 요청의 자동 생성을 위해 사용되어야 합니다.

이 도구 사용은 우리의 bias for action 하위 가치를 반영합니다. 따라서 개발자들은 다음보다는 새로운 keep를 기여하는 것을 우선시해야 합니다:

  1. 시간이 지남에 따라 여러 병합 요청을 생성하는 프로세스 문서화
  2. 개발자들에게 주기적으로 (슬랙이나 이슈에서) 어떤 병합 요청을 생성하도록 하는 작업 설정

문서화 또는 알림 설정보다 keep를 구현하는 데 더 많은 작업이 필요할 수 있으므로 자동화를 사용하면 시간을 절약할 가능성을 평가하기 위해 판단이 필요합니다. gitlab-housekeeper gem은 시간이 지남에 따라 새로운 keep를 기여할 수 있는 것들을 간단하게 만드는 많은 유틸리티와 함께 진화할 것이며, 개발자들이 몇 번 이상 반복할 작업이 필요할 때 대부분 우리는 이것을 선호할 것으로 예상됩니다.

디자인 및 구현 세부사항

이 아키텍처의 주요 세부 내용은 다음과 같습니다.

  1. 이 도구의 디자인은 rubocop -a와 Renovate bot의 결합과 유사합니다. 이는 rubocop -a를 확장하여 특정 마감 기한 이후에 제거해아 할 사항을 이해하고, 리뷰어가 결정하는 대신 개발자에게 남겨두지 않고, 관리 가능한 병합 요청의 지속적인 스트림을 생성하려고 합니다. Renovate bot과 유사하게 정기적으로 MR(Merge Request)을 생성하고 올바른 사람에게 리뷰를 할당하려고 합니다.
  2. keeps는 GitLab 리포지토리에 저장되어 있으므로 업데이트할 종속성이 없으며 keeps는 GitLab 코드베이스 내부의 코드를 사용할 수 있습니다.
  3. 이 스크립트는 개발자가 로컬에서 실행하거나 정기적으로 자동화된 방식으로 실행될 수 있습니다.
  4. keeps는 변경을 하는 방법과 변경이 필요한지를 결정하기 위해 필요한 모든 데이터 원본(예: 로컬 코드, Prometheus, Postgres 데이터베이스 아카이브, 로그)을 사용할 수 있습니다.