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. The development, release, and timing of any products, features, or functionality may be subject to change or delay and 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 Housekeeper - Merge Request 자동화

요약

이 청사진은 “GitLab Housekeeper” gem 에 대한 철학을 문서화한 것입니다. 이 gem은 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/139492에서 소개되었으며 이미 여러 개의 Merge Request을 생성했습니다.

이 도구는 개발자들을 반복적이고 잡다한 작업으로부터 구해내어 자동화할 수 있는 것을 제공해야 합니다. 이 도구는 개발자가 예상할 수 있는 단순한 Merge Request을 만들어야 하는 모든 작업에 해당됩니다.

이 도구는 적어도 다음과 같은 일반적이고 잡다한 MR들에 유용해야 합니다:

  1. X 날짜 이후 피처 플래그 제거
  2. 사용하지 않는 인덱스 제거(해당 인덱스는 어떤 자동화에 의해 식별됨)
  3. X 날짜 이후 ignore_column 제거(열 이름 재설정/제거의 일부로)
  4. 샤딩 키가 없는 테이블의 조직/셀에 대한 샤딩 키 채우기

동기

우리는 개발자들이 완전히 예측 가능하고 자동화 가능한 작업을 위해 많은 매뉴얼 작업을 하는 경우가 많다고 관찰했습니다. 이러한 매뉴얼 작업은 종종 알려진 기간을 기다린 후에 수행됩니다. 따라서 보통 우리는 문제를 만들고 미래의 마일스톤을 설정합니다. 그런 다음 미래에 개발자는 그 문제를 추적하고 매뉴얼으로 변경을 가할 MR을 엽니다.

요즘 우리가 보는 가장 큰 예시들은 다음과 같습니다:

  1. 피처 플래그 제거: https://gitlab.com/groups/gitlab-org/-/epics/5325. 피처 플래그와 관련된 자동화 가능성이 많지만 이 청사진은 주로 피처 플래그가 완전히 롤아웃된 후에 그것을 제거하는 데 초점을 맞춥니다. 종종 잊혀지는 단계로 성장하는 기술 부채를 낳습니다.
  2. 포스트그레스에서 중복되거나 사용되지 않는 인덱스 제거: https://gitlab.com/gitlab-org/gitlab/-/issues/385701. 현재 우리는 이를 추적하고 매뉴얼으로 제거하기 위해 문제를 생성하고 그룹에 할당하는 자동화를 개발 중입니다. 이 청사진은 한 걸음 더 나아가 자동화가 그것을 식별한 후 인덱스를 제거하는 MR을 생성합니다.
  3. 오래된 ignore_column 참조 제거: https://docs.gitlab.com/ee/development/database/avoiding_downtime_in_migrations.html#removing-the-ignore-rule-release-m2 . 우리는 현재 우리 코드에 이를 제거해야 하는 날짜를 알려주는 메모를 남기고 종종 이를 기억해야 하는 문제를 만듭니다. 이 청사진은 자동화가 이 메모를 읽고 그 날짜 이후에 이를 제거하기 위해 MR를 열도록 제안합니다.
  4. 조직/셀에 대한 샤딩 키의 추가 및 백필: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133796. 셀 아키텍처는 모든 테이블이 조직에 속하는 샤딩 키를 가져야 한다는 것에 의존합니다. 우리는 약 300개의 테이블에 대해 이를 백필해야 합니다. 이 중 많은 부분은 반복적이고 잡다한 작업이므로, 그룹들이 샤딩 키의 이름과 그것을 어떻게 백필할 것인지를 식별할 경우 우리는 자동화를 통해 MR을 생성할 수 있습니다. 그런 다음 우리는 생성된 그 MR을 확인하고 수정할 수 있습니다. 그런 다음 우리는 열 생성과 데이터를 백필하는 MR 생성을 자동화할 수 있습니다. 이러한 형태의 자동화가 합리적인 시간 내에 작업을 완료할 수 있도록하는 데 필수적일 것입니다.

목표

  1. 개발에 소요되는 공통 작업을 식별하고 자동화합니다.
  2. 결과물로서의 MR 생성에 초점을 맞추고, 문제 생성이 아니라 MR을 위한 프로세스로 개발자들에게 필요한 것은 기억시켜주는 것입니다.
  3. 자동화가 번거로운 일을 처리하면서 우리가 도전적이고 창의적인 작업을 할 수 있도록 하여 개발자의 직무 만족도를 향상시킵니다.
  4. 개발자들은 패턴을 보았을 때 매뉴얼 작업을 문서화하는 대신 자동화 프레임워크에 기여하도록 장려받아야 합니다.
  5. 자동화 MR은 매우 쉽게 확인하고 빠르게 Merge되어야 합니다. 만약 우리의 자동화 MR이 리뷰어에게 너무 많은 노력을 요구한다면, 이를 재고해볼 필요가 있습니다. 이는 때로는 그 자동화가 시끄럽게 작용할 때 그것을 비활성화해야 한다는 것을 의미할 수 있습니다.

해결책

GitLab Housekeeper gem을 사용하여 잡다한 Merge Request의 자동생성을 해야 합니다.

이 도구를 사용함으로써 우리는 행동에 대한 편향 하위가치를 반영합니다. 따라서 개발자들은 다음을 선호해야 합니다:

  1. 시간의 경과에 따라 여러 개의 Merge Request을 만드는 프로세스를 문서화하는 것
  2. 개발자들에게 일부 Merge Request을 만드라고 정기적인 알림을 설정하는 것 (슬랙이나 문제에서)

문제를 해결하는 데에는 종종 정기적인 알림이나 문서화보다 더 많은 작업을 요구할 수 있으므로, 시간을 절약할 것으로 예상되는 경우 자동화 사용의 시간을 평가하기 위해 판단을 사용해야 합니다. gitlab-housekeeper gem은 시간이 지남에 따라 새로운 keeps를 기여하기 쉬워질 것으로 예상되므로 대부분의 경우 개발자들이 반복적인 작업을 수행해야 할 때 대부분 이를 선호할 것입니다.

설계 및 구현 세부 정보

이 아키텍처의 주요 세부 사항은 다음과 같습니다:

  1. 이 도구의 설계는 rubocop -a와 Renovate bot의 결합과 유사합니다. 특정 기한 이후에 제거해야 하는 것을 이해하는 데에서 rubocop -a를 확장하고, 결정을 개발자에게 넘기지 않고 검토 가능한 연속적이고 처리 가능한 Merge Request을 생성하는 데에서 Renovate bot과 유사합니다.
  2. keeps는 GitLab 리포지터리에 있으므로 업데이트할 의존성이 없으며, keeps는 GitLab 코드베이스 내부 코드를 사용할 수 있습니다.
  3. 이 스크립트는 개발자가 로컬에서 실행하거나 어떤 자동화된 방식으로 주기적으로 실행할 수 있습니다.
  4. keeps는 변화를 이루는 데 필요한 여러 데이터 소스(예: 로컬 코드, 프로메테우스, 포스트그레스 데이터베이스 아카이브, 로그)를 사용할 수 있습니다.