Microsoft가 DevOps를 사용하여 소프트웨어를 제공하는 방법
Microsoft는 확장성이 뛰어난 서비스를 프로덕션 환경에 제공하는 수십 년의 경험을 보유하고 있습니다. Microsoft 서비스 환경이 확장됨에 따라 배달 방식도 시간이 지남에 따라 진화했습니다. 많은 Microsoft 고객도 이러한 효율적인 배달 방법을 채택하고 혜택을 누리고 있습니다. 다음 핵심 DevOps 원칙 및 프로세스는 최신 소프트웨어 제공 노력에 적용할 수 있습니다.
DevOps 배달 프로세스를 구현하기 위해 Microsoft는 다음 이니셔티브를 채택했습니다.
- 배달에 대한 조직의 사고방식과 주기에 초점을 맞춥니다.
- 기능을 소유, 테스트 및 제공하는 자율적이고 책임감 있는 팀을 구성합니다.
- 프로덕션 환경에서 시스템을 테스트하고 모니터링하려면 오른쪽으로 이동합니다.
배달에 집중
더 빠르게 배송하는 것은 조직과 팀이 쉽게 측정하고 평가할 수 있는 분명한 이점입니다. 일반적인 DevOps 주기에는 프로덕션에 정기적으로 배포되는 짧은 스프린트 주기가 포함됩니다.
짧은 스프린트로 제품 안정성이 부족하다는 것을 두려워한 일부 팀은 스프린트 주기가 끝날 때 안정화 기간을 보상했습니다. 엔지니어는 스프린트 중에 가능한 한 많은 기능을 제공하려고 했기 때문에 안정화 중에 지불해야 하는 테스트 부채가 발생했습니다. 스프린트 기간 동안 부채를 관리한 팀은 부채를 쌓은 팀을 지원해야 했습니다. 추가 비용은 배달 파이프라인을 통해 프로덕션으로 진행되었습니다.
안정화 기간을 제거하면 팀이 부채를 관리하는 방식이 빠르게 개선되었습니다. 안정화 기간에 핵심 기본 테넌트 작업을 밀어붙이는 대신, 부채를 쌓은 팀은 다음 스프린트를 통해 부채 목표를 따라잡을 수 있었습니다. 팀은 스프린트 중에 테스트 부채를 관리하는 방법을 빠르게 배웠습니다. 기능은 입증되고 배포 비용 가치가 있을 때 제공됩니다.
파이프라인 완전 자동화
개선 팀의 대부분은 코드 리포지토리에서 프로덕션으로 파이프라인을 완전히 자동화하는 것입니다. Automation에는 CI(연속 통합), 자동화된 테스트 및 CD(지속적인 업데이트)가 포함된 릴리스 파이프라인이 포함됩니다.
팀은 어렵기 때문에 배포를 피할 수 있지만 배포 빈도가 낮을수록 배포가 더 어려워집니다. 배포 사이에 시간이 많을수록 더 많은 문제가 쌓입니다. 코드가 새로 고침되지 않으면 배포에 문제가 있습니다.
자주 배포하여 더 작은 청크에서 작업하는 것이 더 쉽습니다. 이 아이디어는 뒤늦게 분명해 보일 수 있지만 당시에는 직관에 어긋나는 것처럼 보일 수 있습니다. 또한 잦은 배포는 팀이 보다 효율적이고 안정적인 배포 도구 및 파이프라인을 만드는 데 우선순위를 두도록 동기를 부여합니다.
사내 도구 사용
Microsoft는 빌드한 릴리스 관리 시스템을 사용하여 고객에게 배송합니다. 단일 투자를 통해 팀 생산성과 Microsoft 제품을 모두 향상시킬 수 있습니다. 보조 시스템을 사용하면 개발 및 배달 속도가 끊어질 수 있습니다.
팀 자율성 및 책임
특정 KPI(주요 진행률 지표)가 팀 생산성 또는 성능을 측정하거나 기능이 궤도에 있는지 여부를 측정하지 않습니다. 팀은 조직 목표에 부합하는 방법을 찾는 동시에 자체 계획 및 백로그를 관리할 수 있어야 합니다.
진행 상황을 추적하려면 팀과 직접 소통하는 것이 중요합니다. 도구는 통신을 용이하게 하지만 대화는 가장 투명한 의사 소통 방법입니다.
기능 우선 순위 지정
중요한 목표는 기능 제공에 집중하는 것입니다. 일정은 지정된 기간 동안 얼마나 많은 팀과 개인이 합리적으로 완료할 수 있는지 평가할 수 있지만 일부 기능은 더 일찍 제공되고 일부는 나중에 제공될 것입니다. 팀은 가장 중요한 기능을 프로덕션에 적용할 수 있도록 작업의 우선 순위를 지정할 수 있습니다.
마이크로 서비스 사용
마이크로 서비스는 배달을 개선하고 간소화하는 다양한 기술적 이점을 제공합니다. 마이크로 서비스는 팀 소유권에 대한 자연스러운 경계도 제공합니다. 팀이 마이크로 서비스에 대한 투자보다 자율성을 가지면 기능을 구현하고 부채를 관리하는 방법을 우선 순위를 지정할 수 있습니다. 팀은 마이크로 서비스에 의존하는 전체 서비스와 관계없이 버전 관리와 같은 요인에 대한 계획에 집중할 수 있습니다.
기본 작업
엔지니어는 별도의 분기에서 작업하는 데 사용됩니다. 엔지니어가 분기를 기본 분기에 통합하려고 할 때까지 각 분기의 병합 부채가 증가했습니다. 팀과 엔지니어가 많을수록 통합이 더 커졌습니다.
통합이 더 빠르고, 더 지속적으로, 더 작은 청크에서 이루어지기 위해 엔지니어는 이제 기본 분기에서 작업합니다. Git으로 전환하는 가장 큰 이유 중 하나는 간단한 분기 Git 제공이었습니다. 내부 엔지니어링의 이점은 깊은 분기 계층 구조와 낭비를 제거하는 것이었습니다. 통합에 소요되었던 모든 시간이 이제 배달에 쏟아집니다.
기능 플래그 사용
일부 기능은 스프린트 배포를 위해 완전히 완료되지는 않았지만 프로덕션 환경에서 테스트의 이점을 얻을 수 있습니다. Teams는 이 코드를 기능 플래그와 병합하고 배포하여 개발 팀 또는 얼리 어답터의 작은 세그먼트와 같은 특정 사용자에 대한 기능을 켤 수 있습니다. 기능 플래그는 전체 사용자 기반에 문제를 주지 않고 노출을 제어하며 팀이 기능을 완료할지 여부와 방법을 결정하는 데 도움이 될 수 있습니다.
프로덕션에서 테스트
프로덕션 환경에서 테스트 권한을 전환하면 사전 프로덕션 테스트가 유효하고 끊임없이 변화하는 프로덕션 환경에서 배포를 처리할 준비가 되었는지 확인할 수 있습니다.
계측 테스트 및 메트릭
앱이 배포되는 위치에 관계없이 모든 항목을 계측하는 것이 중요합니다. 계측은 문제를 식별하고 해결하는 데 도움이 될 뿐만 아니라 사용량 및 다음에 추가할 내용에 대한 귀중한 연구를 제공할 수 있습니다.
복원력 패턴 테스트
복잡한 배포 의 위험은 하나의 구성 요소 오류로 인해 종속 구성 요소가 실패하는 연속 오류이며 전체 시스템이 중단될 때까지 발생합니다. SPOF(단일 실패 지점)가 어디에 있는지, 어떻게 완화되는지 이해하고, 특히 프로덕션 환경에서 완화 프로세스를 테스트하는 것이 중요합니다.
올바른 메트릭 선택
메트릭 디자인은 어려울 수 있습니다. 일반적인 실수는 누락된 항목을 방지하기 위해 너무 많은 메트릭을 포함하는 것입니다. 그러나 이로 인해 특정 요구 사항을 충족하지 않는 메트릭의 값을 무시하거나 불신할 수 있습니다. 대신 Microsoft 팀은 성공을 측정하는 데 필요한 데이터를 결정하는 데 시간이 소요됩니다. 팀은 메트릭을 추가하거나 변경할 수 있지만 처음부터 목적을 이해하면 해당 프로세스가 용이해집니다.
팀은 메트릭의 기초 외에도 측정할 메트릭이 필요한 사항을 고려합니다. 예를 들어 사용자 이득의 속도 또는 가속은 총 사용자 수보다 더 유용한 메트릭일 수 있습니다. 메트릭은 프로젝트마다 다르지만 비즈니스 의사 결정을 추진할 가능성이 있는 메트릭이 가장 유용합니다.
메트릭을 사용하여 작업 안내
Microsoft에는 최고 수준의 검토가 포함된 메트릭이 포함되어 있습니다. 조직은 6주마다 상태, 비즈니스, 시나리오 및 고객 원격 분석에 대해 수행하는 방법을 제시합니다. 조직은 임원 및 팀과 메트릭에 대해 논의합니다.
조직 전체의 팀은 참여하는 사용자 메트릭을 검사하여 기능에 대한 의미를 확인합니다. Teams는 단순히 기능을 제공하는 것이 아니라 사람들이 기능을 사용하는지 여부와 방법을 확인합니다. 팀은 이러한 메트릭을 사용하여 백로그를 조정하고 기능을 통해 목표를 달성하기 위해 더 많은 작업이 필요한지 여부를 결정합니다.
배달 지침
- A에서 B로 가는 직선도 아니고 B도 끝이 아닙니다.
- 항상 좌절과 실수가 있을 것입니다.
- 좌절을 프로세스의 지정된 부분을 완료하기 위한 전략을 변경할 수 있는 학습 기회로 봅니다.
- 시간이 지남에 따라 모든 팀은 경험을 구축하고 변화하는 요구 사항에 맞게 조정하여 DevOps 사례를 발전합니다.
- 핵심은 최종 사용자와 배달 프로세스 자체 모두에 가치를 제공하는 데 초점을 맞추는 것입니다.