Verify 스테이지 코드베이스에 기여하기
Verify에서 무엇을 작업하고 있나요?
Verify 스테이지는 GitLab 제품에 통합된 포괄적인 지속적 통합 플랫폼에 참여하고 있습니다. 우리의 목표는 사용자들이 만드는 가정을 검증하고 CI/CD 구성에서 정의된 기준에 따라 그를 확인하여, 기술 및 비즈니스 결정을 내릴 수 있도록 하는 것입니다. 이는 유닛 테스트, 엔드 투 엔드 테스트, 벤치마킹, 성능 검증, 코드 커버리지 강화 등이 될 수 있습니다.
GitLab CI/CD가 제공하는 피드백을 통해 사용자들은 성공을 이루기 위해 필요한 기술 및 비즈니스 결정을 내릴 때 잘 궁리할 수 있게 됩니다. 왜 지속적 통합은 중요한 미션 제품인가요?
GitLab CI/CD는 우리의 사용자 및 고객들에게 피드백을 전달하는 플랫폼입니다.
사용자들은 지속적 통합 구성 파일 .gitlab-ci.yml을 기여하여 CI/CD 구성에서 묻는 질문들을 설명합니다. 커밋을 푸시하거나 파이프라인을 트리거할 때마다, CI/CD 구성에서 한 가지 매우 중요한 질문에 대한 대답을 찾아야 합니다.
이러한 질문에 대답하지 못하거나, 더 나쁜 경우로는 거짓된 대답을 제공하는 것은 사용자가 잘못된 결정을 내리게 할 수 있습니다. 이러한 잘못된 결정은 매우 심각한 결과를 낳을 수 있습니다.
우리의 CI/CD 플랫폼의 핵심 원칙
플랫폼에서 프로덕션된 데이터는 다음과 같아야 합니다:
- 정확해야 합니다.
- 지속 가능해야 합니다.
- 접근이 가능해야 합니다.
플랫폼 자체는 다음과 같아야 합니다:
- 신뢰할 수 있어야 합니다.
- 안전해야 합니다.
- 결정론적이어야 합니다.
- 신뢰할 수 있어야 합니다.
- 빠르기야 합니다.
- 간단해야 합니다.
GitLab CI/CD의 출현 이후, 우리는 이러한 원칙을 준수해왔으며, 이것들은 우리와 사용자들에게 잘 기능했습니다. 이러한 원칙의 몇 가지 예는 다음과 같습니다:
- GitLab CI/CD가 제공하는 피드백과 플랫폼에서 생성된 데이터는 정확해야 합니다. 작업이 실패하고 사용자에게 성공했다고 알리면 심각한 부정적인 결과를 낼 수 있습니다.
- 피드백은 사용자가 필요로 할 때 사용 가능해야 하며 엔지니어가 필요로 할 때 데이터가 예상치 못하게 사라서는 안 됩니다.
- 플랫폼이 안전하지 않다면 모든 것이 무의미합니다. 자격증이나 비밀을 유출하지 않아야 합니다.
- 사용자가 CI/CD 구성의 선행 조건을 제공하면, 각 파이프라인 실행마다 결과가 결정적이어야 합니다. 그렇지 않으면 플랫폼은 신뢰할 수 없게 될 수 있습니다.
- 빠르고 사용하기 간편하며 훌륭한 경험을 제공한다면 사용자를 잘 봉사할 것입니다.
Verify에서 무엇을 구축하나요
최적화하기 전에 메트릭하고 데이터 기반 결정하기
메트릭할 수 없는 것을 최적화하는 것은 매우 어렵습니다. 성공했는지, 그 성공이 얼마나 중요한지를 어떻게 알 수 있을까요? 성능이나 신뢰성을 개선하려면 최적화하기 전에 메트릭하도록 하세요.
무언가를 메트릭하는 가장 좋은 방법은 Prometheus 메트릭을 추가하는 것입니다. 카운터, 게이지, 히스토그램은 빠르게 대략적인 결과를 얻는 좋은 방법입니다. 유감스럽게도 이것은 tail latency를 메트릭하는 최고의 방법은 아닙니다. 특히 히스토그램 같은 Prometheus 메트릭은 대개 대략적인 추정값입니다.
tail latency처럼 얼마나 느릴 수 있는지 또는 얼마나 큰 요청 페이로드가 될 수 있는지 메트릭해야 한다면, 사용자 정의 응용프로그램 로그를 추가하고 항상 구조화된 로깅을 사용하도록 하세요.
코드 실행 경로가 실제로 어떻게 보이는지 이해하기 위해 프로파일링과 flamegraph를 사용하는 것이 유용합니다!
단순한 해결책을 추구하고, 간교한 해결책은 피하세요
때로는 무언가를 빠르게 제공하기 위해 간교한 해결책을 사용하는 것이 유혹이 됩니다. 우리는 간교한 코드 배포를 피해야 합니다. 보통 장기적으로 더 이해하기 어렵고 유지보수하기 어렵습니다. 대신 코드베이스를 진화시키고 기여 장벽을 낮게 유지하는 데 도움이 되는 지루한 해결책에 집중하려고 합니다. 가능한 단순한 해결책을 찾으려고 합니다.
지루한 해결책을 쉬운 해결책으로 혼동하지 마세요
지루한 해결책이 종종 쉬운 해결책과 혼동됩니다. 매우 자주 반대의 경우가 사실입니다. 쉬운 해결책이 간단하지 않을 수 있습니다 - 예를 들어 매우 작은 기능을 추가하기 위해 복잡한 새 라이브러리를 포함시킬 수 있습니다. 이 라이브러리를 포함하는 것이 빠르게 이 기능을 구현하는 것보다 쉽지만, 제품에 많은 복잡성을 가져올 수 있습니다.
반면에, 단순하고 테스트된, 잘 유지 관리되는 라이브러리가 있는 경우에는 과도하게 엔지니어링한 해결책을 만드는 것도 가능합니다. 이러한 경우에는 해당 라이브러리를 사용하는 것이 합리적일 수 있습니다. 우리는 항상 간단하고 쉬운 해결책을 균형있게 유지하고 올바른 균형을 찾는 것이 중요하다는 것을 이해하고 있습니다.
“단순함”은 “유연함”과 상호 배타적인 것이 아닙니다
단순한 것을 구축하는 것은 더 고급 및 유연한 해결책이 사용할 수 없음을 의미하지는 않습니다. 여기에서 좋은 예는 .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은 데브옵스 플랫폼입니다. 우리는 데브옵스를 제공하여 기업이 더 효율적이고 더 나은 결과를 달성할 수 있도록 돕습니다. 데브옵스 문화의 중요한 컴포넌트 중 하나는 당신이 구축 중인 기능 및 코드에 대한 소유권을 가져야 한다는 것입니다. 제품 환경에서 기능이나 코드의 동작에 대해 잘 모르면 그런 소유권을 가져가기가 매우 어렵습니다.
이것이 우리가 우리의 기능과 코드를 관찰 가능하게 만들고자 하는 이유입니다. 제품 환경에서 기능이나 코드의 동작이 얼마나 잘 또는 어떻게 나쁘게 되는지 이해할 수 있도록 작성되어야 합니다. 일반적으로 이를 위해 적절한 Prometheus 메트릭과 응용프로그램 로거를 도입함으로써 이러한 목표를 달성합니다.
할 일 Prometheus 메트릭을 사용하는 시점, 로거를 사용하는 시점을 기록하세요. 히스토그램 및 카운터에 대한 몇 가지 문장을 작성하세요. 점진적 배포를 할 때 메트릭의 중요성을 강조하는 몇 가지 문장을 작성하세요.
고객 데이터 보호
우리의 CI/CD 플랫폼에서 생성된 데이터의 지속성을 유지하는 것이 중요합니다. 사용자와 고객이 생성한 데이터는 중요하며 우리는 이를 보호해야 합니다. 이러한 데이터는 중요한 정보가 포함될 뿐만 아니라, 우리에게는 규정 준수 및 감사 책임이 있기 때문입니다.
따라서 데이터베이스, 파일 시스템 또는 오브젝트 리포지터리에서 데이터를 영구적으로 제거하는 마이그레이션 코드를 작성할 때는 변경 사항에 대해 추가적인 확인을 받아야 합니다. 새로운 보존 정책을 정의할 때는 PM 및 EM과 중복 확인해야 합니다.
디자인 검토받기
파이프라인 처리 및 CI/CD 상태 전환을 위한 서브시스템을 설계할 때, 가능한 빨리 Verify 유지보수자(@gitlab-org/maintainers/cicd-verify)로부터 디자인에 대한 추가 의견을 요청하고, 다른 사람들에 대해 같은 책임을 요구하세요. Verify 유지보수자에 의해 디자인을 검토받으면 간과할 수 있는 블라인드 스pod을 가능한 빨리 확인하고 더 나은 해결책으로 이어질 수 있습니다.
개발 작업이 시작되기 전에 디자인을 검토받으면, Merge Request 리뷰를 더 효율적으로 할 수 있습니다. 디자인이 Verify 유지보수자에 의해 검토되었다면, 유지보수자 리뷰 중에 의견이 크게 달라지거나 변경 요청이 발생할 가능성이 적을 것입니다. 결과적으로 Merge Request이 더 빨리 Merge될 수 있습니다.
변경 사항 검토받기
Merge Request이 리뷰를 위해 준비되었다면 리뷰어를 할당한 후에 유지보수자를 할당해야 합니다. 변경의 복잡성에 따라 코드베이스 영역에 대해 가장 많은 정보를 알고 있는 사람들을 참여시키고 싶을 수 있습니다. Verify에는 많은 도메인 전문가 및 유지보수자가 있으며 변경 내용에 대한 리뷰어 룰렛에 의해 할당된 리뷰어 또는 유지보수자가 변경 사항에 대해 충분한 컨텍스트를 가지고 있는지 확신하지 못할 때 그들에게 리뷰해달라고 요청하는 것은 완전히 타당합니다.
리뷰어 룰렛은 유용한 제안을 제공하지만, 올바른 리뷰어를 할당하는 것은 중요하기 때문에 매번 자동으로 수행해서는 안 됩니다. 당신이 업데이트하는 영역에 대해 전혀 알지 못하는 사람에게 할당하는 것은 합리적이지 않을 수 있습니다. 그들의 피드백이 코드 스타일 및 구문에 국한될 수 있기 때문입니다. 변경의 복잡성과 영향에 따라 올바른 사람들을 할당하여 변경 사항을 검토하는 것이 매우 중요할 수 있습니다.
누구에게 할당해야 할지 모르면 git blame를 참고하거나 #s_verify 슬랙 채널에서 (GitLab 팀 멤버만) 질문하세요.
추가 검토 및 추가 리뷰어가 필요한 두 종류의 변경 / Merge Request이 있습니다:
- 파이프라인 / 스테이지 / 빌드 상태 주변의 코드를 변경하는 Merge Request
- 인증 / 보안 기능 주변의 코드를 변경하는 Merge Request
이러한 두 경우 모두 엔지니어는 유지보수자와 도메인 전문가로부터 리뷰를 요청하는 것으로 예상됩니다. 유지보수자가 도메인 전문가인 경우, 다른 사람을 참여시키는 것이 권장됩니다.
점진적 롤아웃
Merge Request이 유지보수자에 의해 Merge된 후, 사용자 및 보다 넓은 커뮤니티에게 릴리스할 시간입니다. 우리는 일반적으로 피처 플래그로 이를 수행합니다. 모든 Merge Request이 피처 플래그가 필요한 것은 아니지만, Verify의 대부분의 Merge Request은 피처 플래그를 가져야 합니다.
이 페이지의 권고사항을 이미 따르고 있다면, 아마도 새로운 코드를 프로덕션 환경에서 관찰 가능하게 하는 몇 가지 메트릭과 로깅이 추가되어 있을 것입니다. 이제 이러한 메트릭을 사용하여 변경 사항을 점진적으로 롤아웃할 수 있습니다!
전형적인 시나리오는 몇몇 내부 프로젝트에서 몇 가지 기능을 활성화하는 것과 관찰하는 것을 포함합니다. Elastic이나 Kibana에서 로그를 처리하는 데 소규모 지연이 발생할 수 있음에 유의하세요. 내부 프로젝트에서 기능이 잘 작동하는 것을 확인한 후, 다른 프로젝트에 대해 점진적으로 롤아웃을 시작할 수 있습니다.
“시간의 백분율” 점진적 롤아웃을 피하십시오. 이러한 점진적 롤아웃은 오류가 발생하기 쉽습니다. 특히 코드베이스의 몇 곳에서 피처 플래그를 체크하고 체크 결과를 단일 위치에 메모해 두지 않은 경우입니다.
우주를 붕괴시키지 마세요
GitLab Contributes 행사 중 하나에서 CI/CD 파이프라인, 스테이지 및 작업 상태를 정확하게 유지하는 중요성에 대해 토론했습니다. 관련하여 하드론 대형 입자 가속기(LHC)에 의해 소프트웨어가 구축되는 경우를 가정한 가상 시나리오를 고려했습니다.
GitLab CI/CD의 버그로 인해 파이프라인이 통과했지만 실제 데이터가 정확하지 않아 배포된 소프트웨어가 실제로 유효하지 않다는 상황이 발생하면 어떻게 될까요? 이러한 문제는 LHC가 고장나게 하고, 이는 새로운 입자를 생성하여 우주를 붕괴시킬 수 있습니다.
GitLab CI/CD 상태 처리에 작은 버그가 결과적으로 우주를 붕괴시키는 불필요한 결과를 초래할 수 있지만, 이 사례는 극단적이고 발생 가능성은 낮습니다. 그러나 정확하지 않은 데이터를 제시하는 것은 잠재적으로 다양한 문제를 초래할 수 있습니다. 나비 효과를 통해 많은 더 심각한 결과를 초래할 수 있습니다. 의료, 항공 및 자동차 소프트웨어를 개발하는 기업들이 GitLab CI/CD를 사용하고 있습니다. 지속적 통합은 소프트웨어 엔지니어링의 중요한 부분입니다.
완료 기준
Verify에서는 개발팀의 완료 기준을 따릅니다. 또한 사용자의 질문과 문제 해결 시 효율적이고 DRY하게 유지하고 싶습니다.
기존 .gitlab-ci.yml 구문을 지원하는 솔루션으로 해결된 이슈의 경우, 해당 솔루션을 보여주는 ci-sample-projects 그룹의 프로젝트를 생성하세요.
프로젝트는 다음을 포함해야 합니다:
- 간단한 제목
- 명확한 설명
- 다음이 포함된
README.md:- 해결된 이슈로의 링크. 질문이 생기면 사용자가 해결된 이슈에서 협력하도록 안내해야 합니다.
- 관련 문서로의 링크
- 예시가 하는 것에 대한 상세한 설명
도움말