GitLab에서 소프트웨어 패치를 릴리스하는 방법

GitLab에서는 수동 및 자동의 두 가지 방법으로 소프트웨어 수정을 처리합니다. gitlab.com에 대한 자동 배포를 통해 중요한 업데이트를 생성하고 제공하는 릴리스 관리자의 작업과 사용자가 자체 설치에서 작업할 수 있는 패치에 대해 알아 보려면 계속 읽어보세요.

스마트워치에 알림을 설정하는 것이 좋습니다. 매달 22일에 해당 시설에서 GitLab을 사용하는 사용자는 현재 제품 버전에 대한 업데이트를 볼 수 있습니다. 월간 릴리스에는 새로운 기능과 기존 기능의 개발이 포함되어 있으며 종종 도구 또는 병합에 대한 커뮤니티 요청의 최종 결과를 보여줍니다.

그러나 실습에서 알 수 있듯이 소프트웨어 개발에 결함이 없는 경우는 거의 없습니다. 버그나 보안 취약점이 발견되면 제공 팀의 릴리스 관리자가 사용자 설치에 대한 패치를 만듭니다. Gitlab.com은 CD 프로세스 중에 업데이트됩니다. GitLab의 CD 기능과의 혼동을 피하기 위해 이 CD 프로세스를 자동 배포라고 부릅니다. 이 프로세스는 사용자, 고객 및 내부 개발 팀이 제출한 풀 요청의 제안을 통합할 수 있으므로 패치 릴리스의 지루한 문제를 매우 다른 두 가지 방법으로 해결합니다.

«우리는 개발자가 만드는 모든 것이 GitLab.com에 출시되기 전에 매일 모든 환경에 배포되도록 합니다."라고 설명한다 마린 얀코프키, 인프라 부서 수석 기술 관리자. "설치 릴리스를 gitlab.com 배포를 위한 스냅샷으로 생각하세요. 이에 대해 우리는 사용자가 패키지를 사용하여 설치에 설치할 수 있도록 패키지를 생성하는 별도의 단계를 추가했습니다.".

버그나 취약점에 관계없이 gitlab.com 고객은 수정 사항이 게시된 후 즉시 수정 사항을 받게 됩니다. 이는 자동화된 CD 프로세스의 이점입니다. 자체적으로 설치한 사용자를 위한 패치는 릴리스 관리자가 별도로 준비해야 합니다.

제공 팀은 릴리스 생성과 관련된 대부분의 프로세스를 자동화하기 위해 열심히 노력하고 있습니다. MTTP (평균 생산 시간, 즉 생산에 소요된 시간), 개발자의 병합 요청 처리부터 gitlab.com에 배포까지의 기간입니다.

«배달팀의 목표는 회사로서 더 빨리 움직일 수 있도록 하는 것, 아니면 적어도 배달원들이 더 빨리 일할 수 있도록 하는 것 아닐까요??, 마린이 말합니다.

gitlab.com 고객과 설치 사용자 모두 주기 시간을 줄이고 배포 속도를 높이려는 제공 팀의 노력으로 이익을 얻습니다. 이 기사에서는 이 두 가지 방법의 유사점과 차이점을 설명합니다. 문제, 또한 제공 팀이 시설에서 작업하는 사용자를 위해 패치를 준비하는 방법과 자동 배포를 사용하여 gitlab.com이 최신 상태인지 확인하는 방법에 대해서도 설명합니다.

릴리스 관리자는 무엇을 합니까?

매월 팀원 릴리스 관리자 역할 이전 릴리스 사이에 발생할 수 있는 패치 및 보안 릴리스를 포함하여 해당 시설의 사용자에게 릴리스합니다. 또한 회사의 자동화된 지속적인 배포로의 전환을 주도하는 역할도 담당합니다.

자체 설치 릴리스와 gitlab.com 릴리스는 유사한 작업 흐름을 사용하지만 실행 시간은 다르다고 Marin은 설명합니다.

무엇보다도 릴리스 관리자는 릴리스 유형에 관계없이 애플리케이션이 gitlab.com에서 실행되는 순간부터 GitLab을 사용할 수 있고 안전하게 보호할 수 있도록 보장합니다. 자신의 역량.

GitLab에서 버그나 취약점이 수정된 것으로 표시되면 릴리스 관리자는 해당 버그나 취약점이 설치된 사용자를 위한 패치나 보안 업데이트에 포함될 것인지 평가해야 합니다. 버그나 취약점을 업데이트할 가치가 있다고 판단하면 준비 작업이 시작됩니다.

릴리스 관리자는 수정 사항을 준비할지 또는 언제 배포할지 결정해야 하며 이는 상황의 맥락에 따라 크게 달라집니다.그 동안 기계는 사람만큼 상황을 잘 관리하지 못합니다."라고 마린은 말합니다.

수정 사항에 관한 모든 것

패치란 무엇이며 왜 필요한가요?

릴리스 관리자는 버그의 심각도에 따라 수정 사항을 릴리스할지 여부를 결정합니다.

오류는 심각도에 따라 다릅니다. 따라서 S4 또는 S3 오류는 픽셀이나 아이콘 변위와 같은 문체적 오류일 수 있습니다. 이는 그다지 중요하지 않지만 다른 사람의 작업 흐름에 큰 영향을 미치지 않습니다. 즉, 그러한 S3 또는 S4 오류에 대한 수정 사항이 생성될 가능성이 작다는 것을 의미한다고 Marin은 설명합니다.

그러나 S1 또는 S2 취약점은 사용자가 최신 버전으로 업데이트해서는 안되거나 사용자의 작업 흐름에 영향을 미치는 심각한 버그가 있음을 의미합니다. 트래커에 포함되어 있으면 많은 사용자가 이를 접한 것이므로 릴리스 관리자는 즉시 수정 준비를 시작합니다.

취약점 S1 또는 S2에 대한 패치가 준비되면 릴리스 관리자는 패치 릴리스를 시작합니다.

예를 들어, GitLab 12.10.1 패치는 여러 가지 차단 문제가 확인된 후 생성되었으며 개발자는 이러한 문제를 일으키는 근본적인 문제를 해결했습니다. 릴리스 관리자는 할당된 심각도 수준의 정확성을 평가하고 확인 후 수정 사항을 릴리스하는 프로세스가 시작되었습니다. 이 프로세스는 차단 문제가 발견된 후 XNUMX시간 이내에 준비되었습니다.

S4, S3, S2가 많이 쌓이면 릴리스 관리자가 컨텍스트를 살펴서 수정 사항 릴리스의 긴급성을 판단하고 일정 수에 도달하면 모두 결합하여 릴리스합니다. 출시 후 수정 사항이나 보안 업데이트는 블로그 게시물에 요약되어 있습니다.

릴리스 관리자가 패치를 생성하는 방법

우리는 GitLab CI와 ChatOps와 같은 기타 기능을 사용하여 패치를 생성합니다. 릴리스 관리자는 내부 채널에서 ChatOps 팀을 활성화하여 수정 사항 릴리스를 시작합니다. #releases 슬랙에서.

/chatops run release prepare 12.10.1

ChatOps는 Slack 내에서 작동하여 다양한 이벤트를 트리거한 후 GitLab에서 처리하고 실행합니다. 예를 들어 제공팀은 패치를 출시하기 위해 다양한 작업을 자동화하도록 ChatOps를 설정했습니다.

릴리스 관리자가 Slack에서 ChatOps 팀을 시작하면 나머지 작업은 CICD를 사용하여 GitLab에서 자동으로 수행됩니다. 릴리스 관리자가 프로세스의 일부 주요 단계를 활성화하므로 릴리스 프로세스 중에 Slack의 ChatOps와 GitLab 간에 양방향 통신이 이루어집니다.

아래 영상은 GitLab용 패치를 준비하는 기술적인 과정을 보여줍니다.

gitlab.com에서 자동 배포가 작동하는 방식

gitlab.com을 업데이트하는 데 사용되는 프로세스와 도구는 패치를 만드는 데 사용되는 것과 유사합니다. 릴리스 관리자의 관점에서 gitlab.com을 업데이트하면 수동 작업이 덜 필요합니다.

ChatOps를 사용하여 배포를 실행하는 대신 CI 기능을 사용합니다. 예정된 파이프라인를 통해 릴리스 관리자는 필요한 시간에 특정 작업이 수행되도록 예약할 수 있습니다. 수동 프로세스 대신 GitLab 프로젝트의 새로운 변경 사항을 다운로드하고 이를 패키징하고 배포를 예약하고 테스트, QA 및 기타 필요한 단계를 자동으로 실행하는 파이프라인이 한 시간에 한 번씩 주기적으로 실행됩니다.

Marin은 "따라서 gitlab.com 이전에는 다양한 환경에서 많은 배포가 실행되고 있었고 이러한 환경이 양호하고 테스트 결과가 좋은 결과를 얻은 후에 릴리스 관리자가 gitlab.com 배포 작업을 시작합니다"라고 말합니다.

gitlab.com 업데이트를 지원하기 위한 CICD 기술은 릴리스 관리자가 gitlab.com에 대한 프로덕션 환경 배포를 수동으로 시작해야 하는 지점까지 전체 프로세스를 자동화합니다.

Marin은 아래 비디오에서 gitlab.com 업데이트 프로세스에 대해 자세히 설명합니다.

배송팀은 또 무슨 일을 하나요?

gitlab.com 업데이트 프로세스와 사내 고객에게 패치를 릴리스하는 것의 주요 차이점은 후자 프로세스에는 릴리스 관리자의 더 많은 시간과 수동 작업이 필요하다는 것입니다.

Marin은 “보고된 문제, 도구 문제, 그리고 단일 패치를 출시할 때 고려해야 할 미묘한 차이로 인해 고객 설치에 대한 패치 출시를 연기하는 경우가 있습니다.”라고 말합니다.

딜리버리 팀의 단기 목표 중 하나는 릴리스 관리자 측의 수동 작업량을 줄여 릴리스 속도를 높이는 것입니다. 팀은 심각도가 낮은 문제(S3 및 S4, 약. 역자). 속도에 초점을 맞추는 것이 핵심 성과 지표입니다. MTTP(병합 요청을 받은 후 결과를 gitlab.com에 배포하는 데 걸리는 시간)를 현재 50시간에서 8시간으로 줄여야 합니다.

제공팀은 gitlab.com을 Kubernetes 기반 인프라로 마이그레이션하는 작업도 진행 중입니다.

편집자의 n.b.: 이미 쿠버네티스 기술에 대해 들어봤지만(물론 알고 계시리라 생각합니다), 아직 손으로 만져보지 않으셨다면 온라인 집중 강좌에 참여해 보시기를 추천드립니다. 쿠버네티스 베이스, 28월 30-XNUMX일에 개최되며, 쿠버네티스 메가14월 16~XNUMX일에 개최됩니다. 이를 통해 자신있게 기술을 탐색하고 작업할 수 있습니다.

이는 동일한 목표를 추구하는 두 가지 접근 방식입니다. 즉, gitlab.com과 해당 시설의 클라이언트 모두에게 빠른 업데이트 제공입니다.

우리에게 어떤 아이디어나 추천이 있나요?

누구나 GitLab에 기여할 수 있으며 독자들의 피드백을 환영합니다. 저희 배송팀에 대한 아이디어가 있으시면 주저하지 마세요. 요청을 생성하다 표시된 team: Delivery.

출처 : habr.com