Verify 단계 코드베이스에 기여하기

Verify에서 무엇을 작업하고 있나요?

Verify 단계는 GitLab 제품에 통합된 포괄적인 지속적 통합 플랫폼을 개발하고 있습니다. 우리의 목표는 사용자가 만든 가정을 검증하고 CI/CD 구성에서 정의된 기준에 따라 그것을 확인하여 훌륭한 기술 및 비즈니스 결정을 내릴 수 있도록 하기 위한 빠르고 안정적이며 안전한 플랫폼을 제공하는 것입니다. 이는 유닛 테스트, 엔드 투 엔드 테스트, 벤치마킹, 성능 유효성 검사, 코드 커버리지 강제 등이 될 수 있습니다.

GitLab CI/CD의 피드백을 통해 사용자들은 성공을 거둘 수 있는 기술 및 비즈니스 선택에 대해 잘 알림받을 수 있습니다. 지속적 통합이 미션 크리티컬 제품인 이유는 무엇인가요?

GitLab CI/CD는 사용자 및 고객에게 피드백을 제공하는 플랫폼입니다.

사용자들은 지속적 통합 구성 파일 .gitlab-ci.yml을 기여하여 CI/CD 구성에서 질문에 대한 답변을 얻고자 합니다. 매번 누군가가 커밋을 푸시하거나 파이프라인을 트리거할 때 우리는 CI/CD 구성에서 제기된 매우 중요한 질문에 대한 답을 찾아야 합니다.

이러한 질문에 대한 답을 찾지 못한다면 또는 더 나쁜 경우에는 잘못된 답변을 제공한다면 사용자는 잘못된 결정을 내릴 수 있습니다. 이러한 잘못된 결정은 매우 심각한 결과를 초래할 수 있습니다.

우리 CI/CD 플랫폼의 핵심 원칙

플랫폼이 생산하는 데이터는 다음과 같아야 합니다:

  1. 정확해야 합니다.
  2. 안정적이어야 합니다.
  3. 접근 가능해야 합니다.

플랫폼 자체는 다음과 같아야 합니다:

  1. 신뢰할 수 있어야 합니다.
  2. 안전해야 합니다.
  3. 결정론적이어야 합니다.
  4. 신뢰할 수 있는해야 합니다.
  5. 빠르고야 합니다.
  6. 간단해야 합니다.

GitLab CI/CD가 처음부터 이러한 원칙을 살펴본 데에서 이러한 원칙을 지키며 사용자들에게 잘 수행되고 있습니다. 이러한 원칙의 몇 가지 예시는 다음과 같습니다:

  • GitLab CI/CD의 피드백과 플랫폼이 생산하는 데이터는 정확해야 합니다. 작업이 실패하고 성공적으로 완료되었다고 사용자에게 알리면 심각한 부정적 결과를 초래할 수 있습니다.
  • 피드백은 사용자가 필요로 할 때 이용 가능해야 하고, 엔지니어가 필요로 할 때 데이터가 예기치 않게 사라지지 않아야 합니다.
  • 플랫폼이 안전하지 않고 자격 증명이나 비밀이 유출된다면 위험합니다.
  • 사용자가 CI/CD 구성 형태로 선행 조건을 제공할 때 결과는 각 파이프라인 실행마다 결정론적이어야 합니다. 그렇지 않으면 플랫폼은 신뢰할 수 없게 될 수 있습니다.
  • 빠르고 간단하며 사용자 경험이 우수하다면 사용자들에게 잘 수행될 것입니다.

Verify에서 무언가를 개발하는 방법

최적화하기 전에 측정하고 데이터 기반 결정하기

측정할 수 없는 것을 최적화하는 것은 매우 어렵습니다. 성공한 지를 어떻게 알 수 있으며, 그 성공이 어떻게 중요한지를 어떻게 알 수 있을까요? 성능 또는 신뢰성을 개선하는 경우, 최적화하기 전에 측정하세요.

무언가를 측정하는 가장 좋은 방법은 Prometheus 메트릭을 추가하는 것입니다. 카운터, 게이지 및 히스토그램이 빠르게 근사 결과를 얻는 좋은 방법입니다. 불행하게도 이는 꼬리 지연을 측정하기에는 최적의 방법은 아닙니다. Prometheus 메트릭, 특히 히스토그램은 보통 근사값입니다.

굼뱅이 지연 시간과 같이 얼마나 느릴 수 있는지 또는 요청 페이로드가 얼마나 큰지 측정해야 하는 경우, 사용자 정의 응용 프로그램 로그를 추가하고 항상 구조화된 로깅을 사용하는 것이 유용합니다.

코드 실행 경로가 실제로 어떻게 보이는지 이해하기 위해 프로파일링과 플레임그래프를 사용하는 것이 유용합니다!

간단한 해결책을 추구하고, 간결한 해결책을 피하세요

가끔은 더 빨리 무언가를 제공하기 위해 간결한 해결책을 사용하는 것이 유혹적일 수 있습니다. 우리는 간결한 코드를 배포하는 것을 피하고자 합니다, 왜냐하면 보통 장기적으로 더 어렵게 이해하고 유지보수하기 때문입니다. 대신에 코드베이스를 발전시키고 기여 장벽을 낮추는 데 도움을 주는 지루한 해결책에 집중하고자 합니다. 가능한 간단한 해결책을 찾고자 합니다.

지루한 해결책을 쉬운 해결책으로 혼동하지 마세요

지루한 해결책은 때로는 쉬운 해결책과 혼동될 수 있습니다. 매우 자주 반대인 경우가 있습니다. 쉬운 해결책이 간단하지 않을 수 있습니다. 예를 들어, 아주 작은 기능을 추가하기 위해 복잡한 새 라이브러리를 포함하는 것은 이 기능을 빠르게 구현하는 것보다 라이브러리를 포함하는 것이 더 쉽지만 제품에 많은 복잡성을 가져올 것입니다.

반면에, 간단하고 잘 테스트되고 유지된 라이브러리가 있는 경우에는 과도하게 엔지니어링된 해결책이 가능합니다. 그 경우에는 해당 라이브러리를 사용하는 것이 합리적일 수 있습니다. 우리는 계속해서 간단하고 쉬운 해결책을 균형있게 유지하고 적절한 균형을 찾는 것이 중요하다는 것을 인지합니다.

“간단함”은 “유연함”과 상반되는 것이 아닙니다

간단한 것을 구축하는 것은 더 고급 및 유연한 해결책을 사용할 수 없음을 의미하지 않습니다. 여기에 좋은 예가 있습니다. .gitlab-ci.yml 구성의 복잡성이 증가하는 것입니다. 예를 들어, 환경 이름을 정의하기 위한 간단한 방법을 사용할 수 있습니다: 

deploy:
  environment: production
  script: cap deploy

하지만 environment 키워드는 더 많은 유연성을 제공할 수 있는 레벨의 구성으로 확장될 수 있습니다. 

deploy:
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://prod.example.com
  script: cap deploy

이러한 접근법은 새로운 사용자들이 플랫폼의 복잡성을 가려주면서 필요한 경우 더 깊이 들어갈 수 있게 합니다. 이러한 접근 방식은 다른 기술적 구현에도 적용할 수 있습니다.

상태 관찰 가능하게 만들기

GitLab은 DevOps 플랫폼입니다. 우리는 회사가 더 효율적이고 더 나은 결과를 달성할 수 있도록 DevOps를 널리 알리고 있습니다. DevOps 문화의 중요한 구성 요소 중 하나는 구축 중인 기능 및 코드에 대해 소유권을 갖는 것입니다. 그러나 제품이나 코드가 프로덕션 환경에서 어떻게 동작하고 어떻게 성과를 내는지 알지 못하면 이를 달성하기가 매우 어렵습니다.

이것이 우리가 기능과 코드를 관찰할 수 있도록 만들고 싶은 이유입니다. 이는 저자가 프로덕션 환경에서 기능 또는 코드의 동작이 얼마나 잘 또는 얼마나 나쁘게 되는지 이해할 수 있도록 작성되어야 합니다. 보통 이는 Prometheus 메트릭과 애플리케이션 로거의 적절한 조합을 도입함으로써 달성합니다.

TODO Prometheus 메트릭을 사용할 때와 로거를 사용할 때를 문서화하세요. 히스토그램과 카운터에 대해 몇 문장을 작성하세요. 점진적인 롤아웃 시 메트릭의 중요성을 강조하는 몇 문장을 작성하세요.

고객 데이터 보호

저희의 CI/CD 플랫폼에서 생성된 데이터를 영구화하는 것은 중요합니다. 사용자 및 고객에 의해 생성된 데이터가 중요하며 보호해야 할 필수적인 자산이라고 인식합니다. 이 데이터는 중요한 정보를 포함할 수 있기 때문뿐만 아니라 규정 준수 및 감사 책임이 있기 때문에 보호해야 합니다.

따라서 우리는 데이터베이스에서 데이터를 영구적으로 제거하는 마이그레이션을 작성하거나 새로운 보존 정책을 정의할 때 추가 주의를 기울여야 합니다.

일반적인 규칙으로는 데이터베이스, 파일 시스템 또는 객체 저장소에서 데이터를 제거하는 코드를 작성할 때 다른 사람의 눈을 더욱 신중하게 받아야 합니다. 새로운 보존 정책을 정의할 때에는 PM(PM, Project Manager) 및 EM(EM, Engineering Manager)들과 두 번 확인해야 합니다.

디자인 검토 받기

파이프라인 처리 및 CI/CD 상태 전환을 위한 서브시스템을 설계할 때, 가능한 빨리 Verify 유지관리자(@gitlab-org/maintainers/cicd-verify)로부터 설계에 대한 추가 의견을 요청하고 다른 사람들로 하여금 동일한 요청의 책임을 져야 합니다. Verify 유지관리자에 의해 설계를 검토받는 것은 가능한 빨리 간과한 사각지대를 식별할 수 있고 더 나은 해결책으로 이어질 가능성이 있습니다.

개발 작업이 시작되기 전에 디자인을 검토받는다면, 이는 또한 병합 요청 검토를 더 효율적으로 만들 수 있습니다. 디자인이 Verify 유지관리자에 의해 검토되었다면, 유지관리자 검토 중에 크게 다른 의견이나 변경 요청을 만날 가능성이 적을 것입니다. 이로써 병합 요청을 더 빨리 병합할 수 있을 것입니다.

변경 사항 검토 받기

병합 요청이 검토를 받을 준비가 되었다면 리뷰어 및 유지관리자를 지정하고 있어야 합니다. 변경의 복잡성에 따라, 당신이 변경하려는 코드 범위에 대해 가장 많은 지식을 가진 사람들을 관련시키기를 원할 것입니다. 우리에는 Verify 영역의 많은 도메인 전문가 및 유지관리자가 있으며, 해당 변경에 대한 리뷰어 룰렛이 지정한 리뷰어 또는 유지관리자가 해당 변경에 대한 충분한 컨텍스트를 갖고 있는지 확신하지 못할 때 그들에게 코드 검토를 요청하는 것은 절대적으로 허용됩니다.

리뷰어 룰렛은 유용한 제안을 제공하지만, 적절한 리뷰어를 지정하는 것이 중요하기 때문에 매번 자동으로 수행되어서는 안됩니다. 당신이 업데이트하는 영역에 대해 아무것도 알지 못하는 사람에게 지정하는 것은 코드 스타일과 문법에 한정된 피드백일 수 있기 때문에 항상 의미가 있는 것은 아닐 수 있습니다. 변경의 복잡성과 영향에 따라, 변경 사항에 대해 올바른 사람들을 지정하는 것은 매우 중요합니다.

담당자를 모르는 경우, git blame을 참고하거나 #s_verify 슬랙 채널(GitLab 팀 멤버 전용)에서 질문하세요.

추가 검토 및 추가 리뷰어를 필요로 하는 두 종류의 변경 / 병합 요청이 있습니다.

  1. 파이프라인 / 스테이지 / 생성 상태 주변의 코드를 변경하는 병합 요청
  2. 인증 / 보안 기능 주변의 코드를 변경하는 병합 요청

두 경우 모두 엔지니어들은 유지관리자와 도메인 전문가로부터 리뷰를 요청받습니다. 유지관리자가 도메인 전문가인 경우, 다른 사람을 관련시키는 것이 권장됩니다.

점진적인 롤아웃

당신의 병합 요청이 유지관리자에 의해 병합된 후, 사용자와 광범위한 커뮤니티에게 이를 릴리스하는 것이 시간입니다. 일반적으로 이를 feature flag로 수행합니다. 모든 병합 요청이 feature flag를 필요로 하는 것은 아니지만, Verify의 대부분의 병합 요청은 feature flags을 가져야 합니다.

이 페이지의 조언을 이미 따르고 있다면, 새로운 코드를 프로덕션 환경에서 관찰 가능하게 만드는 몇 가지 메트릭과 아마도 몇 가지 로거가 이미 추가된 상태일 것입니다. 지금 이러한 메트릭을 사용하여 변경 사항을 점진적으로 롤아웃할 수 있습니다!

일반적인 시나리오는 내부 프로젝트에서 몇 가지 기능을 활성화하면서 메트릭이나 로거를 관찰하는 것입니다. Elastic이나 Kibana에 로그를 흡수하는 데는 약간의 지연이 있을 수 있음에 유의하세요. 내부 프로젝트에서 기능이 잘 작동하는 것을 확인한 후 다른 프로젝트를 대상으로 점진적인 롤아웃을 시작할 수 있습니다.

“시간 비율” 점진적인 롤아웃은 피하는 것이 좋습니다. 이러한 방식은 오류가 발생할 가능성이 높으며, 특정 코드베이스의 몇 군데에서 feature flag를 확인하고 결과를 하나의 장소에 메모하는 것이 없기 때문에 복잡합니다.

우주가 붕괴되지 않도록 주의하세요

첫 번째 GitLab Contributes 이벤트 중 하나에서 우리는 CI/CD 파이프라인, 단계 및 작업 상태를 정확하게 유지하는 중요성에 대해 논의했습니다. 우리는 이른바 고객이 개발한 소프트웨어와 관련한 가상 시나리오를 고려했습니다.

만약 GitLab CI/CD의 버그로 인해 파이프라인이 통과되었지만 이 데이터가 정확하지 않아 배포된 소프트웨어가 실제로 유효하지 않았다는 것을 보여주었을 때 대형 하드론 어결가속기(LHC)에 배포된 소프트웨어가 실패한다면 어떻게 될까요? 이 문제는 LHC가 기능을 해치게 하여 새로운 입자를 생성시키고, 이후 우주가 붕괴되는 결과를 초래할 수 있습니다.

GitLab CI/CD 상태 처리 중에 작은 버그가 발생하면 이러한 원하는 결과를 초래할 수 있습니다. CI/CD 상태를 처리할 때 특별히 주의하세요. 우리는 우주를 붕괴시키고 싶지 않습니다!

이것은 극단적이고 발생 가능성이 낮은 시나리오이지만, 정확하지 않은 데이터를 제시하는 것은 나비 효과를 통해 다양한 문제를 초래할 수 있습니다. 의료, 항공 및 자동차 소프트웨어를 개발하는 회사들이 GitLab CI/CD를 사용하고 있습니다. 지속적 통합은 소프트웨어 공학의 임무 중요한 부분입니다.

완료 기준

우리는 Verify에서 개발팀의 완료 기준을 따릅니다. 또한 질문에 대한 답변과 문제 해결 시 효율적이고 DRY하게 유지하고 싶습니다.

기존 .gitlab-ci.yml 구문을 지원하므로 문제가 해결된 경우, 해당 솔루션이 지원되는 .gitlab-ci.yml 구문으로 프로젝트를 생성하세요.

프로젝트는 다음을 포함해야 합니다:

  • 간단한 제목.
  • 명확한 설명.
  • 다음을 포함하는 README.md:
    • 해결된 문제에 대한 링크. 사용자들이 궁금증이 생기면 해결된 문제에서 협력할 것을 안내해야 합니다.
    • 관련 문서에 대한 링크.
    • 예제의 상세한 설명.