GitLab 17.2가 지난 18일 출시됐습니다. 이번 업데이트에서는 Kubernetes 로그 스트리밍 지원 기능, 변경 요청으로 Merge Request 차단 기능, 취약점 설명 기능 GA 버전, 새로운 파이프라인 실행 보안 정책 유형을 선보였습니다. 아울러 파이프라인 Secret Detection에서 커스텀 ruleset 지원을 확대하고, 삭제된 브랜치를 Jira 개발 패널에서 제거하도록 업데이트했습니다.

위 내용은 이번 릴리즈에서 선보인 30개 이상의 개선 사항 중 몇 가지 주요 사항입니다. 아래에 주요 업데이트 내용을 모두 확인하세요. 다음 달 릴리즈 내용을 미리 보려면, 17.3 릴리즈 킥오프 비디오가 있는 예정 릴리즈 페이지를 확인하세요.


Kubernetes pod와 컨테이너 로그 스트리밍

FREEPREMIUMULTIMATE
Kubernetes pod와 컨테이너의 로그 스트리밍 보기 화면. 출처=GitLab | 인포그랩 GitLab
Kubernetes pod와 컨테이너의 로그 스트리밍 보기 화면. 출처=GitLab

앞서 GitLab 16.1에서는 Kubernetes pod 목록과 상세 보기를 도입했습니다. 그러나 워크로드를 심층적으로 분석하려면 여전히 서드 파티 도구를 사용해야 했습니다. 이제 GitLab이 pod와 컨테이너의 로그 스트리밍 보기를 제공합니다. 이로써 애플리케이션 배포 도구를 벗어나지 않고도 환경 전반의 문제를 빠르게 확인하고 트러블슈팅 할 수 있습니다.

변경 요청으로 Merge Request 차단

PREMIUMULTIMATE
변경 요청이 해결되지 않아 MR의 merge가 차단된 모습. 출처=GitLab | 인포그랩 GitLab
변경 요청이 해결되지 않아 MR의 merge가 차단된 모습. 출처=GitLab

GitLab에서 리뷰를 수행할 때 approve, comment 또는 request changes 중 선택해 리뷰를 완료할 수 있습니다(GitLab 16.9에서 릴리즈). 리뷰하는 동안 Merge Request(MR)가 해결될 때까지 merge 되는 걸 막아야 하는 변경 사항을 발견할 수 있으므로 request changes로 리뷰를 완료합니다.

이제 변경을 요청할 때, GitLab은 이 요청이 해결될 때까지 merge를 방지하는 merge 확인 기능을 추가했습니다. 변경을 요청한 원래 사용자가 MR을 다시 리뷰한 뒤 이를 승인하면, 변경 요청은 해결될 수 있습니다. 원래 변경을 요청한 사용자가 승인할 수 없으면, merge 권한이 있는 누구나 변경 요청을 우회(Bypass)할 수 있어 개발을 계속할 수 있습니다.

이슈 455339에서 이 새로운 기능을 피드백해 주세요.

취약점 설명 기능 GA 버전 출시

ULTIMATEDUO ENTERPRISE
취약점 설명 기능 실행 화면. 출처=GitLab | 인포그랩 GitLab
취약점 설명 기능 실행 화면. 출처=GitLab

취약점 설명 기능은 이제 GitLab Duo Chat의 일부로, GA(Generally Available) 버전이 됐습니다. 이 기능을 사용하면, 모든 SAST 취약점에서 채팅을 열어 취약점을 더 잘 이해하고, 취약점이 어떻게 악용될 수 있는지 확인하며, 잠재적 수정 사항을 검토할 수 있습니다.

파이프라인 실행 정책 유형

ULTIMATE
파이프라인 실행 정책 유형 화면. 출처=GitLab | 인포그랩 GitLab
파이프라인 실행 정책 유형 화면. 출처=GitLab

파이프라인 실행 정책 유형은 사용자가 일반 CI job, 스크립트, 명령의 실행을 지원할 수 있는 보안 정책의 새로운 유형입니다.

이는 보안·컴플라이언스 팀이 맞춤화된 GitLab 보안 스캐닝 템플릿, GitLab 또는 파트너 지원 CI 템플릿, 서드 파티 보안 스캐닝 템플릿, CI job을 통한 커스텀 보고 규칙 또는 GitLab CI를 통한 커스텀 스크립트/규칙을 시행하도록 지원합니다.

파이프라인 실행 정책에는 ‘inject’와 ‘override’라는 두 가지 모드가 있습니다. inject 모드는 job을 프로젝트의 CI/CD 파이프라인에 주입합니다. override 모드는 프로젝트의 CI/CD 파이프라인 구성을 대체합니다.

모든 GitLab 정책과 마찬가지로, 정책을 만들고 관리하는 지정된 보안·컴플라이언스 팀원이 중앙에서 실행을 관리할 수 있습니다. 첫 번째 스캔 실행 정책을 만들어 시작하는 방법을 알아보세요!

파이프라인 Secret Detection 커스텀 ruleset 지원

ULTIMATE
시크릿 커스텀 ruleset 구성 화면. 출처=GitLab | 인포그랩 GitLab
시크릿 커스텀 ruleset 구성 화면. 출처=GitLab

GitLab이 파이프라인 Secret Detection에서 커스텀 ruleset 지원을 확대했습니다.

두 가지 새로운 유형의 패스스루인 giturl을 사용해 원격 ruleset을 구성할 수 있습니다. 이로써 여러 프로젝트에서 ruleset 구성을 공유하는 것과 같이 워크플로를 더 쉽게 관리할 수 있습니다.

또 새로운 유형의 패스스루 중 하나를 사용해 원격 ruleset으로 기본 구성을 확장할 수도 있습니다.

Analyzer는 이제 다음 기능도 지원합니다:

  • 최대 20개의 패스스루를 단일 구성으로 연결해 사전 정의된 규칙 대체
  • 패스스루에 환경 변수 포함
  • 패스스루 로드 시 타임아웃 설정
  • ruleset 구성에서 TOML 구문 유효성 검사

삭제된 브랜치, Jira 개발 패널서 제거

FREEPREMIUMULTIMATE

이전에는 Jira Cloud 앱 용 GitLab을 사용할 때 GitLab에서 브랜치를 삭제해도 해당 브랜치가 Jira 개발 패널에 여전히 표시됐습니다. 이 브랜치를 선택하면 GitLab에서 404 오류가 발생했습니다.

이번 릴리즈부터 GitLab에서 삭제된 브랜치는 Jira 개발 패널에서 제거됩니다.

인포그랩의 기술지원 서비스를 받으세요!

완벽한 GitLab 구축부터 성공적인 DevOps 도입까지! 인포그랩과 DevOps 라이프사이클을 함께하세요.

(이 포스트는 GitLab의 동의를 받아 공식 블로그의 영문 포스트를 우리말로 번역한 글입니다.)

Tip! 인포그랩의 GitLab 버전별 기능에서 버전별로 추가된 기능을 검색해 볼 수 있습니다.