개발팀의 성공은 릴리스의 빈도와 성공에 달려 있습니다. 너무 느리게 릴리스하는 팀은 비즈니스 요구와 혁신을 따라잡을 수 없으며, 실패한 릴리스를 너무 많이 만드는 팀은 고객 만족도, 수익 및 전반적인 시스템 안정성에 부정적인 영향을 미칠 것입니다.
Google의 DORA( DevOps Research and Assessment ) 팀은 소프트웨어 개발 조직의 성능을 나타내는 4가지 핵심 지표를 식별했습니다. 우리의 Innovation and Growth 가치 동인은 이러한 지표를 사용하여 더욱 안정적인 기능과 함께 보다 효율적이고 대응력이 뛰어난 개발 팀을 만드는 전체 프로그램을 만듭니다. 이 릴리스 품질 가이드는 배포 빈도, 애플리케이션 성능 및 애플리케이션 안정성을 향상하는 데 도움이 됩니다.
주요 컨셉
유지 개념에는 다음이 포함됩니다.
의사 소통, 수정, 혁신
New Relic의 관찰성 성숙도 실천의 중심 주제 중 하나는 "의사소통, 해결, 혁신"입니다. 우리는 특정 KPI를 사용하여 이해관계자에게 개발 관행의 현재 상태를 전달할 수 있도록 하여 해당 주제를 지원합니다. 그런 다음 이러한 KPI를 사용하여 개발 방식을 조정하고 느리고 신뢰할 수 없는 애플리케이션 구성 요소를 식별하여 후속 개발 스프린트에서 수정할 수 있습니다. 마지막으로 이러한 KPI를 사용하여 개발 방식을 보다 효율적으로 만들고 팀이 혁신할 시간을 추가할 수 있습니다.
트렁크 기반 개발
트렁크 기반 개발은 "개발자가 trunk 이라는 단일 분기에서 코드에 대해 공동 작업하는 소스 제어 분기 모델은 문서화된 기술을 사용하여 수명이 긴 다른 개발 분기를 생성하라는 압력에 저항합니다."로 정의됩니다. 즉, 개발 작업을 단일 트렁크의 분기에 대해 수행되는 작은 배치로 나눕니다. 하나의 작업 배치가 완료되자마자 해당 분기가 다시 트렁크로 병합됩니다. 각 브랜치는 수명이 짧기 때문에 트렁크로 다시 병합하는 것이 간단하고 모든 개발자가 코드베이스의 최신 릴리스에서 작업할 수 있습니다.
이러한 관행은 DORA(DevOps Research and Assessment) 조직에서 더 빠른 제공과 더 높은 조직 성과를 촉진하는 핵심 기능으로 확인되었습니다. CI/CD의 필수 실습입니다.
IT 서비스 경계
릴리스 품질 개선은 IT 서비스 경계 수준에서 이루어집니다. 경계에서 서비스를 측정하면 해당 서비스의 업스트림에서 무슨 일이 일어나고 있는지 파악할 수 있습니다.
서비스 수준 관리 가이드에서는 서비스 경계 개념을 사용하여 해당 서비스의 응답 시간과 오류율을 측정합니다. 이 가이드에서는 동일한 개념을 사용하여 개발 방식이 서비스에 미치는 영향을 측정한 다음 개발 팀의 응답성, 혁신 능력 및 애플리케이션 안정성을 향상시킵니다.
핵심 성과 지표
개발 품질 프로세스를 사용하여 다음 KPI를 수집하고 측정합니다.
애플리케이션 식별
첫 번째 단계는 개선 프로세스의 첫 번째 반복 범위에 있는 응용 프로그램을 식별하는 것입니다. 포함하기에 적합한 애플리케이션은 다음과 같습니다.
- 활발히 개발 중입니다
- 핵심 운영 서비스
- 개발 주기가 느림
- 배포 실패 기록 보유
필요한 KPI 수집
다음으로 CI/CD 플랫폼, 소스 저장소, 관찰 솔루션 등과 같은 소스에서 정의된 대로 KPI를 수집해야 합니다. KPI의 소스를 식별한 후에는 이를 추출하여 New Relic 플랫폼으로 가져오는 방법을 식별해야 합니다.
위의 핵심 성과 지표 섹션에서 필요한 KPI 및 최소 필수 속성을 확인할 수 있습니다. 일반적으로 개발 도구 체인의 API를 사용하여 KPI와 해당 속성을 추출한 다음 사용자 정의 이벤트 API 를 사용하여 New Relic에 제출합니다.
사용자 정의 통합 작업을 시작하기 전에 목표를 충족하는 즉시 사용 가능한 통합이 있는지 확인해야 합니다.
대시보드 구현
당사의 품질 개선 프로세스의 주요 동인입니다. 개선 노력을 식별하고 우선순위를 지정할 수 있도록 KPI와 추세가 표시됩니다. 샘플 대시보드는 GitHub의 옵저버빌리티 성숙도 리소스 센터에서 찾을 수 있습니다.
대시보드에 표시되는 정보는 개발 도구 체인에 따라 다르므로 정확한 사양에 맞게 대시보드를 사용자 정의 해야 합니다.
릴리스 기준 설정
초기 활성화를 수행 하기 전에 기준선을 구성하는 데 충분한 데이터가 필요하므로 개발 활동 샘플로 구성된 기준선을 설정해야 합니다. 일반적으로 이는 최소 2주가 소요되지만 현재 개발 속도에 따라 최대 6주까지 걸릴 수 있습니다. 이를 수행하는 한 가지 쉬운 방법은 해당되는 경우 기본 수집 및 평가 주기를 애자일 스프린트에 맞추는 것입니다.
기준을 설정하는 동안 이벤트 데이터가 New Relic에 예상대로 누적되는지 정기적으로 확인해야 합니다.
팀과 만나기
기준선을 설정한 후에는 개발 팀과 기타 이해관계자에게 수집된 데이터와 앞으로 따르게 될 지속적인 개선 프로세스를 소개하게 됩니다.
이 프로세스는 네 가지 활동으로 구성됩니다.
Introduce the concepts of trunk-based development
: 귀하와 이해관계자는 트럭 기반 개발의 핵심 개념을 검토하고 현재 관행의 차이점을 파악한 다음 이를 구현하기 위한 전략을 수립합니다.
Review your release KPIs and trends
: 릴리스 속도, 릴리스 크기 및 범위 KPI를 검토하여 트렁크 기반 개발 구현을 향해 진전을 이루고 있는지 확인합니다. 귀하의 목표는 새 릴리스의 크기와 범위를 줄이면서 릴리스 속도를 높이는 것입니다.
Review your application KPIs and trends
: 여기에서는 애플리케이션의 성능과 오류 KPI를 검토하여 애플리케이션 안정성과 성능을 개선하기 위한 노력을 식별하고 우선순위를 지정합니다.
Make technical recommendations
: 여기서는 귀하와 관련 이해관계자가 릴리스 워크플로우 또는 옵저버빌리티 전략 변경과 같은 기술적 권장 사항을 식별하고 검토하게 됩니다.
개선 프로세스 시작
이 마지막 단계는 지속적인 개선 프로세스입니다. 이 단계에서는 팀과 만나 기준에 대한 진행 상황을 검토하고 전략을 조정하여 원하는 개선 사항을 제공하게 됩니다. 개선 프로세스의 각 주기는 개발 프로세스를 여러 번 반복한 후에 발생해야 합니다. 일반적으로 이러한 상황은 모든 Agile 스프린트의 중간 지점과 끝 부분에서 발생합니다.
이 단계에서 다음을 수행해야 합니다.
- 매주 KPI를 이해관계자에게 보고하여 팀이 작업 우선순위를 적절하게 지정하고 약속된 비즈니스 결과에 대한 진행 상황을 보여줄 수 있도록 하세요.
- 시간이 지남에 따라 주간 KPI를 기록하고 유지하여 새로운 기준을 설정하고 개선 속도를 보여줍니다.