This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @ash2k @ntepluhina @grzesiek @nagyv-gitlab @nmezzopera devops deploy 2024-02-16

markdown # AutoFlow - 자동화를 위한 워크플로우

자동화 + 워크플로우 = AutoFlow.

요약

GitLab은 전체 DevSecOps 주기를 위한 단일 애플리케이션을 제공하며, 우리의 목표는 AllOps 플랫폼이 되는 것입니다. 플랫폼이 되기 위해서는 해당 도메인의 다양한 문제를 해결할 수 있는 도구를 사용자에게 제공하는 것을 의미합니다. DevSecOps 도메인 객체 간 상호작용을 자동화하는 데 귀결되는 많은 사용 사례들이 존재합니다. 자동화는 대부분의 비즈니스에서 프로덕션성을 높이고 비용을 줄이는 데 필수적인 요소이므로, 이러한 사용 사례들은 우리 고객들에게 큰 영향을 미칩니다. 현재 우리는 도메인 전체에서 프로세스를 자동화하는 포괄적인 방법을 제공하지는 않습니다.

GitLab AutoFlow를 사용하면 사용자는 DevSecOps 도메인 객체 및 외부 시스템 간 상호작용의 워크플로우를 코드화할 수 있습니다. 사용자들은 워크플로우 블록에 대해 공유, 재사용, 협업할 수 있습니다.

동기

목표

  • 사용자가 DevSecOps 도메인에서 작업을 자동화하는 워크플로우를 구축할 수 있도록 함.
  • 워크플로우는 GitLab, 사용자(통해 UI), 외부 시스템과 상호작용할 수 있어야 함. 상호작용은 API 호출 및 이벤트 발신/수신을 통해 이루어집니다.
  • 사용자는 워크플로우 일부를 자기 서비스 방식으로 공유하고 재사용해야 함.
  • 워크플로우 정의는 실제 환경에서 실행하지 않고도 테스트할 수 있어야 함.
  • 언제나 고객 데이터와 GitLab 플랫폼의 보안을 염두에 두어야 함.
  • 워크플로우는 내구성 있게 실행되어야 함. 다르게 표현하면, 서버가 충돌하거나 네트워크 연결이 끊겨도 자동화된 표시가 지속되어야 함.

예시 사용 사례

사소한

  • 이슈의 마일스톤이 백로그일 때, 라벨을 workflow::backlog로 설정합니다. 마일스톤이 설정된 경우, 라벨을 workflow::ready for dev로 설정합니다.
  • 이슈의 라벨이 group::environments일 때, devops::deploy 및 section::cd 라벨을 설정합니다.
  • GitLab Triage가 수행할 작업들.

흥미로운

  • Retro bot: 마일스톤이 만료되거나 닫힐 때, 다음 월요일을 기다립니다. 그룹 내 구성원 디렉터리을 가져옵니다. 각 구성원을 대상으로 프로젝트에 이슈를 오픈합니다. 이슈에는 이 마일스톤에서 잘한 점, 그렇지 않은 점, 팀에 대한 칭찬을 입력할 필드가 추가됩니다 (현재 우리에겐 없는 새로운 UI 구성요소). 지정된 팀 구성원에게 더 이상 2일 이상 열려있는 이슈에 대해 피드백을 보냅니다. 모든 열린 이슈가 또는 일주일 후에, 무슨 일이든 먼저 발생하는 대로 그 데이터를 수집하고 그 데이터를 집계하여 새로운 이슈를 엽니다. 그 이슈를 그룹 관리자에게 할당하고 그룹 구성원 모두를 멘션합니다.
  • 프로젝트 준수: 프로젝트 설정이 변경될 때, 의도한 변경사항의 프로그램적 유효성 검사를 트리거합니다. 프로젝트 설정 제한은 일반적인 준수 요구 사항입니다. 현재 GitLab 롤 모델은 많은 사용자 정의를 허용하지 않고, 사용자들은 Terraform과 같은 코드 기반 자동화로 이 기능을 우회합니다. 다른 대안적으로 자주 요청되는 접근 방법은 더 높은 수준에서 프로젝트 설정을 제한하는 것입니다. 다양한 프로젝트 설정을 고려하면 이것은 부분적인 지원만 제공할 가능성이 높거나 모든 프로젝트 설정을 준수 설정에서 다시 구현해야 할 수도 있습니다. 전체적으로 대부분의 단일 사용 사례 해결 방법은 심각한 유지 보수 및 확장성 문제를 가질 수 있습니다. 코드로 유효성을 구현함으로써 간단한 인터페이스를 제공할 수 있습니다.

고도화된

  • 배포: 주요 브랜치로 커밋이 Merge될 때:
    • 빌드가 실행되어야 합니다.
    • 성공 시 특정 아티팩트를 릴리스로 결합해야 합니다.
    • 그런 다음 특정 배포 방법을 사용하여 사전 프로덕션 환경으로 릴리스를 롤아웃해야 합니다.
    • 배포는 거기에서 1일 동안의 합성 부하를 받아야 합니다.
    • 그런 다음 스테이징으로 프로모션되어야 합니다.
    • 스테이징에서 1일 동안 더하고 나서, 릴리스가 점진적으로 프로덕션으로 롤아웃되어야 합니다.
    • 프로덕션 롤아웃은 카나리아 배포로 시작되어야 합니다.
    • 그런 다음 시간당 10%씩 확장해야 합니다.
    • 해당 배포에 대해 이상 감지 시스템이 특정 메트릭을 모니터링해야 합니다.
    • 비정상적인 것이 감지되면 롤아웃을 중지하고 (아직 이 메커니즘은 없지만, 좋을 것입니다), SRE 팀에 통보해야 합니다.
    • 상황이 “심각하게 나쁜” 경우 (즉, 특정 메트릭이 특정 임계값을 위반하는 경우) 사건 이슈를 만들고 배포 롤백을 시작해야 합니다.
    • 배포에서 발생하는 일들에 대한 정보를 얻을 수 있어야 합니다 (우리가 Kubernetes로 배포한다고 가정합시다), 네임스페이스의 이벤트 및 GitLab 에이전트에 Pod 로그를 제공해야 합니다.
    • 이를 GitLab Duo에 공급하여 어떤 문제가 있는지와 어떻게 수정해야 하는지에 대한 조언을 받아서 응답을 댓글로 게시해야 합니다.
  • 워크플로우의 준수: 자동화된 워크플로우 중 하나 이상의 단계에서 사용자의 매뉴얼 상호작용을 기다리고 있을 수 있습니다.
    • 워크플로우에 UI 요소를 생성할 수 있도록 한다면, 해당 형식을 대기할 수 있습니다. 도식화되어있듯이 이러한 양식이 채워지는 것, 버튼이 눌리는 것 등을 대기하고 사용자 입력(또는 부재 - 타임아웃)에 따라 추가 조치를 취할 수 있습니다.
    • 배포가 PCL 중에 진행 중인 경우, 리스크 관리팀으로부터 승인을 요청할 수 있습니다.
    • 프로세스가 자동화되기 때문에, 자동화가 코드가 되기 때문에 버전이 관리되므로 감사를 통과하기 쉬워집니다. 자동화되어 있고 우회 방법이 없다면 프로세스를 따르지 않게 되는 실수할 가능성이 없습니다.
  • 접근 요청: 대부분의 (모두?) 접근 요청들을 자동화할 수 있을 것으로 보입니다.
    • 팀 구성원이 이슈를 생성하여 양식을 작성하고, 그것을 그들의 매니저에게 할당하여 라벨을 설정하거나 특별한 버튼을 누르면 자동화는 이를 가져가게 됩니다 - 대부분의 시스템은 요청된 변경사항을 적용하기 위해 사용할 수 있는 API를 가지고 있습니다.
    • 여기서 얼마나 많은 시간이 낭비되는지 고려해보십시오 - 사람들이 기다려야하고, 사람들이 반복적인 작업을 해야합니다.
    • 매뉴얼 조치는 중요한 변경을 만드는 동안 실수가 발생할 가능성이 있습니다.
    • 우리 뿐만 아니라 대부분의 비즈니스들이 이러한 프로세스를 자동화해야 하는 필요성이 있습니다.

관련 이슈

지난 몇 년 동안 자동화와 관련된 많은 이슈, 에픽, 아이디어, 사용 사례들이 축적되었습니다. 여기 몇 가지 흥미로운 예시들이 있습니다.

개선된 Work Item 수명 주기 관리 및 네이티브 자동화, GitLab 자동화, 워크플로우 솔루션 확인. 이러한 것들은 devops::plan 관점에서 문제를 바라본 것입니다:

고객 및 전망 고객들은 종단간 워크플로우(Epic, 이슈, MR…)를 쉽게 관리할 수 있는 방법이 없다고 자주 불평합니다.

14 개의 다른 계정에서 공식 요청을 받았으며, 계획 단계의 세 번째로 가장 요청된/가치 있는 기능입니다.

관련된 이슈를 에픽에서 확인하십시오.

이슈가 닫힐 때 라벨을 제거할 수 있도록 구성은 다른 한 예입니다. 283표의 투표가 있습니다.

자동화 가능한 DevOps은 Mikhail의 이전 자동화 기능을 제공하려는 시도였습니다. 많은 사고를 일으키고 이러한 제안으로 이어졌습니다.

이슈/MR 이벤트 및 해당 이벤트의 결과로 취해야 할 조치를 정의할 수 있는 기능을 추가. 고객 인용:

동의하고 있습니다. 개발 팀을 GitLab에 도입하는 데 어려움을 겪고 있습니다. 일부 부분은 자동화를 통해 처리해야 할 것이나 현재 매뉴얼 라벨 관리를 추가하려는 것이 도움이 되는 기능들 중 하나입니다.

우리는 Merge 시에 이슈를 자동으로 닫기를 원치 않으며 해당 MR이 닫히면 Issue의 라벨 관리를 자동으로 업데이트 하려고 합니다.

우리는 상대적으로 작은 팀이고 제품 개발에 집중해야 하므로 GitLab 자동화 스크립트를 작성하는 방법에 대해 집중할 필요가 없습니다.

MR Merge의 일부로 특정 이벤트를 트리거할 수 있는 능력을 가지면 매우 큰 도움이 될 것입니다.

group::delivery의 사용 사례들:

  • 프로젝트에서 특정 파일이 추가/변경될 때 이벤트가 발생한다면, Runway 플랫폼의 Provisioner를 자동화시키는 데 사용할 수 있을 것입니다 (그리고 사람들이 제거할 때 Deprovision).
  • 새 백포트 요청 이슈가 생성될 때 여러 작업을 자동화합니다.
  • 새로운 월간 릴리스를 시작하려는 경우 자동화된 작업.
  • GitLab CI만큼 강력한 “GitLab 배포 엔진”으로 이동합니다. 이게 저에게는 가장 흥미로운 사용 사례입니다. 그러나 이 워크플로우를 관리하는 것이 얼마나 복잡할지 궁금하긴 합니다.

Remote Development 팀의 사용 사례 일부 (로부터 가져옴) (이 코멘트):

이에 대한 실제 예시는 Remote Development 팀이 GitLab에서 구현하려는 표준 XP/Scrum 스타일의 속도 기반 프로세스 및 워크플로우 입니다.

GitLab 제품 자체에 여러 제한 사항 이 있어서 이 공통 프로세스를 사용하는 데 어려움을 겪고 있고, 우리는 이를 우회해야 합니다.

이 프로세스를 GitLab에서 작업하는 데에서 바인딩 할 때

컨셉 증명, 데모

위의 데모가 잘 진행되어서 내부 사용을 위한 GitLab AutoFlow epic이 열렸습니다. 그런 다음 이슈 상태 업데이트를 위한 구성 가능한 자동화를 위한 AutoFlow PoC에서 구체적인 사용 사례를 다루려고 시도했습니다. 그 과정의 일환으로 두 번의 더 많은 데모를 녹화했습니다(자세한 내용은 epic을 참조하세요):

관련 문서에 대한 링크