Verify에서 현재 작업 중인 것은?#

Verify Stage는 GitLab 제품에 통합된 포괄적인 지속적 통합(Continuous Integration) 플랫폼을 개발하고 있습니다. 우리의 목표는 사용자가 훌륭한 기술적·비즈니스적 결정을 내릴 수 있도록 지원하는 것입니다. 이를 위해 빠르고 안정적이며 안전한 플랫폼을 제공하여, 사용자의 가정을 검증하고 CI/CD 구성에 정의된 기준과 대조합니다. 여기에는 단위 테스트, 엔드-투-엔드 테스트, 벤치마킹, 성능 검증, 코드 커버리지 적용 등이 포함됩니다.

GitLab CI/CD가 전달하는 피드백은 사용자가 성공하기 위해 내려야 하는 기술적·비즈니스적 선택에 대해 충분한 정보를 바탕으로 결정을 내릴 수 있게 합니다. 지속적 통합이 미션 크리티컬(mission critical) 제품인 이유가 여기에 있습니다.

GitLab CI/CD는 사용자와 고객에게 피드백을 전달하는 우리의 플랫폼입니다.

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

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

CI/CD 플랫폼의 핵심 원칙#

플랫폼에서 생성되는 데이터는 다음과 같아야 합니다:

• 정확해야 합니다.

• 내구성이 있어야 합니다.

• 접근 가능해야 합니다.

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

• 안정적이어야 합니다.

• 안전해야 합니다.

• 결정론적이어야 합니다.

• 신뢰할 수 있어야 합니다.

• 빨라야 합니다.

• 단순해야 합니다.

GitLab CI/CD가 시작된 이래 우리는 이러한 원칙들을 지켜왔으며, 이는 우리와 우리 사용자에게 잘 적용되고 있습니다. 이 원칙들의 몇 가지 예시는 다음과 같습니다:

• GitLab CI/CD가 전달하는 피드백과 플랫폼이 생성하는 데이터는 정확해야 합니다. job이 실패했는데 사용자에게 성공했다고 알리면 심각한 부정적 결과가 발생할 수 있습니다.

• 피드백은 사용자가 필요할 때 사용 가능해야 하며, 엔지니어가 필요로 할 때 데이터가 예상치 않게 사라져서는 안 됩니다.

• 플랫폼이 안전하지 않아 자격 증명이나 시크릿이 유출된다면 이 모든 것은 의미가 없습니다.

• 사용자가 CI/CD 구성 형태로 사전 조건 세트를 제공하면, 파이프라인이 실행될 때마다 결과가 결정론적이어야 합니다. 그렇지 않으면 플랫폼이 신뢰할 수 없게 됩니다.

• 빠르고 사용하기 단순하며 뛰어난 UX를 갖추면 사용자에게 잘 서비스할 수 있습니다.

Verify에서 구현하기#

최적화 전에 측정하고, 데이터 기반 결정을 내리세요#

측정할 수 없는 것을 최적화하기는 매우 어렵습니다. 성공 여부나 성공의 중요도를 어떻게 알 수 있을까요? 성능 또는 안정성 개선 작업을 할 때는 최적화 전에 반드시 측정부터 해야 합니다.

가장 좋은 측정 방법은 Prometheus 메트릭을 추가하는 것입니다. 카운터, 게이지, 히스토그램은 근사치 결과를 빠르게 얻기 위한 훌륭한 방법입니다. 그러나 이는 테일 레이턴시(tail latency)를 측정하기에는 최선의 방법이 아닙니다. 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은 DevSecOps 플랫폼입니다. 우리가 DevOps를 대중화하는 이유는 기업이 더 효율적으로 운영되고 더 나은 결과를 달성하는 데 도움이 되기 때문입니다. DevOps 문화의 중요한 요소 중 하나는 자신이 구축하는 기능과 코드에 대한 소유권을 갖는 것입니다. 프로덕션 환경에서 기능이 어떻게 동작하는지 모른다면 이를 실천하기가 매우 어렵습니다.

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

TODO Prometheus 메트릭을 언제 사용하고 로거를 언제 사용해야 하는지 문서화해야 합니다. 히스토그램과 카운터에 대해 몇 문장을 작성하세요. 점진적 롤아웃 시 메트릭의 중요성을 강조하는 몇 문장을 작성하세요.

고객 데이터를 보호하세요#

CI/CD 플랫폼이 생성하는 데이터를 내구성 있게 유지하는 것은 중요합니다. 사용자와 고객이 CI/CD에서 생성한 데이터는 중요하며 반드시 보호해야 한다는 것을 인식하고 있습니다. 이 데이터는 중요한 정보를 담고 있을 수 있다는 점에서만 중요한 것이 아니라, 컴플라이언스와 감사 책임도 있습니다.

따라서 데이터베이스에서 데이터를 영구적으로 삭제하는 마이그레이션을 작성하거나 새로운 데이터 보존 정책을 정의할 때 각별히 주의해야 합니다.

일반적인 규칙으로, 데이터베이스, 파일 시스템, 또는 오브젝트 스토리지에서 데이터를 제거하는 코드를 작성할 때는 변경 사항에 대해 추가적인 검토를 받아야 합니다. 새로운 데이터 보존 정책을 정의할 때는 PM 및 EM과 두 번 확인해야 합니다.

설계를 리뷰받으세요#

파이프라인 처리 및 CI/CD 상태 전환을 위한 서브시스템을 설계할 때는, 가능한 한 빠리 Verify maintainer(@gitlab-org/maintainers/cicd-verify)에게 설계에 대한 추가적인 의견을 요청하고 다른 사람들도 동일하게 하도록 책임을 물으세요. Verify maintainer에게 설계를 리뷰받으면 간과할 수 있는 사각지대를 최대한 빨리 파악하고 더 나은 해결책으로 이어질 수 있습니다.

개발 작업이 시작되기 전에 설계를 리뷰받으면 머지 리퀘스트 리뷰도 더 효율적으로 이루어집니다. 설계가 Verify maintainer에게 리뷰를 받았다면 maintainer 리뷰 중에 의견이 크게 다르거나 변경 요청이 발생할 가능성이 줄어듭니다. 결과적으로 머지 리퀘스트를 더 빨리 머지할 수 있습니다.

변경 사항에 대해 리뷰받으세요#

머지 리퀘스트가 리뷰 준비가 되면 반드시 리뷰어를 먼저 지정하고 그 다음 maintainer를 지정해야 합니다. 변경의 복잡성에 따라, 변경 중인 코드베이스 영역을 가장 잘 아는 사람들을 참여시키고 싶을 수 있습니다. Verify에는 많은 도메인 전문가와 maintainer가 있으며, Reviewer Roulette이 지정한 리뷰어나 maintainer가 변경 사항에 대해 충분한 컨텍스트를 갖고 있지 않다고 확신할 수 없을 때 코드를 리뷰해 달라고 요청하는 것은 완전히 허용됩니다.

Reviewer Roulette은 유용한 제안을 제공하지만, 올바른 리뷰어를 지정하는 것이 중요하므로 매번 자동으로 수행되어서는 안 됩니다. 업데이트하는 영역에 대해 전혀 모르는 사람을 지정하는 것은 의미가 없을 수 있는데, 그들의 피드백이 코드 스타일과 문법으로 제한될 수 있기 때문입니다. 변경의 복잡성과 영향에 따라, 변경 사항을 리뷰할 올바른 사람을 지정하는 것이 매우 중요할 수 있습니다.

누구를 지정해야 할지 모른다면 git blame을 확인하거나 #s_verify Slack 채널(GitLab 팀원 전용)에서 물어보세요.

리뷰와 추가 리뷰어의 추가적인 주의가 필요한 두 가지 종류의 변경 사항/머지 리퀘스트가 있습니다:

• 파이프라인 / Stage / 빌드 상태와 관련된 코드를 변경하는 머지 리퀘스트.

• 인증 / 보안 기능과 관련된 코드를 변경하는 머지 리퀘스트.

두 경우 모두 엔지니어는 maintainer와 도메인 전문가에게 리뷰를 요청해야 합니다. maintainer가 도메인 전문가인 경우 다른 사람을 참여시키는 것이 권장됩니다.

점진적 롤아웃#

머지 리퀘스트가 maintainer에 의해 머지되면, 사용자와 더 넓은 커뮤니티에 릴리스할 시간입니다. 우리는 보통 피처 플래그(feature flag)를 통해 이를 수행합니다. 모든 머지 리퀘스트에 피처 플래그가 필요한 것은 아니지만, Verify의 대부분의 머지 리퀘스트에는 피처 플래그가 있어야 합니다.

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

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

"시간의 퍼센트" 점진적 롤아웃을 사용하는 것은 피하세요. 이는 오류가 발생하기 쉽습니다. 특히 코드베이스의 여러 곳에서 피처 플래그를 확인하고 단일 위치에서 확인 결과를 메모이제이션하지 않은 경우에 그렇습니다.

우리의 우주가 폭발하지 않도록 하세요#

초기 GitLab Contributes 이벤트 중 하나에서 우리는 CI/CD 파이프라인, Stage, job 상태를 정확하게 유지하는 것의 중요성에 대해 논의했습니다. 우리는 초기 고객 중 하나가 구축 중인 소프트웨어와 관련된 가상의 시나리오를 고려했습니다:

대형 강입자 충돌기(LHC)에 배포된 소프트웨어가 파이프라인이 통과했다고 표시하는 GitLab CI/CD의 버그로 인해 손상되었지만, 실제 이 데이터는 부정확하고 배포된 소프트웨어가 실제로 유효하지 않다면 어떻게 될까요? 이와 같은 문제로 인해 LHC가 오작동하여 새로운 입자가 생성되고 우주가 폭발할 수 있습니다.

이는 GitLab CI/CD 상태 처리의 작은 버그가 초래할 수 있는 상당히 바람직하지 않은 결과일 것입니다. CI/CD 상태를 작업할 때 각별히 주의하세요. 우리는 우주가 폭발하기를 원하지 않습니다!

이는 극단적이고 가능성이 낮은 시나리오이지만, 정확하지 않은 데이터를 표시하는 것은 나비 효과를 통해 수많은 문제를 일으킬 수 있습니다. 훨씬 가능성이 높고 재앙적인 결과를 초래할 수 있는 시나리오들이 있습니다. GitLab CI/CD는 의료, 항공, 자동차 소프트웨어를 구축하는 기업들이 사용하고 있습니다. 지속적 통합은 소프트웨어 엔지니어링의 미션 크리티컬한 부분입니다.

완료의 정의#

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

기존 .gitlab-ci.yml 구문으로 해결책이 지원되어 해결되는 이슈의 경우, 해결책을 보여주는 프로젝트를 ci-sample-projects 그룹에 생성하세요.

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

• 간단한 제목.

• 명확한 설명.

• 다음을 포함하는 README.md:

해결된 이슈에 대한 링크. 또한 사용자가 질문이 있을 때 해결된 이슈에서 협업하도록 안내해야 합니다.

• 관련 문서에 대한 링크.

• 예시가 수행하는 작업에 대한 자세한 설명.