• Verify에서 우리가 작업하고 있는 내용은 무엇인가요?
• 우리의 CI/CD 플랫폼의 핵심 원칙
• Verify에서의 작업 구축
  • 최적화하기 전에 측정하고, 데이터 기반의 결정을 내리세요
  • 단순한 솔루션을 추구하고, 기발한 솔루션을 피하세요
  • 지루한 솔루션과 쉬운 솔루션을 혼동하지 마세요
  • “간단함”은 “유연성”과 상호 배타적이지 않습니다
  • 사물을 관찰 가능하게 만드세요
  • 고객 데이터 보호하기
  • 디자인 검토 요청하기
  • 변경 사항 검토 받기
  • 점진적 롤아웃
  • 우리의 우주가 붕괴되지 않도록 하세요
  • 완료 정의

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

Verify에서 우리가 작업하고 있는 내용은 무엇인가요?

Verify 단계는 GitLab 제품에 통합된 포괄적인 Continuous Integration 플랫폼을 작업하고 있습니다. 우리의 목표는 사용자가 훌륭한 기술적 및 비즈니스 결정을 내릴 수 있도록, 사용자가 수립하는 가정을 확인하고 CI/CD 구성에서 정의된 기준에 대해 이를 검사하는 빠르고 신뢰할 수 있으며 안전한 플랫폼을 제공하는 것입니다. 이들은 단위 테스트, 엔드 투 엔드 테스트, 성능 검증, 코드 커버리지 강제화 등이 될 수 있습니다.

GitLab CI/CD에서 제공하는 피드백은 사용자가 성공하기 위해 내릴 기술적 및 비즈니스 선택에 대해 잘-informed된 결정을 내릴 수 있도록 합니다. Continuous Integration이 미션 크리티컬 제품인 이유는 무엇일까요?

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

그들은 질문에 대한 답변을 설명하는 .gitlab-ci.yml 형식의 Continuous Integration 구성 파일을 기여합니다. 누군가가 커밋을 푸시하거나 파이프라인을 트리거할 때마다 우리는 CI/CD 구성에서 제기된 아주 중요한 질문들에 대한 답변을 찾아야 합니다.

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

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

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

1. 정확해야 합니다.
2. 내구성이 있어야 합니다.
3. 접근 가능해야 합니다.

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

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

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

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

Verify에서의 작업 구축

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

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

측정하는 가장 좋은 방법은 Prometheus 메트릭을 추가하는 것입니다. 카운터, 게이지, 히스토그램은 근사된 결과를 빠르게 얻는 훌륭한 방법입니다. 불행히도, 이것은 지연(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은 DevOps 플랫폼입니다. 우리는 DevOps를 대중화하여 기업들이 더 효율적이고 더 나은 결과를 đạt할 수 있도록 돕습니다. DevOps 문화의 중요한 구성 요소는 여러분이 만들고 있는 기능과 코드에 대해 소유권을 가지는 것입니다. 기능이 프로덕션 환경에서 어떻게 수행되고 동작하는지 모르는 상태에서 이를 수행하는 것은 매우 어렵습니다.

이 때문에 우리는 최종 사용자가 우리의 기능과 코드를 관찰 가능하게 만들고 싶습니다. 작성자는 기능이나 코드가 프로덕션 환경에서 잘 동작하는지, 잘 동작하지 않는지 이해할 수 있는 방식으로 작성되어야 합니다. 우리는 일반적으로 Prometheus 메트릭과 애플리케이션 로거의 적절한 조합을 도입하여 이를 달성합니다.

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

고객 데이터 보호하기

우리의 CI/CD 플랫폼에서 생성된 데이터를 내구성 있게 만드는 것은 중요합니다. 우리는 사용자와 고객이 CI/CD에서 생성한 데이터가 중요하다는 것을 인식하고 있으며, 이를 보호해야 합니다. 이 데이터는 중요한 정보가 포함될 수 있기 때문에 중요할 뿐만 아니라, 우리는 준수 및 감사의 책임도 가지고 있습니다.

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

일반적인 규칙으로, 데이터베이스, 파일 시스템 또는 객체 저장소에서 데이터를 제거할 목적으로 코드를 작성할 때는 반드시 추가적인 검토를 받아야 합니다. 새로운 보유 정책을 정의할 때는 PM과 EM과 다시 확인해야 합니다.

디자인 검토 요청하기

파이프라인 처리 및 CI/CD 상태 전환을 위한 하위 시스템을 설계할 때, 가능하면 디자인에 대한 추가 의견을 Verify 유지보수자(@gitlab-org/maintainers/cicd-verify)에게 요청하고 다른 사람들 또한 그렇게 할 수 있도록 책임을 물어야 합니다. Verify 유지보수자의 디자인 검토를 받는 것은 여러분이 간과했을 수 있는 맹점을 조기에 발견하는 데 도움이 되며, 이는 더 나은 솔루션으로 이어질 수 있습니다.

개발 작업이 시작되기 전에 디자인을 검토 받으면, 병합 요청 검토가 더 효율적으로 진행될 수 있습니다. 디자인이 Verify 유지보수자에 의해 검토되었다면, 유지보수자 리뷰 중에 상충되는 의견이나 변경 요청을 받을 가능성이 줄어듭니다. 따라서 병합 요청이 더 빨리 병합될 수 있습니다.

변경 사항 검토 받기

병합 요청이 검토를 받을 준비가 되면, 검토자를 할당해야 하며, 그 다음에는 유지 관리자를 할당해야 합니다. 변경의 복잡성에 따라, 변경 중인 코드베이스 영역에 대해 가장 잘 아는 사람들을 포함하는 것이 좋습니다. Verify에는 많은 도메인 전문가와 유지 관리자가 있으며, Reviewer Roulette에 의해 할당된 검토자나 유지 관리자가 변경에 대한 충분한 맥락을 가지고 있는지 확신이 서지 않을 때, 그들에게 코드 검토를 요청하는 것은 전적으로 허용됩니다.

검토자 룰렛은 유용한 제안을 제공하지만, 적절한 검토자를 할당하는 것이 중요하므로 매번 자동으로 진행되어서는 안 됩니다. 업데이트하는 영역에 대해 전혀 모르는 사람에게 할당하는 것은 의미가 없을 수 있으며, 그들의 피드백은 코드 스타일과 구문에 국한될 수 있습니다. 변경의 복잡성과 영향에 따라, 변경 사항을 검토할 적절한 사람을 할당하는 것은 매우 중요할 수 있습니다.

누구를 할당해야 할지 모를 경우, git blame을 참조하거나 #s_verify 슬랙 채널에서 물어보세요 (GitLab 팀원만 해당).

추가적인 주의가 필요한 두 가지 종류의 변경 사항 / 병합 요청은 다음과 같습니다:

1. 파이프라인 / 단계 / 빌드 상태와 관련된 코드를 변경하는 병합 요청.
2. 인증 / 보안 기능과 관련된 코드를 변경하는 병합 요청.

두 경우 모두 엔지니어는 유지 관리자와 도메인 전문가에게 검토를 요청해야 합니다. 유지 관리자가 도메인 전문가인 경우 다른 사람을 포함하는 것이 권장됩니다.

점진적 롤아웃

병합 요청이 유지 관리자에 의해 병합되면, 이를 사용자와 더 넓은 커뮤니티에 배포할 시간입니다. 우리는 보통 기능 플래그를 사용하여 이를 수행합니다.

모든 병합 요청이 기능 플래그를 필요로 하는 것은 아니지만, Verify의 대부분의 병합 요청은 기능 플래그를 가져야 합니다.

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

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

“시간의 비율” 점진적 롤아웃을 피하세요. 이는 오류가 발생하기 쉬우며, 특히 코드베이스의 여러 곳에서 기능 플래그를 확인할 때 단일 장소에서 체크 결과를 메모화하지 않은 경우 더욱 그렇습니다.

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

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

Large Hadron Collider (LHC)에 배포된 소프트웨어가 GitLab CI/CD의 버그로 인해 파이프라인이 통과했다고 표시되었지만 이 정보가 정확하지 않아 실제로 배포된 소프트웨어가 잘못된 경우에 어떻게 될까요? 이러한 문제는 LHC 작동에 문제가 생겨 새로운 입자가 생성되고, 그로 인해 우주가 붕괴될 수도 있습니다.

이는 GitLab CI/CD 상태 처리의 작은 버그로 인한 매우 바람직하지 않은 결과일 것입니다. CI/CD 상태에서 작업할 때는 특별히 주의하세요, 우리의 우주가 붕괴되기를 원하지 않으니까요!

이는 극단적이고 가능성이 낮은 시나리오이지만, 정확하지 않은 데이터를 제공하는 것은 잠재적으로 수많은 문제를 발생시킬 수 있습니다. 버터플라이 효과와 같은 그럴 수 있습니다. 훨씬 더 가능성이 높은 시나리오가 있으며 이는 재앙적인 결과를 초래할 수 있습니다. GitLab CI/CD는 의료, 항공 및 자동차 소프트웨어를 구축하는 회사에 의해 사용되고 있습니다. 지속적인 통합은 소프트웨어 공학의 핵심적인 부분입니다.

완료 정의

Verify에서는 개발 팀의 완료 정의를 따릅니다.

우리는 또한 사용자의 질문에 답변하고 문제를 해결할 때 효율적이고 DRY하게 유지하고 싶습니다.

기존의 .gitlab-ci.yml 구문으로 지원되는 솔루션으로 해결된 모든 문제에 대해,

해당 솔루션을 보여주는 ci-sample-projects 그룹에 프로젝트를 생성하세요.

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

• 간단한 제목.
• 명확한 설명.
• 다음이 포함된 README.md:
  • 해결된 문제에 대한 링크. 질문이 발생할 경우 사용자가 해결된 문제에서 협업할 수 있도록 안내해야 합니다.
  • 관련 문서에 대한 링크.
  • 예제가 하는 일에 대한 자세한 설명.