소프트웨어 엔지니어링 시스템 적용
개발자 셀프 서비스 개선은 플랫폼 엔지니어링 과정에서 해결하는 첫 번째 문제 중 하나여야 합니다.
자동화된 셀프 서비스 환경을 사용하도록 설정하는 가장 쉬운 방법 중 하나는 기존 엔지니어링 시스템을 다시 사용하는 것입니다. 이러한 시스템은 사용자와 내부 고객에게 익숙할 뿐만 아니라 초기 사용자 환경이 좋지 않더라도 광범위한 자동화 시나리오를 사용할 수 있습니다.
이 문서에서는 광범위한 셀프 서비스 시나리오를 해결하기 위해 엔지니어링 시스템을 적용하기 위한 팁과 모범 사례를 올바르게 시작하고 올바르게 유지하는 데 도움이 되는 템플릿으로 캡슐화하는 방법에 대한 세부 정보를 제공합니다.
기본 DevOps 및 DevSecOps 사례 평가
엔지니어링 시스템은 내부 개발자 플랫폼의 중요한 측면입니다. 내부 개발자 플랫폼은 DevOps 및 DevSecOps의 기본 테넌트에서 구축되어 관련된 모든 사람의 인지 부하를 줄입니다.
DevOps는 개발 및 운영을 결합하여 애플리케이션 계획, 개발, 전달 및 운영에서 사람, 프로세스 및 기술을 통합합니다. 개발, IT 운영, 품질 엔지니어링 및 보안과 같은 역사적으로 사일로 역할을 통해 협업을 개선하기 위한 것입니다. 개발, 배포, 모니터링, 관찰 및 피드백 간에 연속 루프를 설정합니다. DevSecOps는 애플리케이션 개발 프로세스 전반에 걸쳐 지속적인 보안 사례를 사용하여 이 루프에 계층을 적용합니다.
다음 섹션에서는 포장된 경로, 자동화된 인프라 프로비저닝(애플리케이션 배포 외에), 코딩 환경 설정과 함께 애플리케이션 개발 루프의 직접적인 부분이 아닌 도구, 팀 자산 및 서비스의 셀프 서비스 프로비저닝 및 구성과 같은 플랫폼 엔지니어링 이동에 따른 개선 사항에 중점을 줍니다.
원하는 포장 경로 설정
엔지니어링 시스템을 구성하는 여러 도구 집합이 이미 있는 경우 초기 플랫폼 엔지니어링 작업의 일부로 통합할지 아니면 처음부터 다른 도구의 별자리를 지원할 것인지를 조기에 결정해야 합니다. 이 도구 별자리 내에서 포장된 경로 집합을 정의하는 것이 가장 효과적이며 향상된 수준의 유연성을 제공합니다.
제품 사고방식으로 전환하기 시작하면 이러한 포장된 경로 내의 엔지니어링 시스템을 개발 팀에 대한 서비스로 중앙에서 관리되는 도구로 구성한다고 생각합니다. 그러면 조직 내의 개별 팀 또는 부서가 이탈할 수 있지만 규정 준수 요구 사항을 준수하면서 도구를 별도로 관리, 유지 관리 및 지불해야 합니다. 이는 시간이 지남에 따라 포장된 경로에 포함될 수 있는 모든 것을 평가할 수 있으므로 중단 없이 새로운 도구를 에코시스템에 공급할 수 있는 방법을 제공합니다. 한 플랫폼 엔지니어링 책임자는 다음과 같이 설명합니다.
당신은 여전히 자신의 일을 할 수 있지만 우리가 가는 방향으로 그것을 할 수 있습니다 ... 원하는 대로 변경할 수 있지만 이는 사용자의 책임이 됩니다. 당신은 변화를 소유 - 당신은 날카로운 칼을 소유하고 있습니다. - Mark, 플랫폼 엔지니어링 책임자, 유럽 대규모 다국적 소매 회사
플랫폼 엔지니어링의 주요 목표는 내부 고객에게 가치를 제공하는 제품 사고방식으로 전환하는 것입니다. 이 별자리 접근 방식은 일반적으로 하향식 명령보다 더 잘 작동합니다. 포장된 경로를 설정하고 구체화할 때 유연성을 유지하면 팀이 조직의 다른 사용자에게 영향을 주지 않고 지정된 애플리케이션에 대한 진정한 고유한 요구 사항을 입력하고 해결할 수 있습니다. 이렇게 하면 완전히 포장된 황금색 경로 집합으로 이어지지만 다른 경로는 부분적으로만 포장됩니다. 고유한 요구 사항이 없는 경우 개발 팀이 수행하는 추가 작업으로 인해 자연스럽게 시간이 지남에 따라 지원되는 경로로 이동하려고 합니다.
통합 전략을 선호하는 경우 기존 애플리케이션을 마이그레이션하는 것이 예상보다 더 많은 작업이 될 수 있으므로 시작하려면 이 공간의 시작 오른쪽 측면에 집중하고 새 프로젝트에 집중할 수 있습니다. 이렇게 하면 첫 번째 포장된 경로가 제공되고 기존 모든 항목은 기본적으로 저장되지 않습니다. 그러면 비포장 경로의 개발 팀은 새 포장된 경로가 조직에 가치를 표시하면 이동하는 것을 고려합니다. 이 시점에서 개발 팀은 이를 세금이 아닌 혜택으로 간주하기 때문에 양방향 통신을 통해 원하는 상태의 모든 사람을 얻기 위한 올바른 캠페인을 실행할 수 있습니다. 캠페인 기간 동안 플랫폼 엔지니어링 팀은 팀 마이그레이션을 돕는 데 집중할 수 있으며, 개발 팀은 포장된 경로를 더 잘 만드는 방법에 대한 피드백을 제공합니다.
어쨌든, 포장 된 경로의 사용을 의무화하지 마십시오. 포장된 경로를 롤아웃하는 가장 효과적인 방법은 강제 채택보다는 팀이 어떤 팀에서 나가는지 강조하는 것입니다. 내부 개발자 플랫폼은 이와 똑같은 팀을 행복하게 만드는 데 중점을 두기 때문에 개별 리더에 대한 예산 및 가치 창출 시간 압박은 나머지를 처리합니다. 올바른 캠페인을 얻으려면 비포장 경로에 있는 사용자가 전환하는 가장 좋은 방법으로 양방향 대화를 할 수 있는 방법을 제공합니다.
개발자 자동화 도구를 사용하여 포장된 경로에 대한 셀프 서비스 개선
첫 번째 경로 만들기의 일부는 핵심 개발자 자동화 제품을 설정하는 것입니다. 개발자 셀프 서비스 기능을 사용하도록 설정하는 방법에 대해 생각하기 시작하면 이러한 기능이 중요합니다.
지속적인 업데이트 중에 자동 애플리케이션 인프라 프로비저닝 사용
아직 구현되지 않은 경우 계획 중에 식별한 문제는 CI(연속 통합) 및 CD(지속적인 업데이트)가 해결하는 데 도움이 될 수 있는 문제를 가리킬 수 있습니다. 이 공간에는 Flux 또는 Argo CD와 같은 끌어오기 기반 GitOps 솔루션과 함께 GitHub Actions, Azure DevOps, Jenkins와 같은 제품이 있습니다. Microsoft DevOps 리소스 센터에서 이러한 항목을 시작할 수 있습니다.
기존 인프라에서 애플리케이션을 지속적으로 배포하는 방법을 이미 구현한 경우에도 IaC(Infrastructure as code)를 사용하여 CD 파이프라인의 일부로 필요한 애플리케이션 인프라를 만들거나 업데이트하는 것이 좋습니다.
예를 들어 GitHub Actions를 사용하여 인프라를 업데이트하고 Azure Kubernetes Service에 배포하는 두 가지 방법, 즉 푸시 기반 배포를 사용하는 방법 및 끌어오기 기반(GitOps) 배포를 보여 주는 다음 그림을 고려해 보세요.
선택한 것은 기존 IaC 기술 집합 및 대상 애플리케이션 플랫폼의 세부 정보에 의해 결정됩니다. GitOps 접근 방식은 최신 버전이며 애플리케이션의 기반으로 Kubernetes를 사용하는 조직에서 널리 사용되고 있으며, 풀 기반 모델은 현재 사용 가능한 옵션 수를 고려할 때 유연성을 가장 많이 제공합니다. 대부분의 조직에서는 이 두 가지를 혼합하여 사용할 것으로 예상합니다. 그럼에도 불구하고 IaC 사례에 정통하게 되면 추가 자동화 시나리오에 적용되는 패턴을 배우는 데 도움이 됩니다.
카탈로그 또는 레지스트리에서 IaC를 중앙 집중화하여 보안 확장 및 개선
애플리케이션 간에 IaC를 관리하고 크기를 조정하려면 재사용을 위해 IaC 아티팩트 중앙에 게시해야 합니다. 예를 들어 Azure Container Registry(ACR), DockerHub 또는 ADE(Azure Deployment Environments)의 카탈로그와 같은 클라우드 네이티브 OCI 아티팩트 레지스트리에 저장된 레지스트리, Bicep 모듈, Radius 레시피 또는 Helm 차트에서 Terraform 모듈 을 사용할 수 있습니다. GitOps 및 Kubernetes의 경우 클러스터 API(및 CAPZ와 같은 구현)를 사용하면 Kubernetes 워크로드 클러스터를 관리할 수 있으며, Azure 서비스 운영자와 같은 사용자 지정 리소스 정의는 다른 종류의 Azure 리소스에 대한 추가 지원을 제공할 수 있으며, 크로스플레인과 같은 다른 도구는 여러 클라우드에서 리소스를 지원합니다. 이를 통해 ACR과 같은 항목에서 중앙 집중식 또는 일반 Helm 차트를 사용하여 광범위한 시나리오를 사용할 수 있습니다.
IaC를 중앙 집중화하면 더 이상 애플리케이션 코드와 함께 저장되지 않으므로 업데이트를 수행할 수 있는 사용자를 더 잘 제어할 수 있으므로 보안이 향상됩니다. 전문가, 운영 또는 플랫폼 엔지니어가 필요한 변경을 수행할 때 코드 업데이트 중에 실수로 인한 실수로 중단될 위험이 적습니다. 또한 개발자는 완전한 IaC 템플릿을 직접 작성할 필요가 없고 인코딩된 모범 사례를 통해 자동으로 이점을 얻을 수 있기 때문에 이러한 구성 요소의 이점을 누릴 수 있습니다.
선택하는 IaC 형식은 기존 기술 집합, 필요한 컨트롤 수준 및 사용하는 앱 모델에 따라 달라집니다. 예를 들어 ACA(Azure Container Apps) 및 최근 실험적 Radius OSS 인큐베이션 프로젝트는 Kubernetes를 직접 사용하는 것보다 더 많은 의견을 제시하지만 개발자 환경을 간소화합니다. 클라우드 서비스 유형 설명 학습 모듈은 다양한 모델의 장단점을 이해하는 데 도움이 될 수 있습니다. 그럼에도 불구하고 원본 트리에서 완전한 정의를 갖는 대신 중앙 집중식 및 관리되는 IaC를 참조하면 상당한 이점이 있습니다.
개발자가 거버넌스를 위한 기본 구성 요소에서 계층에 직접 액세스할 수 없는 방식으로 필요한 프로비전 ID 또는 비밀을 유지합니다. 예를 들어 ADE(Azure Deployment Environments)를 사용하여 수행할 수 있는 역할 분리에 대한 이 그림을 생각해 보세요.
여기서 플랫폼 엔지니어 및 기타 전문가는 IaC 및 기타 템플릿을 개발하고 카탈로그에 배치합니다. 그러면 작업에서 "환경 유형"으로 관리 ID 및 구독을 추가하고 프로비전에 사용할 수 있는 개발자 및 기타 사용자를 할당할 수 있습니다.
개발자 또는 CI/CD 파이프라인은 Azure CLI 또는 Azure 개발자 CLI를 사용하여 기본 구독 또는 ID에 액세스하지 않고도 미리 구성되고 제어된 인프라를 프로비전할 수 있습니다. ADE와 같은 항목을 사용하든 그렇지 않든 간에 선택한 지속적인 배달 시스템은 비밀을 분리하고 개발자가 직접 액세스하거나 수정할 수 없는 위치에서 IaC 콘텐츠를 소싱하여 인프라를 안전하고 안전하게 업데이트하는 데 도움이 될 수 있습니다.
애플리케이션 지속적인 업데이트 이외의 시나리오에서 셀프 서비스 사용
CI 및 CD 개념은 애플리케이션 개발에 연결되어 있지만 내부 고객이 프로비전하려는 많은 항목은 특정 애플리케이션과 직접 연결되지 않습니다. 공유 인프라, 리포지토리 만들기, 프로비전 도구 등이 될 수 있습니다.
이것이 도움이 될 수 있는 위치를 이해하려면 현재 수동 또는 서비스 데스크 기반 프로세스가 있는 위치를 생각해 보세요. 각각에 대해 다음 질문에 대해 생각해 보십시오.
- 이 프로세스는 얼마나 자주 발생하나요?
- 프로세스가 느리거나 오류가 발생하기 쉽거나 상당한 작업이 필요한가요?
- 필요한 승인 단계 또는 단순히 자동화 부족으로 인해 이러한 프로세스가 수동입니까?
- 승인자는 소스 제어 시스템 및 끌어오기 요청 프로세스에 익숙합니까?
- 프로세스에 대한 감사 요구 사항은 무엇인가요? 소스 제어 시스템의 감사 요구 사항과 다른가요?
- 더 복잡한 프로세스로 이동하기 전에 위험이 낮은 프로세스로 시작할 수 있습니까?
자주, 높은 노력 또는 오류가 발생하기 쉬운 프로세스를 먼저 자동화할 수 있는 잠재적 대상으로 식별합니다.
모든 항목을 코드 패턴으로 사용
git의 보편성 외에도 Git에 대한 좋은 점 중 하나는 안전하고 감사 가능한 정보 원본이 될 수 있다는 것입니다. 커밋 기록 및 액세스 제어 외에도 끌어오기 요청 및 분기 보호와 같은 개념은 주 분기에 병합하기 전에 전달해야 하는 특정 검토자, 대화 기록 및 자동화된 검사를 설정하는 방법을 제공합니다. CI/CD 시스템에 있는 것과 같은 유연한 작업 엔진과 결합하면 보안 자동화 프레임워크가 있습니다.
코드로 모든 것을 숨기는 아이디어는 거의 모든 것을 보안 git 리포지토리의 파일로 전환할 수 있다는 것입니다. 리포지토리에 연결된 다른 도구 또는 에이전트는 콘텐츠를 읽을 수 있습니다. 모든 항목을 코드로 처리하면 템플릿을 통해 반복성이 향상되고 개발자 셀프 서비스가 간소화됩니다. 이 작업이 어떻게 작동하는지에 대한 몇 가지 예를 살펴보겠습니다.
인프라에 IaC 패턴 적용
IaC는 애플리케이션 배달을 자동화하는 데 큰 인기를 얻었지만, 이 패턴은 특정 애플리케이션에 연결된 인프라, 도구 또는 서비스뿐만 아니라 프로비전 및 구성하려는 모든 인프라, 도구 또는 서비스로 확장됩니다. 예를 들어 Flux가 설치된 클러스터를 사용하여 K8을 공유하거나, 여러 팀과 애플리케이션에서 사용하는 DataDog와 같은 항목을 프로비전하거나, 즐겨 찾는 공동 작업 도구를 설정하기도 합니다.
이렇게 작동하는 방식은 프로비전 및 구성해야 하는 항목을 나타내는 일련의 파일을 보관하는 별도의 보안 중앙 집중식 리포지토리가 있다는 것입니다(이 경우 Bicep, Terraform, Helm 차트 및 기타 Kubernetes 네이티브 형식에 이르기까지). 운영 팀 또는 다른 관리자 집합은 리포지토리를 소유하고 개발자(또는 시스템)는 끌어오기 요청을 제출할 수 있습니다. 이러한 관리자가 이러한 PR을 주 분기에 병합하면 애플리케이션 개발 중에 사용되는 동일한 CI/CD 도구가 변경 내용을 처리하기 시작할 수 있습니다. Azure 배포 환경에 보관된 GitHub Actions 및 IaC 및 배포 ID를 사용하는 이 그림을 고려합니다.
애플리케이션 배포에 GitOps 접근 방식을 이미 사용하고 있는 경우 이러한 도구도 다시 사용할 수 있습니다. Flux 및 Azure 서비스 운영자와 같은 도구를 결합하면 Kubernetes 외부에서 확장할 수 있습니다.
두 경우 모두 애플리케이션에 대해 생성되지 않더라도 완전히 관리되고 재현 가능하며 감사 가능한 정보 원본이 있습니다. 애플리케이션 개발과 마찬가지로 필요한 비밀 또는 관리 ID는 파이프라인/워크플로 엔진 또는 프로비전 서비스의 네이티브 기능에 저장됩니다.
PR을 만드는 사용자는 이러한 비밀에 직접 액세스할 수 없으므로 개발자가 직접 수행할 수 있는 권한이 없는 작업을 안전하게 시작할 수 있습니다. 이렇게 하면 개발자에게 셀프 서비스 옵션을 제공하면서 최소 권한 원칙을 준수할 수 있습니다.
프로비전된 인프라 추적
이 접근 방식의 크기를 조정하기 시작하면 프로비전된 인프라를 추적하는 방법을 생각해 보세요. Git 리포지토리는 구성의 소스이지만 만든 항목에 대한 특정 URI 및 상태 정보를 알려주지는 않습니다. 그러나 코드 접근 방식에 따라 프로비전된 인프라의 인벤토리를 합성하기 위해 활용할 수 있는 정보 원본을 제공합니다. 프로비저닝기는 이 정보를 활용할 수 있는 좋은 소스일 수도 있습니다. 예를 들어 Azure 배포 환경에는 개발자가 볼 수 있는 환경 추적 기능이 포함되어 있습니다.
다양한 데이터 원본을 추적하는 방법에 대한 자세한 내용은 개발자 셀프 서비스 기반 디자인을 참조하세요.
코드를 사용하여 보안 및 정책을 코드 패턴으로 적용
인프라 프로비전은 유용하지만 이러한 환경이 안전하고 일반적으로 조직의 정책을 따르는지 확인하는 것이 똑같이 중요합니다. 이로 인해 "코드로서의 정책" 개념이 증가했습니다. 여기서는 소스 제어 리포지토리의 구성 파일을 사용하여 보안 검색을 구동하거나 인프라 정책을 적용하는 등의 작업을 수행할 수 있습니다.
Azure Policy, Open Policy Agent, GitHub Advanced Security 및 GitHub CODEOWNERS를 비롯한 다양한 제품 및 오픈 소스 프로젝트에서 이 접근 방식을 지원했습니다. 애플리케이션 인프라, 서비스 또는 도구를 선택할 때 이러한 패턴을 얼마나 잘 지원하는지 평가해야 합니다. 애플리케이션 및 거버넌스 구체화에 대한 자세한 내용은 애플리케이션 플랫폼 구체화를 참조하세요.
사용자 고유의 시나리오에 대한 코드로 모든 항목 사용
코드로서의 모든 것은 이러한 패턴을 IaC 이외의 다양한 자동화 및 구성 작업으로 확장합니다. 모든 유형의 인프라를 만들거나 구성할 뿐만 아니라 모든 다운스트림 시스템에서 데이터를 업데이트하거나 워크플로를 트리거하도록 지원할 수 있습니다.
PR은 다양한 프로세스( 특히 시작할 때)에 적합한 기준 셀프 서비스 사용자 환경이 됩니다. 프로세스는 git 자체에서 제공하는 보안, 감사 가능성 및 롤백 이점을 자연스럽게 얻으며, 관련 시스템은 사용자 환경에 영향을 주지 않으면서 시간이 지남에 따라 변경될 수도 있습니다.
Teams를 코드로
사용자 고유의 시나리오에 코드로 모든 것을 적용하는 한 가지 예는 코드 패턴으로 Teams입니다. 조직은 이 패턴을 적용하여 팀 멤버 자격을 표준화하고, 경우에 따라 다양한 시스템에서 개발자 도구/서비스 자격을 표준화합니다. 이 패턴은 시스템 개발자와 운영자가 자신의 그룹화, 사용자 및 액세스 개념에 액세스해야 하는 필요에 따라 수동 온보딩 및 오프보딩 서비스 데스크 프로세스를 제거합니다. 수동 서비스 데스크 프로세스는 액세스를 과도하게 프로비전할 수 있으므로 잠재적인 보안 위험입니다. 팀을 코드 패턴으로 사용하는 경우 git 및 끌어오기 요청의 조합은 감사 가능한 데이터 원본에서 셀프 서비스를 사용하도록 설정할 수 있습니다.
이 패턴의 성숙하고 광범위한 변형에 대한 예제를 보려면 자격 관리 방법에 대한 GitHub의 블로그 게시물을 확인 하세요. 또한 GitHub는 사용자가 사용해 보거나 채택할 수 있도록 정교한 권한 구현 을 오픈 소스로 제공합니다. 블로그 게시물에서는 모든 직원 자격을 설명하지만, 더 좁은 범위의 개발 팀 시나리오에 팀을 코드 개념으로 적용할 수 있습니다. 이러한 개발 팀은 직원 조직도에 전혀 표시되지 않을 수 있으며 팀 구성원의 온보딩 또는 오프보딩을 복잡하게 만들 수 있는 독점 도구 또는 서비스를 포함할 수 있습니다.
CI/CD 시스템 및 ID 공급자 그룹을 사용하여 업데이트를 조정하는 이 아이디어의 간소화된 변형에 대한 요약은 다음과 같습니다.
이 예에서는 다음이 적용됩니다.
- 관련된 각 시스템은 SSO(Single Sign-On)에 ID 공급자(예: Microsoft Entra ID)를 사용하도록 설정되었습니다.
- 시스템 전체에서 ID 공급자 그룹(예: Entra 그룹)을 사용하여 역할별로 멤버 자격을 관리하여 복잡성을 줄이고 중앙 집중식 감사를 유지합니다.
높은 수준에서 이 패턴의 작동 방식은 다음과 같습니다.
- 잠긴 중앙 git 리포지토리에는 각 추상 팀, 관련 사용자 멤버 자격 및 사용자 역할을 나타내는 일련의(일반적으로 YAML) 파일이 있습니다. 팀 변경에 대한 소유자 또는 승인자는 이 같은 위치에 저장할 수도 있습니다(예: CODEOWNERS를 통해). 이러한 파일의 사용자에 대한 참조는 ID 공급자이지만 이 리포지토리는 이러한 팀(사용자 아님)에 대한 진실의 근원 역할을 합니다.
- 이러한 파일에 대한 모든 업데이트는 끌어오기 요청을 통해 수행됩니다. 이는 감사 가능성을 위해 git 커밋 요청에 대한 대화 및 관련 참가자를 연결합니다.
- 잠재 고객 및 개별 사용자는 사용자를 추가/제거하는 PR을 만들 수 있으며, 개발 리드 및 기타 역할은 템플릿의 새 팀 파일과 함께 PR을 사용하여 새 팀을 만들 수 있습니다.
- PR이 기본으로 병합될 때마다 리포지토리에 연결된 CI/CD 시스템은 ID 공급자 시스템 및 모든 다운스트림 시스템을 적절하게 업데이트합니다.
특히 CI/CD 시스템은 다음과 같습니다.
- 적절한 ID 공급자 시스템 API를 사용하여 역할당 ID 공급자 그룹을 파일의 개인과 정확히 일치하도록 만들거나 업데이트합니다(더 이상, 더 이상 없음).
- 각 다운스트림 시스템에 대한 API를 사용하여 이러한 시스템 그룹화 개념을 각 역할에 대한 식별 공급자 그룹(예: GitHub 및 Azure DevOps)에 연결합니다. 이로 인해 역할을 나타내는 팀과 다운스트림 시스템 간에 일대다 관계가 발생할 수 있습니다.
- (선택 사항) 각 다운스트림 시스템에 API를 사용하여 시스템의 그룹화 메커니즘에 연결된 권한 논리를 구현합니다.
- API를 사용하여 잠긴 데이터 저장소를 내부적으로 빌드된 시스템에 사용할 수 있는 결과(다운스트림 시스템 팀 ID 연결 포함)로 업데이트합니다. 필요한 경우 동일한 ID 공급자 사용자/계정에 대한 사용자 ID의 다양한 시스템 표현에 대한 연결을 여기에 저장할 수도 있습니다.
조직에서 이미 Entra 권한 관리와 같은 항목을 사용하고 있는 경우 이 패턴에서 그룹 멤버 자격 관리를 생략할 수 있습니다.
요구 사항 및 정책은 세부 사항을 변경할 수 있지만 일반적인 패턴은 다양한 변형에 맞게 조정할 수 있습니다. 다운스트림 시스템과 통합하는 데 필요한 모든 비밀은 CI/CD 시스템(예: GitHub Actions, Azure Pipelines) 또는 Azure Key Vault에서 유지 관리됩니다.
수동 또는 외부로 트리거되고 매개 변수가 있는 워크플로 사용
식별한 셀프 서비스 관련 문제 중 일부는 Git에서 파일을 사용하는 데 도움이 되지 않을 수 있습니다. 또는 셀프 서비스 환경을 구동하는 데 사용하려는 사용자 인터페이스가 있을 수 있습니다.
다행히 GitHub Actions 및 Azure Pipelines를 비롯한 대부분의 CI 시스템은 입력을 사용하여 워크플로를 설정한 다음 UI 또는 UI를 통해 수동으로 트리거할 수 있습니다. 개발자 및 관련 작업 역할이 이러한 사용자 환경에 이미 익숙한 경우 수동 트리거는 모든 것을 코드 패턴으로 보강하여 자연 파일 표현이 없거나 PR 프로세스를 요구하지 않고 완전히 자동화되어야 하는 활동(또는 작업)에 대한 자동화를 가능하게 할 수 있습니다.
CI 시스템을 사용하면 API를 통해 사용자 고유의 사용자 환경에서 이러한 워크플로 또는 파이프라인을 트리거하도록 옵트인할 수 있습니다. GitHub Actions의 경우 이 작업을 만드는 핵심은 워크플로 실행을 트리거하기 위해 워크플로 디스패치 이벤트를 실행하는 Actions REST API입니다. Azure DevOps 트리거는 유사하며 실행에 Azure DevOps Pipeline API 를 사용할 수도 있습니다. 다른 제품에서도 동일한 기능을 볼 수 있습니다. 수동으로 트리거하든 API를 통해 트리거되든, 각 워크플로는 워크플로 YAML 파일에 workflow_dispatch 구성을 추가하여 입력 집합을 지원할 수 있습니다. 예를 들어 Backstage.io 같은 포털 도구 키트가 GitHub Actions와 상호 작용하는 방법입니다.
CI/CD 시스템의 워크플로 또는 작업 시스템은 의심할 여지 없이 활동을 추적하고, 상태를 보고하며, 개발자와 운영 팀이 무엇이 잘못되었는지 확인하는 데 사용할 수 있는 자세한 로그를 포함합니다. 이러한 방식으로 코드 패턴과 동일한 보안, 감사 가능성 및 가시성 이점이 있습니다. 그러나 이러한 워크플로 또는 파이프라인에서 수행하는 모든 작업은 다운스트림 시스템에 대한 시스템 ID(예: Microsoft Entra ID의 서비스 주체 또는 관리 ID)처럼 보입니다.
CI/CD 시스템에서 요청을 시작하는 사용자를 볼 수 있지만, 이 정보가 충분한지 여부를 평가하고 CI/CD 보존 설정이 이 정보가 중요한 경우의 감사 요구 사항을 준수하는지 확인해야 합니다.
다른 경우와 통합하는 도구에는 사용자가 사용할 수 있는 자체 추적 메커니즘이 있을 수 있습니다. 예를 들어 이러한 CI/CD 도구에는 거의 항상 Microsoft Teams 또는 Slack 채널을 사용하는 것과 같은 몇 가지 알림 메커니즘을 사용할 수 있으며, 이를 통해 상태 업데이트를 받기 위한 요청을 제출하는 모든 사용자를 유지할 수 있으며 채널은 어떤 일이 일어났는지에 대한 비공식적인 레코드를 제공합니다. 이러한 동일한 워크플로 엔진은 이러한 패턴의 유용성을 더욱 확장하기 위해 운영 도구와 통합되도록 이미 설계된 경우가 많습니다.
요약하면 CI/CD 도구의 유연성과 기본 사용자 환경 덕분에 소스 제어 리포지토리에 저장된 파일을 사용하여 일부 자동화를 구현할 수 있습니다. 내부 개발자 플랫폼이 시간이 지남에 따라 보다 정교한 기능을 손상시키지 않고 이 방법을 시작점으로 사용할 수 있는 방법을 알아보려면 개발자 셀프 서비스 기반 디자인을 참조하세요.
개발자 코딩 환경 설정 자동화
엔지니어링 시스템의 또 다른 일반적인 문제는 개발자 코딩 환경 부트스트래핑 및 정규화입니다. 다음은 이 영역에서 들을 수 있는 몇 가지 일반적인 문제입니다.
- 경우에 따라 개발자가 첫 번째 끌어오기 요청에 도착하는 데 몇 주가 걸릴 수 있습니다. 이는 기능 승무원과 프로젝트 간에 개발자를 상당히 자주(예: 행렬화된 조직에서) 이전하거나, 계약자를 강화해야 하거나, 채용 단계에 있는 팀에 있는 경우 문제가 되는 영역입니다.
- 개발자와 CI 시스템 간의 불일치로 인해 숙련 된 팀 구성원의 경우에도 자주 "내 컴퓨터에서 작동"문제가 발생할 수 있습니다.
- 프레임워크, 런타임 및 기타 소프트웨어를 실험하고 업그레이드하면 기존 개발자 환경이 중단되고 무엇이 잘못되었는지 정확히 파악하는 데 걸리는 시간이 손실됩니다.
- 개발 리드의 경우, 검토가 완료되면 테스트 및 실행 취소하기 위해 구성 변경이 필요할 수 있으므로 코드 검토로 인해 개발 속도가 느려질 수 있습니다.
- 또한 팀 구성원과 운영자는 개발(운영자, QA, 비즈니스, 스폰서)을 넘어 관련 역할을 강화하여 팀이 수행하는 작업을 테스트하고, 진행 상황을 보고, 비즈니스 역할을 교육하고, 전도하는 데 시간을 할애해야 합니다.
포장된 경로의 일부
이러한 문제를 해결하려면 잘 정의된 포장 경로의 일부로 특정 도구 및 유틸리티를 설정하는 방법을 생각해 보세요. 개발자 컴퓨터 설치를 스크립팅하면 도움이 될 수 있으며 CI 환경에서 이러한 동일한 스크립트를 다시 사용할 수 있습니다. 그러나 제공할 수 있는 이점 때문에 컨테이너화되거나 가상화된 개발 환경을 지원하는 것이 좋습니다. 이러한 코딩 환경은 조직 또는 프로젝트의 사양에 따라 미리 설정할 수 있습니다.
워크스테이션 교체 및 Windows 대상 지정
Windows를 대상으로 하거나 전체 워크스테이션 가상화(프로젝트별 설정 외에도 클라이언트 도구 및 호스트 OS 설정)를 수행하려는 경우 VM은 일반적으로 최상의 기능을 제공합니다. 이러한 환경은 Windows 클라이언트 개발에서 Windows 서비스 또는 .NET 전체 프레임워크 웹 애플리케이션 관리 및 유지 관리에 이르기까지 모든 경우에 유용할 수 있습니다.
| 접근 방식 | 예제 |
|---|---|
| 클라우드 호스팅 VM 사용 | Microsoft Dev Box 는 데스크톱 관리 소프트웨어에 기본 제공 통합된 전체 Windows 워크스테이션 가상화 옵션입니다. |
| 로컬 VM 사용 | Hashicorp Vagrant는 좋은 옵션이며 HashiCorp Packer를 사용하여 VM 이미지와 Dev Box를 모두 빌드할 수 있습니다. |
작업 영역 가상화 및 Linux 대상 지정
Linux를 대상으로 하는 경우 작업 영역 가상화 옵션을 고려합니다. 이러한 옵션은 개발자 데스크톱을 대체하는 데 초점을 맞추지 않고 프로젝트 또는 애플리케이션 특정 작업 영역에서 더 많이 사용합니다.
| 접근 방식 | 예제 |
|---|---|
| 클라우드 호스팅 컨테이너 사용 | GitHub Codespaces 는 VS Code, JetBrains의 IntelliJ 및 터미널 기반 도구와의 통합을 지원하는 Dev Containers용 클라우드 기반 환경입니다. 이 서비스 또는 유사한 서비스가 요구 사항을 충족하지 않는 경우 원격 Linux VM의 Dev Containers에서 VS Code의 SSH 또는 원격 터널 지원을 사용할 수 있습니다. 클라이언트뿐만 아니라 웹 기반 vscode.dev 작동하는 터널 기반 옵션입니다. |
| 로컬 컨테이너 사용 | 대신 로컬 Dev Containers 옵션을 사용하거나 클라우드에 호스트되는 옵션을 선호하는 경우 Dev Containers는 VS Code, IntelliJ 지원 및 기타 도구 및 서비스에서 견고한 지원을 제공합니다. |
| 클라우드 호스팅 VM 사용 | 컨테이너가 너무 제한적인 경우 VS Code 또는 IntelliJ와 같은 JetBrains 도구와 같은 도구에서 SSH 지원을 사용하면 직접 관리하는 Linux VM에 직접 연결할 수 있습니다. VS Code에는 터널 기반 옵션 도 여기에서 작동합니다. |
| Linux용 Windows 하위 시스템 사용 | 개발자가 Windows 전용인 경우 WSL(Linux용 Windows 하위 시스템)은 개발자가 Linux를 로컬로 대상으로 지정할 수 있는 좋은 방법입니다. 팀에 대한 WSL 배포를 내보내고 설정된 모든 항목과 공유할 수 있습니다. 클라우드 옵션의 경우 Microsoft Dev Box와 같은 클라우드 워크스테이션 서비스는 WSL을 활용하여 Linux 개발을 대상으로 할 수도 있습니다. |
올바른 구성 유지를 포함하는 시작 오른쪽 애플리케이션 템플릿 만들기
코드 패턴인 모든 항목의 장점은 개발자가 처음부터 설정한 포장된 경로를 유지할 수 있다는 것입니다. 이것이 조직에 어려운 과제인 경우 애플리케이션 템플릿은 구성 요소를 다시 사용하여 일관성을 높이고, 표준화를 촉진하고, 조직의 모범 사례를 명문화하는 중요한 방법이 될 수 있습니다.
시작하려면 GitHub 템플릿 리포지토리처럼 간단한 항목을 사용할 수 있지만 조직에서 모노레포 패턴을 따르는 경우 덜 효과적일 수 있습니다. 애플리케이션 원본 트리와 직접 관련이 없는 항목을 설정하는 데 도움이 되는 템플릿을 만들 수도 있습니다. 대신 쿠키커터, Yeoman 또는 Azure 개발자 CLI(azd)와 같은 템플릿 엔진을 사용할 수 있습니다. 이 엔진은 템플릿 및 간소화된 CI/CD 설정 외에도 편리한 개발자 명령 집합을 제공합니다. Azure 개발자 CLI는 모든 시나리오에서 환경 설정을 구동하는 데 사용할 수 있으므로 Azure 배포 환경과 통합되어 향상된 보안, 통합된 IaC, 환경 추적, 문제 분리 및 간소화된 CD 설정을 제공합니다.
템플릿 집합이 있으면 개발 리더는 이러한 명령줄 도구 또는 기타 통합 사용자 환경을 사용하여 애플리케이션에 대한 콘텐츠를 스캐폴드할 수 있습니다. 그러나 개발자는 템플릿에서 리포지토리 또는 기타 콘텐츠를 만들 수 있는 권한이 없을 수 있으므로 수동으로 트리거되고 매개 변수가 있는 워크플로/파이프라인을 사용할 수도 있습니다. CI/CD 시스템에서 리포지토리에서 인프라에 이르는 모든 항목을 대신 만들도록 입력을 설정할 수 있습니다.
올바른 상태를 유지하고 올바르게 유지
그러나 크기를 조정하기 위해 이러한 애플리케이션 템플릿은 가능한 경우 중앙 집중식 구성 요소(예: IaC 템플릿 또는 CI/CD 워크플로/파이프라인)를 참조해야 합니다. 실제로 이러한 중앙 집중식 구성 요소를 고유한 형태의 시작 오른쪽 템플릿으로 처리하는 것은 식별한 몇 가지 문제를 해결하는 효과적인 전략이 될 수 있습니다.
이러한 각 개별 템플릿은 새 애플리케이션뿐만 아니라 업데이트되거나 개선된 지침을 롤아웃하기 위한 올바른 가져오기 캠페인의 일환으로 업데이트하려는 기존 템플릿에도 적용할 수 있습니다. 이 중앙 집중화를 사용하면 새로운 애플리케이션과 기존 애플리케이션을 모두 올바르게 유지하여 시간이 지남에 따라 모범 사례를 발전하거나 확장할 수 있습니다.
템플릿 내용
템플릿을 만들 때 다음 영역을 고려하는 것이 좋습니다.
| 지역 | 세부 정보 |
|---|---|
| 앱 패턴, SDK 및 도구 사용을 구동하기에 충분한 샘플 소스 코드 | 권장 언어, 앱 모델 및 서비스, API, SDK 및 아키텍처 패턴으로 개발자를 유도하는 코드 및 구성을 포함합니다. 선택한 도구를 사용하여 분산 추적, 로깅 및 관찰 가능성을 위한 코드를 포함해야 합니다. |
| 빌드 및 배포 스크립트 | 개발자에게 빌드 및 로컬/샌드박스 배포를 트리거하는 일반적인 방법을 제공합니다. 사용할 도구에 대한 IDE 내/편집기 디버그 구성을 포함합니다. 이는 유지 관리 문제를 방지하고 CI/CD가 동기화되지 않도록 방지하는 중요한 방법입니다. 템플릿 엔진이 Azure 개발자 CLI와 같은 의견으로 표시되는 경우 방금 사용할 수 있는 명령이 이미 있을 수 있습니다. |
| CI/CD에 대한 구성 | 권장 사항에 따라 애플리케이션을 빌드하고 배포하기 위한 워크플로/파이프라인을 제공합니다. 중앙 집중식, 재사용 가능 또는 템플릿 워크플로 /파이프라인을 활용하여 최신 상태로 유지할 수 있습니다. 실제로 이러한 재사용 가능한 워크플로/파이프라인은 자체 템플릿을 시작할 수 있습니다. 이러한 워크플로를 수동으로 트리거하는 옵션을 고려해야 합니다. |
| 코드 자산으로서의 인프라 | 인프라 설정이 처음부터 모범 사례를 따르도록 중앙에서 관리되는 모듈 또는 카탈로그 항목 에 대한 참조를 포함하여 권장되는 IaC 구성을 제공합니다. 이러한 참조는 시간이 지남에 따라 팀이 올바르게 유지하는 데 도움이 될 수도 있습니다. 워크플로/파이프라인과 결합하면 거의 모든 것을 프로비전하는 IaC 또는 EaC를 포함할 수도 있습니다. |
| 코드 자산으로서의 보안 및 정책 | DevSecOps 이동은 템플릿에 적합한 코드로 보안 구성을 이동했습니다. 코드 아티팩트로서의 일부 정책은 애플리케이션 수준에서도 적용할 수 있습니다. CODEOWNERS와 같은 파일부터 GitHub Advanced Security의 dependabot.yaml과 같은 구성 검사에 이르기까지 모든 항목을 포함합니다. 환경 테스트 실행과 함께 클라우드용 Defender 같은 항목을 사용하여 예약된 워크플로/파이프라인 실행을 검사에 제공합니다. 이는 공급망 보안에 중요하며 애플리케이션 패키지 및 코드 외에도 컨테이너 이미지를 고려해야 합니다. 이러한 단계는 개발 팀이 올바르게 유지하는 데 도움이 됩니다. |
| 관찰 가능성, 모니터링 및 로깅 | 셀프 서비스를 사용하도록 설정하면 배포된 애플리케이션을 쉽게 볼 수 있습니다. 런타임 인프라 외에도 관찰 가능성 및 모니터링에 대한 설정을 포함해야 합니다. 대부분의 경우 IaC 측면 설정(예: 에이전트 배포, 계측)이 있는 반면, 다른 경우에는 다른 유형의 구성 코드 아티팩트(예: Azure 애플리케이션 Insights에 대한 대시보드 모니터링)일 수 있습니다. 마지막으로 선택한 도구를 사용하여 분산 추적, 로깅 및 관찰성을 위한 코드 샘플 코드를 포함해야 합니다. |
| 코딩 환경 설정 | Linter, 포맷터, 편집기 및 IDE 코딩을 위한 구성 파일을 포함합니다. devcontainer.json, devbox.yaml, 개발자 중심 Dockerfiles, Docker Compose 파일 또는 Vagrantfiles와 같은 작업 영역 또는 워크스테이션 가상화 파일과 함께 설치 스크립트를 포함합니다. |
| 테스트 구성 | UI용 Microsoft Playwright Testing 또는 Azure Load Testing과 같은 기본 서비스를 사용하여 단위 및 더 심층 테스트 모두에 대한 구성 파일을 제공합니다. |
| 공동 작업 도구 설정 | 문제 관리 및 소스 제어 관리 시스템에서 작업/문제/PR 템플릿을 코드로 지원하는 경우 이러한 템플릿도 포함합니다. 더 많은 설정이 필요한 경우 필요에 따라 사용 가능한 CLI 또는 API를 사용하여 시스템을 업데이트하는 워크플로/파이프라인을 제공할 수 있습니다. 이렇게 하면 Microsoft Teams 또는 Slack과 같은 다른 공동 작업 도구를 설정할 수도 있습니다. |