Kubernetes 모범 사례, 제 2판

2장. 개발자 워크플로

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

Kubernetes 는 소프트웨어를 안정적으로 운영하기 위해 구축되었습니다. 애플리케이션 지향 API, 자가 복구 속성, 다운타임 없는 소프트웨어 롤아웃을 위한 배포와 같은 유용한 도구로 애플리케이션 배포 및 관리를 간소화합니다. 이러한 모든 도구가 유용하긴 하지만 Kubernetes용 애플리케이션을 더 쉽게 개발하는 데는 큰 도움이 되지 않습니다. 이것이 바로 개발자 워크플로우가 필요한 이유입니다. 많은 클러스터가 프로덕션 애플리케이션을 실행하도록 설계되었기 때문에 개발자 워크플로우에서 거의 액세스하지 않지만, 개발 워크플로우가 Kubernetes를 대상으로 하도록 하는 것이 중요하며, 이는 일반적으로 클러스터 또는 적어도 클러스터의 일부가 개발용으로 사용되는 것을 의미합니다. 이러한 클러스터를 설정하여 애플리케이션을 쉽게 개발할 수 있도록 하는 것은 Kubernetes의 성공을 보장하는 데 매우 중요합니다. 클러스터를 위해 빌드된 코드가 없는 경우 클러스터 자체는 별다른 성과를 거두지 못합니다.

목표

에서 개발 클러스터 구축을 위한 모범 사례를 설명하기 전에, 이러한 클러스터에 대한 우리의 목표를 언급할 필요가 있습니다. 물론 궁극적인 목표는 개발자가 Kubernetes에서 애플리케이션을 빠르고 쉽게 빌드할 수 있도록 하는 것이지만, 이것이 실제로 실제로 무엇을 의미하며 개발 클러스터의 실제 기능에 어떻게 반영되어 있을까요?

이 질문에 답하기 위해 개발자가 클러스터와 상호 작용하는 단계를 식별하는 것부터 시작하겠습니다.

첫 번째 단계는 온보딩입니다. 이 단계에서는 새로운 개발자가 팀에 합류합니다. 이 단계에서는 사용자에게 클러스터에 대한 로그인 권한을 부여하고 첫 번째 배포에 대한 오리엔테이션을 제공합니다. 이 단계의 목표는 개발자가 최소한의 시간 내에 익숙해지도록 하는 것입니다. 이 프로세스에 대한 핵심 성과 지표(KPI) 목표를 설정해야 합니다. 합리적인 목표는 사용자가 아무것도 없는 상태에서 30분 이내에 HEAD에서 현재 애플리케이션을 실행할 수 있도록 하는 것입니다. 팀에 새로운 사람이 들어올 때마다 이 목표에 대해 어떻게 하고 있는지 테스트하세요.

두 번째 단계 가 개발 중입니다. 이것은 개발자의 일상적인 활동입니다. 이 단계의 목표는 빠른 반복과 디버깅을 보장하는 것입니다. 개발자는 코드를 클러스터에 빠르고 반복적으로 푸시해야 합니다. 또한 코드를 쉽게 테스트하고 제대로 작동하지 않을 때 디버깅할 수 있어야 합니다. 이 단계의 KPI는 측정하기가 더 어렵지만 풀 리퀘스트(PR)를 받거나 클러스터에서 변경을 실행하는 데 걸리는 시간을 측정하거나 사용자의 체감 생산성에 대한 설문조사 또는 두 가지 모두로 측정하여 추정할 수 있습니다. 또한 팀의 전반적인 생산성에서도 이를 측정할 수 있습니다.

세 번째 단계 는 테스트 단계입니다. 이 단계는 개발과 연계되어 있으며 제출 ...