Share via

도구 및 프로세스 표준화를 위한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 운영 우수성 검사 목록 권장 사항에 적용됩니다.

OE:04 개발 및 테스트에 대한 업계에서 입증된 사례를 따라 소프트웨어 개발 및 품질 보증 프로세스를 최적화합니다. 명확한 역할 지정을 위해 도구, 소스 제어, 애플리케이션 디자인 패턴, 설명서 및 스타일 가이드와 같은 구성 요소의 사례를 표준화합니다.

관련 가이드: 빌드 속도 | 향상연속 통합 사용

이 가이드에서는 소프트웨어 개발 도구 및 프로세스에 대한 표준을 정의하기 위한 권장 사항을 설명합니다. 일관된 사례를 정의하면 효율적인 워크로드 팀과 고품질 작업으로 이어집니다. 고성능 팀은 업계에서 입증된 도구와 프로세스를 사용하여 낭비되는 노력과 잠재적 코드 오류를 최소화합니다.

주요 디자인 전략

개발 사례를 최적화하는 첫 번째 단계는 도구와 프로세스를 표준화하는 것입니다. 가능하면 사내 솔루션을 개발하는 대신 업계에서 입증된 솔루션을 사용합니다. 사례를 더욱 최적화하려면 로우 코드 및 코드 없는 도구를 채택합니다. 이러한 도구를 사용하면 애플리케이션에 노력을 집중하고 시간을 절약할 수 있습니다. 표준화하는 모든 도구와 프로세스의 경우 팀이 이를 이해하고 효율적으로 사용할 수 있도록 교육을 구현합니다. 개발 사례를 최적화하는 데 도움이 되는 표준을 정의하려면 다음 권장 사항을 고려하세요.

잘 알려진 성숙한 기성품 도구 사용

잘 알려진 성숙한 기성 도구를 사용하고 사용을 표준화합니다. 매우 효과적인 엔지니어링 팀은 동급 최고의 도구를 채택합니다. 이 접근 방식은 계획, 개발, 테스트, 협업 및 CI/CD(지속적인 통합 및 지속적인 업데이트)를 위한 솔루션을 개발해야 하는 필요성을 최소화합니다. 많은 기업에서는 개발자에게 몇 가지 도구 중에서 선택할 수 있지만 모든 옵션은 organization 대한 표준 도구이며 내부적으로 유효성을 검사합니다. 가장 중요한 것은 워크로드에 대한 요구 사항을 충족하는 도구를 선택하는 것입니다. 기성품 도구는 다음 기능을 제공해야 합니다.

  • 작업 계획 및 백로그 관리

  • 버전 제어 및 리포지토리

  • CI/CD 파이프라인

  • 통합, 스모크, 가상 사용자, 시뮬레이션, 카오스 및 기타 품질 테스트와 같은 테스트

  • 코드 개발

경우에 따라 하나의 도구 또는 도구 모음이 여러 함수를 제공할 수 있습니다. 도구의 기능과 해당 제한 사항을 이해하여 함수 전체의 요구 사항을 충족하는지 확인합니다.

비용이 많이 드는 도구 또는 프리미엄 버전의 도구에 투자해야 하는지 결정합니다. 프리미엄 도구가 제공하는 기능과 비교하여 고유한 솔루션을 개발하는 시간과 노력을 고려합니다. 일회성 비용 및 반복 비용을 고려합니다. 대부분의 경우 기성품 도구는 팀에 더 높은 가치를 제공합니다.

실용적인 경우 로우 코드, 코드 없음 및 AI 도구를 사용합니다. 코드가 부족하고 코드 없는 도구는 전체 코드 개발 프로세스를 수행하는 대신 기능을 쉽게 연결할 수 있도록 하여 숙련된 개발자의 시간을 절약합니다. 또한 이러한 도구를 사용하면 학습되지 않은 개발자가 워크로드 작업에 기여할 수 있는 워크로드 팀 구성원을 허용합니다. AI 도구는 코드 개발, 검토 및 최적화에 도움이 될 수 있습니다.

분기 전략 표준화

가능한 경우 트렁크 기반 모델을 선택합니다. 트렁크 기반 분기는 워크로드 개발 팀을 동기화 상태로 유지하고 지속적인 업데이트를 장려합니다. 기본 분기와 같은 중요한 분기를 보호하기 위해 분기 정책을 정의합니다. 자세한 내용은 Git 분기 전략 채택 및 분기 정책 및 설정을 참조하세요.

메트릭을 평가하여 개발 효율성 정량화

소프트웨어 개발 및 품질 보증 팀은 효율성을 정량화할 수 있는 경우에만 개선할 수 있습니다. 효율성을 정량화하려면 개발자 속도를 측정하고 KPI를 정의하는 메트릭을 식별해야 합니다. 이러한 메트릭의 예는 다음과 같습니다.

  • 배포 빈도: 각 개발자가 매일 배포하는 배포 수입니다.

  • 리드 타임: 작업 또는 사용자 스토리가 백로그에서 프로덕션 배포로 이동하는 데 걸리는 시간입니다.

  • 평균 해결 시간: 코드에서 버그 또는 결함을 수정하는 데 소요된 평균 시간입니다.

  • 변경 실패율: 실패를 초래하는 변경 내용의 백분율입니다.

관련자와 워크로드 팀이 속도를 쉽게 추적할 수 있도록 대시보드 또는 기타 보고 도구를 사용하여 KPI를 시각화합니다.

워크로드 팀이 코드 작성, 검토 및 문서 작성 방법 표준화

스타일 가이드를 사용하여 워크로드 팀이 코드를 작성, 검토 및 문서화하는 방법을 표준화합니다. 표준 스타일을 사용하면 협업이 쉽고 새 개발자의 온보딩에 도움이 됩니다. 효과적으로 작동하려면 새 개발자가 워크로드 팀의 작동 방식을 알고 있어야 합니다. 명확하게 정의된 표준이 있는 스타일 가이드는 학습 프로세스를 용이하게 할 수 있습니다. 스타일 가이드에서 개발 언어, 라이브러리, 프레임워크 및 기타 규칙에 대한 표준을 정의합니다.

실용적이면 도구를 사용하여 코드 서식 표준을 적용합니다. 예를 들어 Visual Studio는 코드에서 스타일, 품질, 유지 관리 효율성, 디자인 및 기타 문제를 검사하는 여러 도구를 제공합니다. IaC(Infrastructure as Code)의 경우 Terraform에 Checkov 또는 Terrascan을 사용할 수 있습니다.

일관성을 보장하고 잠재적인 혼동을 방지하려면 스타일 가이드에 아티팩트, 환경, 분기, 빌드 및 실행에 대한 표준 명명 규칙이 포함되어야 합니다.

또한 환경에서 허용되는 분산 정도에 대한 지침과 표준을 설정해야 합니다. 워크로드 팀 구성원이 표준 목록에 추가하려는 새 언어, 프레임워크 또는 기타 기술이 있는 경우 샌드박스 또는 하위 환경에서 해당 도구를 사용하는 프로세스를 구현합니다. 해당 실행 가능성을 테스트하고 적절한 경우 기존 기술을 대체합니다.

ADR(아키텍처 의사 결정 레코드)을 사용하여 워크로드 팀의 디자인 결정에 대한 기록 기록을 유지합니다. ADR은 팀이 워크로드에 대한 새로운 이해를 유지하는 데 도움이 됩니다. 또한 새 팀 구성원이 워크로드의 수명 주기 동안 내려진 디자인 결정에 대해 배울 수 있도록 도와줍니다. ADR이 버전 제어되는지 확인합니다.

ADR에서 다음을 포함합니다.

  • 팀이 선택하는 특정 도구 및 기술(예: SQL 또는 NoSQL 사용).

  • 팀의 결정에 대한 이유입니다.

  • 고려된 다른 옵션으로, 최종 결정을 컨텍스트화하는 데 도움이 됩니다.

  • 의사 결정에 고려되는 기능 및 비기능 요구 사항입니다.

  • 해결된 문제와 같은 의사 결정 프로세스의 컨텍스트입니다.

기술 문제를 해결하기 위한 표준 구현

워크로드 팀의 결과물에 기술적 부채가 의도적이고 필요하다는 사고방식을 채택합니다. 이러한 사고방식은 팀이 누적을 피하기 위해 정기적으로 기술적인 문제를 고려하고 해결하도록 동기를 부여합니다. 백로그에서 정기적으로 반복되는 작업으로 기술 문제를 해결합니다.

예를 들어 팀이 라이브러리에서 표준화되어 있다고 가정합니다. 시간이 지남에 따라 워크로드의 새로운 기능을 위해 다른 라이브러리로 전환해야 합니다. 이러한 전환으로 인해 기술적인 부채가 발생할 수 있습니다. 이와 같은 전환은 원활하게 전환할 수 없기 때문에 워크로드 팀이 두 가지 기술을 지원하게 될 수 있습니다. 워크로드 팀은 워크로드가 새로운 기능을 달성할 때 이해 관계자가 만족하고 기술적인 문제를 고려할 가능성이 적기 때문에 전환 완료의 우선 순위를 지정해야 합니다.

아티팩트에서 버전 관리를 적용하는 방법 표준화

아티팩트 버전 관리를 적용하는 방법과 버전 관리가 내부 및 외부에서 노출되는 방식을 표준화합니다. 예를 들어 클라이언트 연결 시스템은 사용자 인터페이스에서 실행 중인 버전을 노출해야 합니다. 이 기술은 고객이 사용하는 버전을 쉽게 통신할 수 있으므로 워크로드 팀이 문제를 해결할 때 유용합니다. REST 인터페이스는 특정 구성 요소 또는 데이터베이스에 대한 버전을 노출할 수 있습니다. 스키마에 대한 메타데이터의 특정 테이블을 사용하여 스키마 버전을 노출할 수 있습니다.

업계에서 입증된 애플리케이션 디자인 패턴을 사용하여 애플리케이션이 안정적이고 성능이 뛰어나며 안전한지 확인합니다. 이러한 패턴을 사용하여 애플리케이션에 대한 고유한 솔루션을 개발하는 데 비해 시간과 노력을 절약할 수 있습니다. 워크로드에 도움이 되는 패턴을 선택합니다. 정기적으로 디자인 패턴을 검토하여 워크로드가 발전함에 따라 올바른 패턴을 사용하는지 확인합니다.

테스트에 대한 왼쪽 시프트 접근 방식 구현

개발 프로세스 전체에서 초기 및 자주 단위 테스트를 수행하여 테스트에 대한 시프트 레프트 접근 방식을 구현합니다. 각 개발 환경에서 자주 테스트하면 개발자가 애플리케이션에 대한 확신을 얻을 수 있습니다. 왼쪽 시프트 접근 방식으로 테스트 전략을 만들려면 다음 원칙을 고려합니다.

  • 가능한 가장 낮은 수준에서 테스트를 작성합니다. 외부 종속성이 가장 적은 테스트를 선호하고 빌드의 일부로 테스트를 실행합니다.

  • 테스트를 한 번 작성하고 프로덕션을 비롯한 모든 곳에서 테스트를 실행합니다. 암호화된 비밀 또는 구성과 같이 한 환경에 특정한 요인을 고려하지 않고 모든 개발 환경에서 실행할 수 있는 테스트를 작성합니다.

  • 테스트를 위해 워크로드를 디자인합니다. 애플리케이션을 개발할 때 테스트 가능성을 요구 사항으로 만듭니다.

  • 테스트 코드를 애플리케이션 코드로 처리합니다. 애플리케이션 코드 및 테스트 코드에 동일한 품질 및 개발 표준을 적용합니다. 애플리케이션 코드와 함께 테스트 코드를 저장합니다. 애플리케이션 코드를 사용하여 테스트 코드를 개발하고 유지 관리합니다. 테스트 품질을 보장하려면 신뢰할 수 없는 테스트를 삭제합니다.

  • 워크로드 소유권을 기반으로 하는 테스트 소유권을 고려합니다. 워크로드 팀은 테스트를 소유하고 있으며 다른 팀에 의존하여 코드를 테스트해서는 안 됩니다.

  • 가능한 한 테스트를 자동화합니다. 자동화된 코드는 워크로드 팀의 부담을 덜어주고 일관된 품질을 적용합니다.

DevOps 테스트 전략 구현에 대한 자세한 지침은 단위 테스트가 남아 있는 Shift 테스트를 참조하세요.

표준 운영 절차의 일부로 DevSecOps 사례를 요구합니다. 워크로드 팀은 소프트웨어 개발 및 품질 보증과 관련된 보안 사례를 이해해야 합니다. 예외 없이 이러한 사례를 따라야 합니다. 자세한 내용은 보안 개발 수명 주기 가이드를 참조하세요.

리소스 이름 지정 및 태그 지정에 대한 표준 구현

태그 지정 및 명명 규칙을 구현하는 것은 Azure 리소스를 관리하고 구성하는 모범 사례입니다. 태그 지정 및 명명 규칙은 환경, 애플리케이션, 소유자 또는 비용 센터와 같은 일반적인 특성에 따라 리소스를 식별, 분류 및 그룹화하는 데 도움이 됩니다. 또한 구독 및 리소스 그룹 전체에서 리소스의 보안, 자동화, 보고 및 거버넌스를 사용하도록 설정합니다.

표준화된 태그 지정 및 명명 규칙을 사용할 때의 이점은 다음과 같습니다.

  • 리소스 식별 및 관리에 대한 일관성과 명확성을 제공하여 Azure Portal, PowerShell, CLI 및 API에서 검색 및 검색을 용이하게 합니다.
  • 청구, 모니터링, 보안 및 규정 준수를 위해 리소스를 필터링하고 그룹화할 수 있습니다.
  • 프로비저닝, 서비스 해제, 백업 및 복구와 같은 리소스 수명 주기 관리를 지원합니다.
  • 보안 목적에 필수적입니다. 보안 인시던트가 발생하는 경우 영향을 받는 시스템, 해당 시스템이 지원하는 기능 및 잠재적인 비즈니스 영향을 신속하게 식별하는 것이 중요합니다.

클라우드 리소스에 명명 규칙을 사용하는 방법에 대한 자세한 내용은 명명 규칙 정의를 참조하세요. 클라우드 리소스에 메타데이터 태그를 적용하는 방법에 대한 자세한 내용은 태그 지정 전략 정의를 참조하세요.

Azure 촉진

  • Azure DevOps 는 협업적이고 효율적이며 일관된 개발 사례를 빌드하는 데 사용할 수 있는 서비스 모음입니다. Azure DevOps는 다음 솔루션을 번들로 제공합니다.

  • Azure용 GitHub Actions CI/CD 프로세스를 자동화하는 데 사용할 수 있는 도구입니다. Azure와 직접 통합하여 배포를 간소화합니다. 리포지토리에 대한 모든 끌어오기 요청을 빌드하고 테스트하는 워크플로를 만들거나 병합된 끌어오기 요청을 프로덕션에 배포할 수 있습니다.

  • GitHub Projects 는 Kanban 보드, 보고서, 대시보드 및 기타 함수를 만드는 데 사용할 수 있는 작업 관리 도구입니다.

  • 로우 코드 및 코드 없는 도구는 다음과 같습니다.

  • Azure Resource Manager 템플릿 및 Bicep은 IaC를 배포하는 데 사용할 수 있는 Azure 네이티브 도구입니다. Terraform 은 인프라를 배포하고 관리하는 데 사용할 수 있는 또 다른 Azure 지원 IaC 도구입니다.

  • Visual Studio 는 Azure와 통합되고 많은 언어를 지원하는 강력한 개발 도구입니다.

  • GitHub Copilot 쌍 프로그래머 역할을 하고 코딩할 때 자동 완성 스타일 제안을 제공하는 AI 서비스입니다. Copilot는 Visual Studio 및 기타 여러 개발 도구에서 확장으로 사용할 수 있습니다.

  • Azure Load Testing 은 호스트되는 위치에 관계없이 애플리케이션에 대한 트래픽을 시뮬레이션하여 대규모 부하를 생성하는 데 사용할 수 있는 완전 관리형 부하 테스트 서비스입니다.

운영 우수성 검사 목록

전체 권장 사항 집합을 참조하세요.

운영 우수성 검사 목록