안녕하세요 GitHub 한국 총판 단군소프트입니다.

오늘의 소식, GitHub Enterprise Server 3.7 버전이 출시되었습니다!

이번 업데이트는 GitHub Enterprise Server(GHES) 고객에게 신기능을 제공합니다. 개발자가 매일 빌드할 수 있도록 하는 동시에 관리자에게 안정성을 핵심으로 GitHub Enterprise를 대규모로 실행할 수 있는 도구를 제공하도록 설계되었습니다.

GHES 3.7의 주요 기능은 다음과 같습니다.

● Reusable workflows와 Google Cloud Storage에 대한 새로운 지원을 통해 GitHub Actions를 규모에 맞고 쉽게 구축할 수 있습니다.

● 보안 개요는 개발자 관리자와 보안 팀에게 보안에 대한 중앙 집중식 뷰를 제공합니다.

● 자동화된 사용자 onboarding 및 offboarding을 통해 인스턴스를 그 어느 때보다 안전하게 유지하는 향상된 management console을 제공합니다.

● 새로운 forking 와 repository 정책을 통해 innersource의 모범 사례를 채택하는 것이 더 쉬우면서도 감사 기능의 균형을 유지하고 프로젝트를 장기적으로 유지 관리할 수 있습니다.

● Code scanning alerts는 더 많은 협업 보안 검토를 위해 pull request 대화 탭에 표시됩니다.

그럼 시작해 볼까요?

GitHub Actions를 규모에 맞게 안전한 배포를 하는 것이 쉽습니다.

GitHub Actions는 모든 workflows를 쉽게 자동화하고 팀 간에 workflows를 쉽게 공유할 수 있도록 설계된 개발자 자동화 도구입니다. GHES 3.5에서 처음 출시된 reusable workflows를 통해 개발자는 회사 내에서 워크플로우를 공유하고 프로젝트 전체에서 해당 workflows를 사용할 수 있습니다.

reusable workflows가 크게 개선되어 팀이 자동화를 더 쉽게 공유할 수 있게 되었습니다.

● 이제 reusable workflows를 함께 중첩할 수 있어 팀은 새롭고 호환성이 있는 워크플로우를 신속하게 작성할 수 있습니다.

● reusable workflows는 매트릭스 작업 정의를 지원하므로 여러 호스팅 환경에서 단일 CI 작업을 쉽게 실행할 수 있습니다. 자세한 내용은 matrix for your jobs를 참조해 주세요.

GitHub Pages를 사용하는 기업은 이제 GitHub Actions를 사용하여 저장소에서 직접 해당 페이지를 배포할 수 있습니다. 따라서 GitHub Actions를 배포 게이트와 빌드 환경이 내장된 앱과 GitHub Pages의 단일 CD 공급자로 사용할 수 있습니다.

GitHub Actions는 이제 Google 클라우드 스토리지를 지원합니다.

GHES 3.7을 사용하면 관리자는 관리 콘솔에서 직접 설정한 서버 인스턴스에서 logs, artifacts 및 caches를 저장하도록 Google Cloud Storage for GitHub Actions를 구성할 수 있습니다. 

새로운 개발자 workflows 및 enterprise 정책으로 innersource 모범 사례 채택

GitHub는 오랫동안 기업 간에 코드를 공유하고 organizational silos를 해소함으로써 팀이 더 빨리 혁신할 수 있도록 지원하는 플랫폼이었습니다. 모든 개발자와 기업이 innersource 사례를 쉽게 채택하고 보안과 감사 가능성의 균형을 맞출 수 있도록 GHES 3.7은 forking 경험, forking 정책 및 repository 생성 정책을 다양하게 개선합니다. 아래 몇 가지 예가 있습니다.

조직의 모든 저장소 유지

Enterprise 개발자가 개인 namespace에 repository를 만들 때 관리자는 감사 기능 및 정책 시행 부족으로 개발자가 퇴사할 때 유지보수 문제까지 장기적인 문제를 안고 있을 수 있습니다. 새로운 forking workflow는 관리자를 위한 두 가지 새로운 엔터프라이즈 정책을 통해 이 문제를 해결하는 데 도움이 됩니다.

이제 개발자는 repository를 같은 조직으로 분기하는 동시에 분기 이름을 지정할 수 있습니다. fork는 upstream repository와 동일한 가시성을 유지합니다(private, private 또는 internal).

또한 관리자는 모든 새 repository 규정을 준수하고 감사 가능한 조직에서 소유하도록 하는 두 가지 enterprise-wide 정책을 사용하도록 설정할 수 있습니다. 즉, 새로운 저장소를 조직으로만 제한할 수 있으며, 포크를 조직으로 제한할 수도 있습니다. 이러한 변경은 모든 기업이 innersource를 보다 쉽게 혁신할 수 있도록 설계되었습니다.

어느 때보다 안전한 인스턴스를 유지합니다.

Azure Active Directory 및 Okta와 같은 ID 공급자는 대부분의 경우 직원이 GHES 인스턴스에 액세스할 수 있는 가장 좋은 리소스입니다. 관리자는 ID 공급자를 사용하여 SAML SSO를 구성할 수 있지만 offboarding과 팀 관리는 완전히 별개입니다. 이로 인해 중복 작업과 복잡한 시간에 민감한 offboarding processes가 발생할 수 있습니다.

이 릴리스에는 관리자가 새로운 SCIM API를 통해 완전히 자동화된 방식으로 사용자 계정을 프로비저닝 및 일시 중단하고 ID 공급자로부터 직접 팀 멤버십을 채울 수 있는 SCIM 사용자 관리의 비공개 베타 버전이 포함되어 있습니다. SCIM API에 대해 자세히 알아보거나 계정 관리자에게 문의하여 지금 비공개 베타 버전을 사용해 보세요.

한편, 관리 콘솔은 보다 엄격한 비밀번호 정책과 완전한 감사 로그로 보안 면모를 대폭 개선했습니다.

보안 팀은 코드 리스크를 한 번에 파악할 수 있게 되었습니다.

이제 모든 기업 고객은 보안 개요에 액세스할 수 있으며, 이를 통해 기업 전체의 보안 상태를 중앙 집중식으로 파악할 수 있습니다. 애플리케이션 보안 팀, 엔지니어링 리더 및 개발자는 Dependabot alerts, code scanning 및 secret scanning alerts 등을 모두 한 곳에서 볼 수 있습니다. 엔터프라이즈 계정의 코드 보안 탭에서 보안 개요를 찾을 수 있습니다.

종속성 또는 코드 검사 경고가 누락될 가능성 감소

GitHub의 종속성 그래프는 가장 널리 사용되는 매니페스트 형식을 자동으로 검색하지만 Gradle, Scala SBT 또는 Maven의 매니페스트와 같은 일부 매니페스트는 정적으로 스캔할 수 없거나 전이적 종속성을 자동으로 포함하지 않습니다.

dependency submission API를 통해 CI 워크플로가 최근 빌드의 종속성을 SBOM 형식으로 GitHub의 dependency graph에 제출할 수 있습니다. 그런 다음 이러한 종속성이 GitHub dependency graph에 표시되고 취약성에 대한 Dependabot alerts를 생성할 수 있습니다. submission API를 사용하여 dependency graph를 확장하는 방법에 대해 자세히 알아보려면 여기를 읽어주세요.

보안 취약성의 영향을 더욱 쉽게 평가할 수 있도록 코드 스캔 경고를 보다 협업적이고 접근하기 쉬우며 관련성이 높은 것으로 만들고 있습니다. 이제 보안 경보를 대화형 주석으로 추가하여 pull request의 대화 탭에 표시합니다. 개발자는 이러한 주석의 코멘트를 작성하고 기존의 모든 기능을 사용하여 경고를 효과적으로 분류할 수 있습니다(경로 표시, 경보 해제 및 세부 정보 표시 포함).

지금 바로 시험해 보세요.

GitHub Enterprise Server 3.7에 대한 자세한 내용은 릴리스 노트를 읽고 지금 다운로드하세요.