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

Verify에서 작업 중인 내용은 무엇인가요?

Verify 단계는 GitLab 제품에 통합된 포괄적인 지속적 통합(Continuous Integration) 플랫폼에서 작업하고 있습니다. 우리의 목표는 사용자들이 하고 있는 가정을 확인하고 CI/CD 구성에서 정의된 기준에 따라 그것들을 확인하여 좋은 기술적, 비즈니스적 결정을 내릴 수 있도록 하는 것입니다. 이는 유닛 테스트, 엔드 투 엔드 테스트, 벤치마킹, 성능 검증, 코드 커버리지 강화 등이 될 수 있습니다.

GitLab CI/CD로 전달되는 피드백은 사용자가 성공하기 위해 내릴 필요한 기술적, 비즈니스적 선택에 대해 제대로 된 결정을 내릴 수 있게 해줍니다. 지속적 통합이 미션 크리티컬 제품인 이유는 무엇인가요?

GitLab CI/CD는 사용자 및 고객에게 피드백을 전달하기 위한 플랫폼입니다.

사용자는 지속적 통합 구성 파일인 .gitlab-ci.yml을 기여하여, 커밋을 푸시하거나 파이프라인을 트리거할 때마다, 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 플랫폼에서 생성된 데이터를 영구적으로 보호하는 것은 중요합니다. 사용자 및 고객이 생성한 CI/CD에서 생성된 데이터는 중요한 정보일 수 있으며, 우리는 준수 및 감사 책임이 있을 수 있습니다.

따라서, 데이터베이스, 파일 시스템 또는 개체 리포지터리에서 데이터를 제거해야 하는 코드를 작성할 때는 변경사항에 대해 추가적인 검토를 받아야 합니다. 새로운 보관 정책을 정의할 때는 PMs 및 EMs와 다시 한번 확인해야 합니다.

일반적인 규칙으로는 데이터베이스, 파일 시스템 또는 개체 리포지터리에서 데이터를 제거하는 코드를 작성할 때 추가적인 검토가 필요합니다. 새로운 보관 정책을 정의할 때는 PMs 및 EMs와 다시 한번 확인해야 합니다.

실제로 누구에게 할당해야 하는지 모르는 경우에는 git blame을 참조하거나 #s_verify Slack 채널에서 질문하세요(GitLab 팀 멤버만 해당합니다).

디자인 검토 받기

파이프라인 처리 및 CI/CD 상태 전이를 위한 서브시스템을 설계할 때, 가능한 빨리 Verify 유지관리자(@gitlab-org/maintainers/cicd-verify)로부터 디자인에 대한 추가적인 의견을 요청하고, 다른 사람들에게도 동일한 책임감을 요구하세요. Verify 유지관리자가 디자인을 검토하면 가능한 한 빨리 간과한 사각을 식별하고 더 나은 솔루션을 찾아낼 수 있습니다.

개발 작업을 시작하기 전에 디자인이 검토되면, MR(Merge Request) 리뷰를 더 효율적으로 만듭니다. Verify 유지관리자가 디자인을 검토했을 경우, MR 리뷰 중에 크게 다른 의견이나 변경 요청을 만나게 되지 않을 확률이 높습니다. 결과적으로 MR은 더 빨리 Merge될 수 있습니다.

변경사항 검토 받기

MR이 리뷰 준비가 됐을 때, 리뷰어를 할당한 후 유지관리자를 할당해야 합니다. 변경의 복잡성에 따라, 변경하려는 코드 베이스 영역에 대한 가장 많은 지식을 가진 사람을 관련시키고 싶을 수 있습니다. Verify에는 많은 도메인 전문가와 유지관리자가 있으며, 리뷰어 룰렛이 지정한 리뷰어 또는 유지관리자가 변경에 대한 충분한 컨텍스트를 알고 있는지 확실하지 않은 경우에는 그들에게 코드 리뷰를 요청하는 것이 아주 합리적입니다.

리뷰어 룰렛은 유용한 제안을 제공하지만, 올바른 리뷰어를 지정하는 것은 매우 중요하기 때문에 항상 자동으로 이를 수행해서는 안 됩니다. 당신이 업데이트하려는 영역에 대해 아무것도 모르는 사람에게 지정하는 것은 의미가 없을 수 있습니다. 그들의 피드백은 코드 스타일과 구문에 제한될 수 있기 때문입니다. 변경의 복잡성과 영향에 따라, 올바른 사람들을 지정하여 변경 사항을 검토받는 것은 매우 중요할 수 있습니다.

어떤 사람에게 지정할지 모를 때에는 git blame을 참조하거나 #s_verify Slack 채널에서 질문하세요(GitLab 팀 멤버만 해당합니다).

추가적인 리뷰와 추가적인 리

점진적인 롤아웃

유지보수자에 의해 Merge Request이 Merge된 후에는 사용자와 넓은 커뮤니티에 이를 배포할 시간입니다. 우리는 주로 피처 플래그로 이를 수행합니다. 모든 Merge Request이 피처 플래그를 필요로 하는 것은 아니지만, Verify의 대부분의 Merge Request은 피처 플래그를 가져야 합니다.

이 페이지의 권고 사항을 이미 따르고 있다면, 아마도 새로운 코드를 프로덕션 환경에서 관찰 가능하게 만들기 위해 이미 몇 가지 메트릭 및 로거를 추가했을 것입니다. 이제 이러한 메트릭을 사용하여 변경 사항을 점진적으로 배포할 수 있습니다!

전형적인 시나리오는 몇 가지 내부 프로젝트에서 몇 가지 기능을 활성화하는 동안 메트릭이나 로거를 관찰하는 것을 포함합니다. Elastic이나 Kibana에서 로그를 소비하는 데 작은 지연이 있을 수 있다는 점을 인식하세요. 내부 프로젝트에서 기능이 잘 작동하는 것을 확인한 후 다른 프로젝트에 대해 점진적으로 롤아웃을 시작할 수 있습니다.

“시간의 백분율” 점진적인 롤아웃을 사용하지 마십시오. 이는 코드베이스의 몇 군데에서 피처 플래그를 확인하고 확인 결과를 한 곳에 메모화하지 않았을 때 특히 오류가 발생하기 쉽습니다.

우주의 붕괴 방지

첫 번째 GitLab Contributes 이벤트 중 하나에서 CI/CD 파이프라인, 스테이지 및 작업 상태를 정확하게 유지하는 중요성에 대한 토론이 있었습니다. 우리는 이른 시기 고객 중 하나가 구축한 소프트웨어와 관련한 가상 시나리오를 고려했습니다.

만약 GitLab CI/CD의 버그로 인해 파이프라인이 통과되었지만 이 데이터가 정확하지 않았고, 실제로 배포된 소프트웨어가 유효하지 않다는 것을 나타냈다면 대형 핵입자가 동력기에 문제가 생기게 될까요? 이와 같은 문제는 LHC의 고장을 유발하고, 그러면 우주가 붕괴할 수 있습니다.

GitLab CI/CD 상태 처리에서 작은 버그의 극심하고 예상치 못한 결과입니다. CI/CD 상태 처리 시 추가로 주의해야 합니다. 우리는 우주를 붕괴시키고 싶지 않습니다!

이것은 극단적이고 발생 가능성이 낮은 시나리오지만, 정확하지 않은 데이터를 제공하면 잠재적으로 나비 효과를 통해 수많은 문제를 유발할 수 있습니다. 재앙을 일으킬 수 있는 훨씬 더 가능성이 높은 시나리오들이 있습니다. GitLab CI/CD는 의료, 항공 및 자동차 소프트웨어를 개발하는 기업에서 사용되고 있습니다. 지속적인 통합은 소프트웨어 엔지니어링의 중요한 부분입니다.

완료의 정의

Verify에서는 개발팀의 완료 정의를 따릅니다. 또한 사용자의 질문에 답변하고 문제를 해결할 때 효율적이고 DRY한 방식으로 유지하고자 합니다.

기존 .gitlab-ci.yml 구문을 지원하는 솔루션으로 문제가 해결된 이슈에 대해 ci-sample-projects 그룹에 프로젝트를 만들어서 솔루션을 보여주는 것이 좋습니다.

프로젝트에는 다음이 포함되어야 합니다:

  • 간단한 제목.
  • 명확한 설명.
  • 다음을 포함한 README.md:
    • 해결된 이슈로의 링크. 사용자가 추가 질문이 있을 경우 해결된 이슈에서 협업할 수 있도록 안내하세요.
    • 관련 문서로의 링크.
    • 예시가 하는 작업에 대한 상세한 설명.