다음을 통해 공유

개발자 셀프 서비스 기반 디자인

  • 아티클

엔지니어링 시스템의 목표를 잘 이해하면 보다 정교한 개발자 셀프 서비스 환경을 만들 수 있습니다. 개발자 셀프 서비스 환경은 개념, 패턴 및 구성 요소의 기초를 기반으로 합니다.

현재 조직에서 설명하는 모든 항목이 필요하지는 않지만, 사용자 지정 제품을 빌드하거나 관련 제품을 평가하는 경우 이러한 개념을 염두에 두어야 합니다. 개발자 셀프 서비스 환경 모델은 가정에서 재배한, 기성품 및 오픈 소스 제품의 조합으로 구성될 수 있습니다. 제품 또는 Backstage.io 같은 오픈 소스 포털 도구 키트는 아래에 설명된 모델의 일부 요소에 대해 다른 용어를 사용할 수 있지만 모델은 여전히 방향을 지정하는 데 도움이 될 수 있습니다.

워크플로 자동화, 데이터 집계, 단순 시작 및 점진적으로 확장

목표는 중앙 집중식 가시성과 함께 제어되고 제어된 작업 실행 및 프로비저닝을 통해 가드레일로 셀프 서비스를 사용하도록 설정하는 것입니다. 가장 중요한 영역은 지루하거나 복잡성이나 사용 권한으로 인해 개발자가 스스로 할 수 없는 영역입니다. 이 마지막 조각은 수동 서비스 데스크 프로세스를 통해 개발자를 강제하지 않고 최소 권한의 원칙을 따를 수 있도록 하는 것이 중요합니다.

이러한 요구 사항에 맞게 DevOps 제품군을 확장하도록 선택할 수 있지만 시간이 지남에 따라 여러 애플리케이션 플랫폼을 지원해야 할 수 있으며 이를 지원하는 특정 도구와 프로세스도 변경해야 합니다. 핵심 문제는 표준이 움직이는 대상이라는 것입니다. 한 플랫폼 엔지니어링 실무자는 다음과 같이 말했습니다.

어려움은 표준화를 포함 ... '중단'을 다루는 중... 자동화된 프로세스의 잠재적 중단과 필요한 변경을 식별하는 데 시간이 많이 걸리는 작업으로 인해 표준화가 수행되지 않는 경우가 많습니다. - Martin, DevOps 엔지니어, 대규모 물류 회사

새 표준 또는 업데이트된 표준으로 빠르게 전환하는 것은 일반적으로 불가능하며 기존 프로세스를 중단하면 위험이 발생합니다. 조직에서 이미 여러 DevOps 제품군 또는 시나리오별 개별 도구 및 개발자 서비스의 다양한 조합을 사용하고 있을 수 있습니다. 중앙 팀과 표준 솔루션이 있더라도 셀프 서비스 요구 사항이 증가함에 따라 가변성이 불가피합니다. 따라서 지정된 팀이 새로운 기술, 배포 전략 등을 시도한 다음 의도적인 채택 및 증분 롤아웃을 시도할 수 있는 제어된 실험을 사용하도록 설정하려고 합니다.

일반적으로 셀프 서비스 환경은 자동화 및 데이터 집계의 두 가지 기본 범주로 분류됩니다.

데이터 집계는 좋은 사용자 환경을 만들지만 자동화가 더 중요합니다.

자동화는 핵심이며 모든 사람에게 사랑받을 것입니다. [데이터] 집계는 보조입니다. – Peter, 플랫폼 엔지니어링 리더, 다국적 기술 회사

플랫폼 엔지니어링 과정에서 자동화로 해결할 수 있는 문제를 파악했습니다. 인지 부하 및 개발자 수고를 줄이는 것 외에도 자동화는 애플리케이션이 작업, 보안 및 기타 역할을 수행하는 데 가장 적합한 도구 및 서비스에 연결되도록 하는 데 도움이 될 수 있습니다.

그러나 자동화를 구동하기 위해 둘 이상의 시스템과 함께 작업하는 경우 일부 수준의 데이터 집계는 자동화된 요청 및 관련 결과를 추적하는 데 유용합니다. 먼저 외부 시스템에 연결하여 다른 요구 사항을 충족하거나 세부 정보를 드릴인할 수 있습니다. 데이터 집계 및 가시성은 감사, 거버넌스 및 낭비를 줄이는 데도 중요합니다(예: 사용되지 않는 환경).

인프라 프로비저닝과 같은 자동화는 시스템 통합을 사용하여 수행할 수 있지만 개발자에게 자동화된 수동 워크플로 프로세스를 트리거하고 용이하게 할 수도 있습니다. 이는 플랫폼의 초기 단계, 에코시스템으로 가져오는 새 제품 또는 시스템을 사용하여 자동화할 수 없거나 자동화할 수 없는 영역(예: 소프트웨어 라이선스 할당)에 유용합니다. 올바른 디자인을 사용하면 시간이 지남에 따라 완전히 자동화된 흐름으로 전환하는 Power Automate와 같은 작업을 통해 쉽게 수행할 수 있는 수동 프로세스로 시작할 수 있습니다. 따라서 처음부터 자동화를 위해 디자인합니다.

엔지니어링 시스템 또는 내부 포털과 같은 기존 투자를 다시 사용한 다음, CLI, 기본 웹 페이지 또는 Power Pages, Power BI 또는 Microsoft Fabric 대시보드를 만들고 필요에 따라 확장하여 간단히 시작합니다. UX에서 사용하는 일관된 API를 사용하면 요구 사항 및 기본 설정이 변경됨에 따라 시간이 지남에 따라 여러 인터페이스를 지원할 수 있습니다.

개발자 셀프 서비스 플랫폼 구성 요소: API, 그래프, 오케스트레이터, 공급자 및 메타데이터

개발자 셀프 서비스의 기초를 고려합니다.

개발자 셀프 서비스의 기초 다이어그램.

그림에서 알 수 있듯이 다음 구성 요소는 개발자 셀프 서비스 기반 개념의 핵심을 구성합니다.

구성 요소 설명
개발자 플랫폼 API 사용자 환경을 위한 단일 연락 지점입니다. 이는 사실상 다른 시스템과의 시스템 계약입니다.
개발자 플랫폼 그래프 다양한 종류의 엔터티 및 템플릿을 검색, 연결 및 사용할 수 있는 관리되고 안전한 데이터 그래프입니다. 엔터티는 여러 원본의 데이터 집계를 가능하게 하는 개체이며 템플릿은 자동화를 가능하게 하는 사용자 입력을 구동합니다.
개발자 플랫폼 오케스트레이터 시스템 또는 수동 프로세스를 통해 작업을 수행하기 위해 템플릿 기반 요청을 라우팅하고 추적하는 기능입니다. 이러한 요청은 다양한 워크플로 시스템 또는 기타 서비스에 통합할 수 있는 개발자 플랫폼 공급자 집합 중 하나로 라우팅됩니다.
개발자 플랫폼 공급자 엔터티에 대한 CRUD 작업 및/또는 템플릿 기반 작업 요청의 이행을 지원하기 위해 다운스트림 시스템과 통합하는 데 필요한 논리를 캡슐화하는 구성 요소 집합입니다. 각 공급자는 고유한 특정 형식의 템플릿을 지원하고 고유하거나 일반적인 유형의 엔터티를 내보낼 수 있습니다.
사용자 프로필 및 팀 메타데이터 개발자 플랫폼 API를 그룹화하고 액세스하기 위해 개념적 팀에 연결된 개인 집합에 대한 정보를 유지하는 기능입니다. 사용자는 ID 공급자 계정(예: Microsoft Entra ID 로그인)과 밀접하게 연결되어 있지만, 사용자 계정과 팀 모두 관련 다운스트림 시스템 표현 수에 연결할 수 있습니다. 이 정보 저장소의 한 가지 구현은 개발자 플랫폼 그래프를 다시 사용하는 것입니다. 개발자 셀프 서비스 기반은 사용자와 팀 모두에 공통 엔터티 형식을 설정하고 그래프에 해당 정보를 유지할 수 있습니다. 그러나 여기서는 명확성을 위해 이 저장소를 별도로 유지합니다.

이러한 기본 구성 요소를 사용하면 시간이 지남에 따라 다양한 구성 요소를 사용하고 교체할 수 있습니다.

시작하려면 이 모든 것을 빌드해야 하나요?

아니요. 첫째, 이 모델은 이러한 기반이 완료되면 수행할 수 있어야 하는 작업을 통해 생각하는 데 도움이 되는 개념적 모델입니다. 둘째, 개발자 플랫폼 API가 키 인터페이스가 되는 경우 구현 세부 사항은 여기서 덜 중요합니다. 초기 구현은 다른 제품에 설명되거나 혼합된 여러 계층에 대한 코드의 인터페이스 및 클래스를 사용하여 시작할 수 있습니다. 또한 고객 개발에서 단순히 낮은 우선 순위라고 알려주기 때문에 측면을 생략할 수도 있습니다. 당신이 가지고있는 것으로 시작하고 성장.

개발자 플랫폼 API

시스템 계약으로 작동하도록 개발자 플랫폼 API를 정의해야 합니다. API는 다른 사용자 인터페이스에서 데이터 액세스 또는 드라이브 프로비저닝 및 기타 작업을 사용하도록 설정하는 데 사용됩니다.

이 API는 다른 시스템의 원시 기본 API에 대한 액세스를 보다 구체적이고 제어된 데이터 및 작업으로 제한하여 중요한 인증 및 보안 계층 역할을 합니다. API는 사용자 프로필의 고유한 표현, 플랫폼 내에서 사용자의 상위 수준 역할(팀 구성원, 관리자 등) 및 기본 ID 공급자 시스템 식별자에 대한 액세스를 제공합니다. 자세한 내용은 사용자 및 팀을 참조 하세요.

개발자 플랫폼 공급자

내부 개발자 플랫폼의 폭을 고려하여 확장 가능한 공급자 모델을 따르는 시스템을 만들거나 식별하여 API에 기능을 도입합니다. 자동화 및 데이터 집계와 같은 주요 기능은 잘 정의된 인터페이스를 사용하여 플러그형 구성 요소와 상호 작용하여 제공됩니다. 이 느슨한 결합은 필요한 항목을 증분 방식으로 연결하는 데 도움이 되며, 나머지 기반과 독립적으로 기능을 테스트할 수 있으므로 유지 관리 효율성이 향상됩니다.

또한 플랫폼에 확장 가능한 내부 원본 정신을 사용하도록 설정하는 중요한 방법입니다. 일반적으로 플랫폼 엔지니어링에 대한 내부 소싱 노력은 지속적인 유지 관리 문제로 인해 견인력을 얻지 못합니다. 다른 팀은 기능을 기꺼이 기여할 수 있지만 플랫폼의 핵심 내에서 무언가를 유지 관리하고 테스트할 의향이 적습니다. 반대로 중앙 집중식 팀은 기여된 코드를 유지 관리하거나 끌어오기 요청을 검토할 수 있는 용량이 제한되어 있습니다. 개발자 플랫폼 공급자의 개념은 독립적으로 작성된 코드가 개발자 셀프 서비스 기반 내의 핵심 기능에 "플러그 인"되도록 허용하여 이러한 긴장을 완화합니다. 사용하는 공급자를 신중하게 관리하고, 공급자 코드를 검토하고, 지정된 공급자가 개발자 플랫폼에서 액세스할 수 있는 노출 영역을 제한해야 하지만, 플러그형 접근 방식은 조직의 광범위한 부분에서 노력을 확장하여 더 많은 작업을 수행하는 데 도움이 될 수 있습니다.

주요 개발자 플랫폼 공급자 개념

엔터티

엔터티의 개념은 내부 개발자 플랫폼의 개발자 또는 다른 시스템이 추적, 업데이트, 존재 또는 조치를 취해야 하는 개념입니다. 엔터티는 서로 관계를 맺을 수 있으며, 함께 사용하면 내부 개발자 플랫폼의 조각에 대한 중요한 정보를 제공하는 그래프를 구성할 수 있습니다. 개발자 플랫폼 공급자는 다음을 포함하여 핵심 기능을 사용하도록 엔터티를 출력할 수 있습니다.

  • 검색 및 사용을 위해 외부에서 프로비저닝된 리소스/환경 또는 사용 가능한 API 표시
  • 종속성 분석, 영향 분석, 검색 등에 대한 관계 노출
  • 검색 및 공동 작업을 위한 표면화 유지 관리자/소유권 정보
  • 사용자 환경에서 사용하기 위해 더 많은 데이터 표시

이 기능을 잘 정의된 개발자 플랫폼 공급자 인터페이스로 캡슐화하면 통합 및 테스트가 간소화되고, 독립적인 배포가 가능하며, 기본 내부 개발자 플랫폼 팀 외부의 개발자가 공급자에 기여하고 관리할 수 있습니다. 이는 모든 도구, 서비스 또는 플랫폼이 중앙에서 관리되지는 않지만 더 광범위한 조직에서 여전히 기능을 공유하려는 대규모 또는 부서 조직에서 중요합니다. 따라서 처음에는 이 길을 따라 가지 않더라도 장기적으로 고려해야 할 사항입니다.

일반 속성

각 엔터티에는 Foundation에서 관리할 수 있도록 공통 속성 집합이 있어야 합니다. 고려해야 할 몇 가지 속성은 다음과 같습니다.

  • 고유 식별자
  • 속성
  • 원래 공급자
  • 선택적 연결:
    • 소유 사용자
    • 소유 팀
    • 기타 엔터티

사용자 및 팀 속성은 RBAC(역할 기반 액세스 제어), 검색 및 데이터 집계(예: 팀 수준 요약)의 세 가지 이유로 중요합니다. 처음부터 RBAC에서 빌드하는 것은 보안에 중요하며 시간이 지남에 따라 내부 개발자 플랫폼을 성장시키는 데 중요합니다. 개발이 팀 스포츠라는 점을 감안할 때, 엔터티에 대해 누구와 이야기해야 하는지 발견하는 것은 재사용, 지원 및 내부 소싱에 빠르게 중요해질 것입니다.

일반 및 공급자별 엔터티

또한 여러 공급자가 출력할 수 있는 일반적인 상위 수준 정규화된 엔터티 집합을 설정할 수 있어야 합니다. 예시:

  • 환경
  • 리소스
  • API
  • 리포지토리
  • 구성 요소
  • 도구

일반적으로 C4 모델 컨텍스트 또는 상위 수준 구성 요소 다이어그램에 배치하는 것처럼 높은 수준에 있어야 합니다. 예를 들어 환경의 경우 내부 인프라 토폴로지의 세부 정보를 포함할 필요가 없습니다. 동일한 UX에 있는 여러 공급자의 다양한 개념적 환경을 나열하고 연결할 수 있는 충분한 정보만 있으면 됩니다. 엔터티는 모든 것을 사용하려고 하는 대신 시스템 외부의 세부 수준을 낮출 수 있습니다. 이는 시간이 지남에 따라 데이터 집계를 사용하도록 설정하는 데 핵심적인 검색의 시작점을 제공합니다.

다른 항목은 특정 사용 사례 또는 공급자와 관련이 있으므로 시간이 지남에 따라 증가하는 엔터티 형식 집합을 수용하는 방법을 고려해야 합니다.

템플릿

이 컨텍스트에서 템플릿의 개념은 작업을 추진하기 위한 엔터티의 개념과 다릅니다. 예제 시나리오에는 인프라 프로비저닝, 리포지토리 만들기 및 기타 장기 실행 프로세스가 포함됩니다. 이러한 템플릿은 확장 가능한 개발자 플랫폼 공급자를 통해서도 사용할 수 있어야 하며 엔터티 연결을 포함하여 엔터티와 동일한 공통 속성을 지원해야 합니다.

그러나 시스템 또는 사용자가 지정한 경우 작업을 수행하는 데 필요한 필수 입력을 정의할 수도 있습니다. 리소스 이름 지정과 같은 항목부터 선택적 추가에 이르기까지 다양할 수 있습니다.

템플릿의 예는 다음과 같습니다.

엔터티와 마찬가지로 템플릿에는 공급자별 속성이 포함될 수 있습니다.

각 템플릿에는 공급자에 고유한 다른 표현이 있을 수 있습니다. Terraform 또는 ARM 템플릿부터 Helm 차트, 매개 변수가 있는 GitHub Actions 워크플로 또는 Azure Pipelines, 간단한 스크립트 또는 사용자 지정 형식에 이르기까지 다양할 수 있습니다.

실제 기본 템플릿 세부 정보를 반드시 중앙에 저장할 필요는 없습니다. 다른 리포지토리, 레지스트리 또는 카탈로그에 존재할 수 있습니다. 예를 들어 애플리케이션 템플릿에 GitHub 템플릿 리포지토리를 사용할 수 있지만, IaC 템플릿은 개발자가 Azure 배포 환경과 같은 항목을 통해서만 간접적으로 액세스할 수 있는 제한된 카탈로그 리포지토리에 있을 수 있습니다. 다른 IaC 템플릿은 Helm 차트와 같은 OCI 아티팩트 레지스트리에 저장될 수 있습니다. 다른 경우에는 템플릿이 매개 변수가 있는 HTTP 엔드포인트에 대한 참조일 수 있습니다. 개발자 플랫폼 공급자는 참조할 수 있도록 각 템플릿 유형 및 사용자 환경에서 사용하기 위해 노출되는 모든 옵션에 대한 충분한 정보를 제공해야 합니다. 그러나 템플릿 자체는 사용 사례에 가장 자연스러운 위치에 보관할 수 있습니다.

특정 영역에 대한 플랫폼 엔지니어 또는 전문가는 템플릿을 작성한 다음 다시 사용할 수 있도록 개발 팀과 공유합니다. 시스템을 통해 이러한 템플릿의 사용을 중앙 집중화하면 개발자 셀프 서비스를 사용할 수 있으며 조직 표준 또는 정책 준수를 적용하는 데 도움이 되는 가드레일을 만들 수 있습니다. 이에 대한 자세한 내용은 개발자 플랫폼 오케스트레이터를 약간 다룹니다.

개발자 플랫폼 그래프

개발자 플랫폼 그래프를 여러 공급자의 엔터티 및 템플릿을 검색 가능한 그래프에 연결할 수 있는 것으로 생각할 수 있습니다. 그러나 엔터티의 실제 데이터를 그래프 특정 데이터베이스에 직접 유지할 필요는 없습니다. 대신 공급자와의 상호 작용을 필요한 메타데이터와 함께 캐시하여 모두 함께 맞출 수 있습니다.

공급자 및 오케스트레이터를 포함한 개발자 플랫폼 그래프의 다이어그램

그래프는 여러 공급자가 기여할 수 있는 공통 엔터티와 함께 사용할 때 강력합니다. 예를 들어 API 목록은 Azure API 센터와 같은 제품에서 나올 수 있지만 지속적인 배포 시스템의 배포 및 환경에 자동으로 공급하려고 할 수도 있습니다. 시간이 지남에 따라 서로 다른 배포 시스템 간에 전환하거나 둘 이상의 배포 시스템을 지원할 수 있습니다. 각 배포 시스템에 개발자 플랫폼 공급자가 있는 한 연결을 만들 수 있어야 합니다.

이 그래프에서 빌드되는 각 사용자 환경은 공통 API를 활용하여 검색, 검색, 거버넌스 등을 구동할 수 있습니다. 개발자 플랫폼 오케스트레이터는 개발자 플랫폼 공급자가 수행하는 모든 작업이 동일한 API에서 사용할 수 있는 엔터티를 자동으로 기여하도록 이 동일한 그래프를 활용할 수 있습니다.

개발자 플랫폼 오케스트레이터

개발자 플랫폼 오케스트레이터를 사용하면 개발자 또는 시스템에서 템플릿을 사용하여 작업을 수행하는 요청을 만들 수 있습니다. 이러한 작업 자체는 수행하지 않고 작업 엔진, 워크플로 엔진 또는 다른 오케스트레이터와 조정하여 작업을 수행합니다. 셀프 서비스 기반의 일부임을 확신할 수 있는 중요한 요소 중 하나입니다. 개발자는 템플릿을 사용하여 요청을 만들거나 직접 권한 없이 작업을 실행할 수 있습니다. 또한 CI 또는 CD의 개념과 달리 이러한 작업은 애플리케이션 소스 코드와 관련될 필요가 없습니다.

GitHub Actions, Azure Pipelines 또는 다른 워크플로 엔진을 오케스트레이터로 사용할 수 있습니다. 시작하기에 적합한 위치이지만 다양한 형식의 템플릿이 다른 기본 엔진을 사용할 수 있도록 약간의 추상화가 있을 수 있습니다. 이 기능은 다음과 같은 몇 가지 이유로 유용할 수 있습니다.

  • 첫째, 빠른 잘라내기 없이 시간이 지남에 따라 다른 워크플로 및 작업 실행 엔진을 선택할 수 있어야 할 수 있습니다. 둘 이상의 엔진을 허용하면 시간이 지남에 따라 마이그레이션하거나 새 엔진을 사용하여 이전 작업에 영향을 주지 않고 새 작업으로 마이그레이션할 수 있습니다.
  • 오케스트레이션에 도움이 하려는 일부 프로세스는 나중에 완전히 자동화하려는 경우에도 처음에는 수동 단계가 필요할 수 있습니다.
  • 다른 작업은 유료 계정 또는 라이선스 관리자와 같은 개발 팀 외부의 역할을 대상으로 할 수 있습니다. Power Automate와 같은 하위 코드 엔진은 종종 이러한 역할에 적합합니다.
  • GitHub Actions 또는 Azure Pipelines처럼 가능한 작업을 회전하거나 크기를 조정하는 데 비용 효율이 없는 간단한 HTTP 요청을 통해 다른 작업을 처리할 수 있습니다.

다행히 자동화 단계 트리거 및 추적을 포함하도록 개발자 플랫폼 공급자의 아이디어를 확장하면 필요한 추상화가 제공될 수 있습니다. 다음 그림을 고려하세요.

개발자 플랫폼 API 및 엔터티 공급자 라우팅 및 전달이 있는 플랫폼 오케스트레이터의 다이어그램.

일반적인 개념은 다음과 같습니다.

  • 템플릿은 필요에 따라 사용자가 입력할 수 있는 입력 집합을 지정할 수 있습니다. 개발자는 특정 작업을 트리거할 때 템플릿을 선택하고(이러한 방식으로 설명하지 않더라도) 입력을 입력합니다.
  • 템플릿 관련 입력에 대한 참조는 개발자 플랫폼 API의 요청이 됩니다.
  • 요청이 제출되면 오케스트레이터 내의 요청 라우팅 및 처리 구성 요소가 요청의 수명 주기를 추적하기 시작합니다. 요청 라우팅 및 처리 구성 요소는 요청의 템플릿을 템플릿이 시작된 개발자 플랫폼 공급자로 라우팅합니다.
  • 그런 다음 개발자 플랫폼 공급자는 구현에 적절한 단계를 수행합니다.
  • (선택 사항) 개발자 플랫폼 공급자는 작업을 수행할 때 요청 상태를 업데이트합니다.
  • 요청이 완료되면 개발자 플랫폼 공급자는 개발자 플랫폼 그래프에서 추가/업데이트할 엔터티 집합을 반환할 수 있습니다. 공급자별 엔터티 또는 공통 엔터티일 수 있습니다.

필요에 따라 고급 상호 작용을 지원하기 위해 개발자 플랫폼 공급자는 개발자 플랫폼 API를 직접 호출하여 더 많은 엔터티를 입력으로 얻거나 다른 관련 작업을 요청할 수 있습니다.

일반 작업 또는 워크플로 엔진을 사용하는 개발자 플랫폼 공급자를 선택합니다. 더 구체적으로, 소프트웨어 엔지니어링 시스템 적용의 일환으로 함께 배치한 것을 연결하기 위해 무언가를 원합니다. 투자할 일반적인 워크플로 또는 작업 실행 엔진 중 하나는 CI/CD 시스템입니다.

GitHub Actions 또는 Azure Pipelines를 사용하는 예제

개발자 플랫폼 공급자로서 GitHub Actions 또는 Azure Pipelines가 어떻게 작동하는지 간략하게 살펴보겠습니다.

GitHub Actions의 경우 개발자 플랫폼 공급자가 지정된 GitHub 인스턴스에 연결하고 Actions REST API를 사용하여 워크플로 디스패치 이벤트를 실행하여 워크플로 실행을 트리거할 수 있습니다. 각 워크플로는 워크플로 YAML 파일에 workflow_dispatch 구성을 추가하여 입력 집합을 지원할 수 있습니다. Azure DevOps 트리거는 유사하며 실행에 Azure DevOps Pipeline API 를 사용할 수도 있습니다. 다른 제품에서도 동일한 기능을 볼 수 있습니다.

GitHub Actions를 개발자 플랫폼 공급자로 사용하는 예제의 다이어그램.

이러한 워크플로 또는 파이프라인은 애플리케이션 소스 코드 리포지토리에 있을 필요가 없습니다. 개념은 이 사실을 활용하여 다음과 같은 작업을 수행하는 것입니다.

  • 플랫폼 엔지니어 또는 DevOps 팀 구성원은 개발자가 액세스할 수 없는 하나 이상의 중앙 리포지토리에서 워크플로/파이프라인을 유지 관리할 수 있지만 개발자 플랫폼 공급자는 사용하도록 설정됩니다. 이 동일한 리포지토리에는 워크플로/파이프라인에서 사용하는 스크립트 및 IaC 코드 조각이 포함될 수 있습니다.
  • 이러한 워크플로/파이프라인이 적절한 다운스트림 시스템과 상호 작용할 수 있도록 하기 위해 ops 또는 플랫폼 엔지니어링 팀의 다른 구성원은 중앙 리포지토리에 필요한 비밀을 추가할 수 있습니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 GitHub Actions 및 Azure DevOps 설명서를 참조하거나 Azure Key Vault와 같은 항목을 사용하여 비밀을 중앙 집중화하도록 선택할 수 있습니다.
  • 그런 다음, 이러한 워크플로/파이프라인은 결과 엔터티를 빌드/배포 아티팩트(GitHub 문서, Azure DevOps 문서)로 게시하는 모델을 따를 수 있습니다.
  • 실행하는 동안 개발자 플랫폼 공급자는 워크플로/파이프라인의 상태를 확인하고 완료될 때까지 오케스트레이터의 수명 주기 상태를 업데이트할 수 있습니다. 예를 들어 GitHub Actions와 함께 웹 후크를 사용하고 Azure Pipelines와 함께 서비스 후크를 사용하여 업데이트를 추적할 수 있습니다.
  • 완료되면 공급자는 필요에 따라 개발자 플랫폼 그래프에 포함하기 위해 게시된 아티팩트 사용이 가능합니다.

마지막으로, 지정된 작업에 대한 입력과 함께 적절한 리포지토리 및 워크플로/파이프라인을 참조하는 템플릿 집합을 개발자 플랫폼 그래프로 출력하도록 이 개발자 플랫폼 공급자를 설정할 수 있습니다.

CI/CD 시스템을 사용할 때 가장 좋은 점은 임의 CLI 실행을 지원하도록 설정되는 경우가 많기 때문에 모든 작업에 대해 일류 고유 통합이 필요하지 않는다는 것입니다. 시간이 지남에 따라 필요에 따라 추가할 수 있습니다.

이 예제에 설명된 내용의 대부분은 다른 유형의 공급자가 작동하는 방식을 적용합니다. 또한 이 컨텍스트에서 GitHub Actions 또는 Azure Pipelines를 사용하면 실제 CI/CD 파이프라인에도 사용할 필요가 없다는 점에 유의해야 합니다.

다른 예제

다음은 템플릿을 처리할 수 있는 다른 유형의 개발자 플랫폼 공급자에 대한 몇 가지 예입니다.

예제 설명
소스 제어 작업 경우에 따라 리포지토리를 만들거나 업데이트하거나 PR을 제출하거나 다른 다른 소스 제어 관련 작업을 수행해야 할 수 있습니다. 일반적인 비동기 워크플로 엔진은 이러한 종류의 작업을 관리할 수 있지만 하나도 없이 기본 Git 작업을 수행할 수 있는 것이 유용할 수 있습니다.
인프라 프로비저닝자 GitHub Actions 및 Azure Pipelines는 인프라 프로비저닝을 관리하는 데 적합하지만 더 직접적인 통합도 선택할 수 있습니다. 전용 공급자는 설정을 간소화하고 오버헤드를 방지할 수 있습니다. Azure 배포 환경 또는 Terraform Cloud와 같은 서비스는 IaC 템플릿 기반 프로비저닝을 안전하고 안전하게 사용하도록 설정하는 데 보다 직접적으로 초점을 맞추고 있습니다. 다른 예로는 공유 클러스터의 애플리케이션에 대한 Kubernetes 네임스페이스를 만들거나 Flux 또는 Argo CD를 특정 유형의 공급자로 사용하여 GitOps 워크플로에서 git을 사용하는 등의 작업이 포함될 수 있습니다. 자체 CLI를 사용하는 실험적 Radius OSS 인큐베이션 프로젝트와 같은 더 많은 앱 중심 모델은 시간이 지남에 따라 자체 개발자 플랫폼 공급자를 가질 수 있습니다. 중요한 것은 적응할 수 있도록 확장성을 찾고 계획하는 것입니다.
애플리케이션 스캐폴딩/시드 애플리케이션 템플릿은 시간이 지남에 따라 플랫폼 엔지니어링이 리드하는 중요한 부분입니다. 애플리케이션 원본 트리를 스캐폴드할 뿐만 아니라 소스 코드 리포지토리에 콘텐츠를 만들고 푸시하고 결과 엔터티를 그래프에 추가하도록 설계된 전용 개발자 플랫폼 공급자를 제공하여 원하는 템플릿 엔진을 지원할 수 있습니다. 모든 에코시스템에는 Yeoman, cookiecutter 또는 Azure Developer CLI와 같은 자체 애플리케이션 스캐폴딩 기본 설정이 있으므로 여기서 공급자 모델을 사용하면 동일한 인터페이스에서 둘 이상을 지원할 수 있습니다. 여기서도 핵심은 확장성입니다.
수동 프로세스 개발자가 아닌 사용자가 Power Platform과 같은 항목을 사용하여 응답할 수 있도록 수동 승인 또는 수동 워크플로 단계에 대한 PR을 자동으로 생성하는지 여부에 관계없이 개발자 플랫폼 공급자에서 동일한 템플릿 기반 모델을 사용할 수 있습니다. 시간이 지남에 따라 더 자동화된 단계로 이동할 수도 있습니다.

이러한 공급자를 모두 시작할 필요는 없지만 개발자 플랫폼 공급자와 같은 기능을 통한 확장성이 시간이 지남에 따라 자동화 기능이 증가하는 데 어떻게 도움이 되는지 확인할 수 있습니다.

사용자 및 팀

플랫폼 엔지니어링은 본질적으로 다중 시스템 문제이므로 셀프 서비스 기반이 이러한 시스템을 통합할 때 더 어려운 문제를 어떻게 처리해야 하는지 계획하는 것이 중요합니다. ID, 사용자 및 팀과 관련된 일반적인 문제를 해결하기 위한 전략은 다음과 같습니다.

추천 설명
최적의 보안을 위해 개발자 플랫폼 API를 ID 공급자와 직접 통합 개발자 플랫폼 API를 보호하려면 강력한 ID 및 Entra ID의 RBAC(역할 기반 액세스 제어) 기능을 고려할 때 Microsoft Entra ID와 같은 ID 공급자와 직접 통합하는 것이 좋습니다. 추상화가 아닌 ID 공급자의 네이티브 SDK 및 API(예: MSAL Entra ID를 통해)를 직접 사용하는 경우 많은 이점이 있습니다. 엔드 투 엔드 보안을 구동하고 조건부 액세스 정책이 지속적으로 평가되도록 하는 동시에 동일한 RBAC 모델을 사용할 수 있습니다(로그인 시에만 해당).
다운스트림 시스템에서 Single Sign-On 및 ID 공급자 그룹 통합 사용 SSO(Single Sign-On) 통합은 개발자 플랫폼 API에 사용하는 것과 동일한 ID 공급자 및 테넌트를 사용해야 합니다. 또한 SCIM과 같은 프로토콜에 대한 지원을 활용하여 ID 공급자 그룹(예: AD 그룹)에 연결해야 합니다. 이러한 ID 공급자 그룹을 다운스트림 시스템 권한에 연결하는 것은 항상 자동은 아니지만 최소한 나중에 멤버 자격을 수동으로 관리하지 않고도 식별 공급자 그룹을 각 도구의 그룹화 개념과 수동으로 연결할 수 있습니다. 예를 들어 ID 공급자 그룹을 GitHub 팀에 연결하는 기능을 수동으로 활용하는 기능과 함께 GitHub의 EMU(Enterprise Managed User) 지원을 결합할 수 있습니다. Azure DevOps의 기능도 비슷합니다.

단일 ID 공급자 그룹을 넘어 팀의 개념 설정

플랫폼 엔지니어링 과정을 계속하면서 ID 공급자 그룹이 멤버 자격을 관리하는 데 적합하지만 RBAC(역할 기반 액세스 제어) 및 데이터 집계를 위한 팀의 개념을 형성하기 위해 여러 그룹이 함께 모여야 합니다.

플랫폼 엔지니어링의 맥락에서, 우리는 팀을 함께 작업하는 다양한 역할의 사용자 집합으로 정의합니다. 데이터 집계의 경우 다중 역할 팀의 아이디어는 대시보드 보고와 같은 장소에서 정보를 검색하고 롤업하는 데 매우 중요합니다. 반면에 그룹은 사용자 집합에 대한 일반 ID 공급자 개념이며, 다른 방법이 아닌 특정 역할에 여러 사람을 추가하는 아이디어로 설계되었습니다. 따라서 RBAC를 사용하면 팀이 서로 다른 역할을 통해 여러 ID 공급자 그룹과 관련할 수 있습니다.

한 팀에 연결된 여러 ID 공급자의 다이어그램

팀 데이터의 원본은 몇 가지 다른 위치에서 올 수 있습니다. 예를 들어 팀을 코드 패턴(TaC)으로 사용하는 경우 개발자 플랫폼 공급자는 리포지토리의 파일 변경 내용을 감시하고 사용자 프로필 및 팀 메타데이터 저장소에 캐시할 수 있습니다. 또는 이러한 핵심 RBAC 구문을 이미 사용할 수 있는 Azure 개발자 센터 Project와 직접 통합할 수 있습니다.

팀 또는 사용자 수준에서 다운스트림 시스템과 통합하기 위한 모델 설정

일부 개발자 및 운영 도구/서비스는 기본적으로 ID 공급자 개념을 직접 통합하고 사용하지만, 많은 개발자는 이를 SSO를 사용하여 그룹 또는 사용자의 고유한 표현으로 추상화합니다. 이 현실에서는 도구 간에 액세스를 사용하도록 설정하는 것 외에도 데이터 집계에 문제가 발생할 수 있습니다. 특히 다운스트림 시스템의 API는 ID 공급자 식별자가 아닌 자체 식별자를 사용하는 것을 확인할 수 있습니다(예: Entra ID의 개체 ID는 직접 사용되지 않음). 따라서 다른 ID 간에 매핑할 수 없는 한 사용자 또는 팀 수준 데이터를 필터링하고 연결하기가 어렵습니다.

팀 및 그룹 수준 차이 해결

TaC와 같은 패턴을 사용하면 각 시스템의 팀 또는 그룹 식별자 간에 관계를 저장하고 액세스할 수 있으므로 이들 간에 매핑할 수 있습니다. 요약하자면, 안전하고 감사 가능한 Git 리포지토리는 팀의 원본이 되며, PR은 업데이트할 제어된 사용자 인터페이스를 제공합니다. 그런 다음 CI/CD 시스템은 다운스트림 시스템을 업데이트하고 이 작업을 수행하는 데 사용한 팀의 관련 식별자 관계를 유지할 수 있습니다.

관계를 저장하는 코드 구현인 팀 차트입니다.

예를 들어 다음과 같은 관계를 API 호출에 저장할 수 있습니다.

API 호출에서 팀을 코드로 사용하는 관계의 다이어그램.

팀의 리포지토리에 있는 파일 이외의 데이터 원본을 사용하려는 경우 개발자 플랫폼 오케스트레이터를 사용하여 동일한 작업을 수행할 수 있습니다. 이 모델에서 팀 데이터 원본에 대한 개발자 플랫폼 공급자는 다른 모든 공급자가 수신하고 적절하게 작동하는 팀 업데이트 이벤트를 트리거할 수 있습니다.

개발자 플랫폼을 사용한 코드로 된 팀의 다이어그램.

사용자 ID 문제 해결

데이터 액세스 및 집계에 대한 또 다른 관련 과제는 사용자 ID 차이입니다. 팀 사례와 마찬가지로 시스템 대 시스템 통합을 사용하여 사용자에 대한 데이터를 쿼리하는 경우 ID 공급자 네이티브 ID(예: Entra ID의 개체 ID)가 지정된 API를 지원한다고 가정할 수 없습니다. 여기서도 개발자 플랫폼 API를 통해 데이터에 액세스하는 사용자 ID에 대한 매핑을 저장하는 것이 도움이 될 수 있습니다. 예를 들어 GitHub를 고려합니다.

GitHub를 공급자로 사용하는 사용자 역할의 다이어그램

각 시스템에 대해 사용자 토큰 없이 API를 통해 다른 시스템의 사용자 ID 조회를 수행할 수 있는 경우 지정된 개발자 플랫폼 공급자가 이 매핑을 즉시 생성할 수 있습니다. 경우에 따라 이 작업을 대량으로 수행하고 성능을 유지하기 위해 참조를 위해 결과를 캐시해야 할 수 있으므로 이 작업이 복잡해질 수 있습니다.

여러 사용자 토큰 사용으로 대체

공급자가 작동하는 사용자 ID 변환을 수행할 방법 없이 사용자 수준 데이터에 액세스해야 하는 경우 개발자 플랫폼 API를 설정하여 여러 사용자 토큰을 관리할 수 있습니다. 예시:

  • 개발자 플랫폼 API는 다운스트림 시스템에서 사용하기 위해 공급자별 사용자 토큰의 캐시를 지원할 수 있습니다.
  • API에 의해 트리거된 지정된 공급자와의 상호 작용은 사용 가능한 경우 공급자의 사용자 토큰에 포함됩니다.
  • 사용자 토큰을 사용할 수 없는 경우를 처리하기 위해 공급자는 OAuth 흐름을 트리거하여 토큰을 가져옵니다.
  • 먼저 개발자 플랫폼 API는 공급자에 전달된 리디렉션 URI를 사용하여 OAuth 흐름에 대한 인증 URI를 다시 전달합니다. 전달된 URI에는 nonce/일회성 사용 코드가 포함됩니다.
  • 그런 다음 API는 URI를 사용하여 "인증되지 않은" 응답을 반환합니다.
  • 그러면 모든 UX에서 이 URI를 사용하여 브라우저에서 적절한 인증 흐름을 구동할 수 있습니다.
  • 리디렉션이 수행되면 개발자 플랫폼은 필요한 사용자 토큰을 수신하고 사용자 ID와 함께 향후 참조를 위해 캐시합니다.
  • 그러면 클라이언트가 API 호출을 다시 시도하면 성공합니다.

이 개념은 가능한 경우 ID를 다시 사용할 수 있고 다운스트림 시스템당 별도의 리디렉션 URI를 유지할 필요가 없으므로 복잡한 인증을 처리하는 방법을 간략하게 설명합니다.

지금까지 문제 공간의 자동화 측면에 대해 이야기해 왔습니다. UI는 자동화 중에 반환된 엔터티의 값을 사용하여 팀을 위한 다른 시스템에 대한 딥 링크를 만들 수 있으므로 이 작업만으로는 먼 길을 갈 수 있습니다.

자동화와 관련이 없는 경우에도 개발자 플랫폼 공급자는 모든 종류의 엔터티 필요를 내보낼 수 있습니다. 그러나 일반적으로 전체 내부 개발자 플랫폼의 자세한 데이터를 개발자 플랫폼 그래프로 가져오고 싶지는 않습니다. Grafana, Prometheus, DataDog 또는 SonarQube와 같은 제품의 코드 인텔리전스와 GitHub 및 Azure DevOps와 같은 DevOps 제품군의 네이티브 기능과 같은 가시성 솔루션의 대시보드는 모두 매우 가능합니다. 대신, 가장 좋은 방법은 종종 이러한 다른 시스템에 대한 딥 링크를 만드는 것입니다. 엔터티는 로그 콘텐츠와 같은 자세한 정보를 직접 포함하지 않고도 링크를 만들 수 있는 충분한 정보를 제공할 수 있습니다.

도구 간에 집계되고 요약된 데이터를 사용하거나 사용자 지정 메트릭을 구동해야 하는 경우 Power BI 또는 Microsoft Fabric 보고 솔루션이 다음 호출 포트가 될 수 있습니다. 팀 데이터를 병합하려면 Foundation의 데이터베이스에 연결하거나 개발자 플랫폼 API를 통해 진행할 수 있습니다. 예를 들어 계획 및 우선 순위에 설명된 대로 사용자 지정 대시보드를 원하는 위치 중 하나는 내부 개발자 플랫폼의 성공을 측정하는 것입니다.

빌드하는 각 추가 환경을 선택해야 합니다.

일반적인 포털과 같은 방식으로 기존 기능을 다시 만드는 것이 매력적일 수 있지만 유지 관리해야 합니다. 제품 사고방식을 따르는 것이 중요한 영역입니다. 대시보드 스타일 인터페이스는 쉽게 생각하고 이해할 수 있지만 개발자는 다른 곳에서 더 많은 가치를 찾을 수 있습니다.

즉, 여기서 모델을 사용하면 개발자 플랫폼 그래프에서 집계된 데이터를 사용하여 사용자 지정 사용자 환경을 만들 수 있습니다. 엔터티는 사용자 또는 팀과 연결할 수 있도록 기본 제공 지원이 있어야 합니다. 이를 통해 개발자 플랫폼 API는 인덱싱 및 캐싱 사용과 함께 출력 범위를 지정합니다.

그러나 딥 링크가 아닌 사용자 지정 UX를 만들어야 하는 경우에도 개발자 플랫폼 그래프로 모든 데이터를 끌어당기는 것이 가장 좋은 방법은 아닙니다. 예를 들어 잘 정의되고 관리되는 홈이 이미 있는 UX에 로그를 표시할 수 있는 상황을 고려해 보세요. 관련 엔터티의 정보를 사용하여 UX가 다운스트림 시스템에서 직접 정보를 수집하는 데 도움이 됩니다.

연결하려면 시스템-시스템 통합을 사용해야 할 수도 있지만 사용자 및 팀에 설명된 모델 중 하나를 구현한 후에는 필요한 경우 저장된 다운스트림 사용자/팀 ID 또는 사용자 인증 토큰을 사용할 수 있습니다.

다음은 고려해야 할 일반적인 환경의 몇 가지 예입니다.

예제 설명
검색 및 탐색 한 플랫폼 엔지니어링 실무자는 "프로젝트를 느리게 하는 것은 개발자 기술이 아니라 커뮤니케이션입니다." –Daniel, Cloud Engineer, Fortune 500 Media Company.
소프트웨어는 팀 스포츠이므로 팀을 검색하는 데 도움이 되는 사용자 인터페이스를 만드는 것은 일반적으로 가장 먼저 해결해야 할 사항 중 하나입니다. 팀 간 검색, 검색 및 문서는 재사용을 촉진하고 내부 소싱 또는 지원을 위한 공동 작업을 지원합니다. 또한 Teams는 원스톱 상점을 통해 환경, 리포지토리 및 문서와 같은 기타 리소스를 포함하여 소유한 항목을 찾을 수 있습니다.
환경 또는 리소스 수동 등록 개발자 플랫폼 오케스트레이터를 통해 많은 항목을 프로비전하고 추적할 수 있지만, 이미 존재하거나 아직 자동화되지 않은 리소스 또는 환경을 등록할 수도 있습니다. Git 리포지토리에서 정보를 가져오고 리소스/환경 관리에 정보를 추가하는 간단한 공급자는 여기에서 유용할 수 있습니다. 소프트웨어 카탈로그가 이미 있는 경우 모델에 통합하는 방법이기도 합니다.
API 카탈로그 개발자가 사용해야 하는 API 추적은 먼 길을 갈 수 있습니다. 아직 없는 경우 API, 해당 상태를 나타내는 일련의 파일로 간단한 Git 리포지토리로 시작하여 PR을 사용하여 승인 워크플로를 관리할 수도 있습니다. 이러한 항목을 개발자 플랫폼 그래프에 추가하여 표시하거나 다른 엔터티와 연결할 수 있습니다. 보다 강력한 기능을 위해 Microsoft의 API 센터 또는 다른 제품과 같은 기능을 통합할 수 있습니다.
라이선스 규정 준수 경우에 따라 소프트웨어 라이선스 규정 준수 및 라이선스 사용량에 대한 가시성을 제공할 수도 있습니다. 개발자 플랫폼은 라이선스를 사용하는 데 필요한 자동화를 추가할 수도 있지만 라이선스가 수동으로 할당되더라도(예: Git 리포지토리의 PR 프로세스를 통해), 개발자는 라이선스가 있는 항목(및 모든 것을 볼 수 있는 관리자의 기능)을 파악할 수 있습니다.
Kubernetes의 애플리케이션 중심 뷰 공유 Kubernetes 클러스터를 사용하는 경우 개발자는 클러스터 관리자 UX를 통해 애플리케이션의 상태를 찾고 이해하기 어려울 수 있습니다. 조직별로 이 문제를 다르게 처리하도록 선택할 수 있지만 네임스페이스를 사용하여 애플리케이션을 나타내는 것은 잘 알려진 한 가지 방법입니다. 여기에서 엔터티를 사용하여 클러스터와 팀의 애플리케이션 네임스페이스 간에 연결을 설정하고 애플리케이션에 대한 개발자 중심의 상태 보기를 만들고 다른 도구 또는 웹 UI에 대한 딥 링크를 제공할 수 있습니다.

사용자 환경

조직의 다양한 역할에는 일상적인 작업에 대한 무게 중심을 나타내는 도구 또는 서비스가 있습니다. 이러한 시스템을 끌어오면 이러한 무게 중심 외부의 새로운 사용자 환경이 견인력을 얻기 어려울 수 있습니다. 완벽한 환경에서 개발자, 운영 및 기타 역할은 이미 사용 중인 환경에서 계속 작동할 수 있습니다.

이를 염두에 두고 플랫폼 엔지니어링 과정을 진행할 때 여러 사용자 인터페이스를 계획하는 것이 좋습니다. 또한 필요에 따라 단순하게 시작하고, 가치를 증명하고, 더 복잡한 인터페이스로 확장할 수 있는 기회를 제공할 수 있습니다.

가지고 있는 항목 통합

소프트웨어 엔지니어링 시스템 적용 및 애플리케이션 플랫폼 구체화 문서를 읽은 경우 계속 사용하려는 시스템을 식별했을 수 있습니다. 두 경우 모두 새로운 환경을 처음부터 빌드하기 전에 가지고 있는 기능을 향상시키고 확장할 수 있는지 평가합니다. (자신에게 물어, 사람들이 다른 새로운 사용자 경험 또는 그들이 지금 가지고있는 무언가의 개선 된 버전에 더 잘 반응 할 것인가?)

계속 사용하려는 도구, 유틸리티 또는 웹앱 중 일부는 사용자 지정이며 향상된 기능을 위한 좋은 후보입니다. 하지만 즐겨 찾는 도구와 서비스에 사용할 수 있는 확장성 모델이 있는지 주의해야 합니다. 여기에서 시작하면 많은 이점을 얻을 수 있습니다. 이렇게 하면 유지 관리 및 보안 문제를 제거하고 해결하려는 문제에 집중할 수 있습니다.

예를 들어 이미 사용 중인 다음 표면을 확장할 수 있습니다.

기존 시스템의 확장성 예제 스크린샷

각 역할은 기존 무게 중심이므로 처음부터 설정한 역할보다 더 나은 시작점을 제공할 수 있습니다. 일반적인 개발자 플랫폼 API를 기준으로 사용하면 시간이 지남에 따라 사물을 교환하고 실험하고 변경할 수 있습니다.

개발자 포털을 만들려면 웹 편집기 확장을 고려하세요.

개발자를 위한 웹 기반 환경을 찾고 있는 경우 최근 추세는 웹 기반 버전의 편집기 및 IDE입니다. VS Code를 사용하는 것과 같은 많은 경우 확장 지원이 있습니다. VS Code를 사용하면 이러한 웹 환경을 위해 빌드하는 모든 항목이 이중 혜택을 위해 로컬로 변환됩니다.

GitHub Codespaces와 같은 서비스 외에도 vscode.dev 컴퓨팅이 없는 VS Code 편집기의 무료 웹 버전이지만 사용자 지정 UI에 웹 보기를 사용하는 확장을 포함하여 특정 유형의 확장에 대한 지원을 포함합니다.

사용자 지정 UX용 WebView를 사용하는 확장이 있는 VS Code의 스크린샷

개발자가 VS Code 자체를 사용하지 않더라도 UX 패턴은 잘 알려져 있으며 다른 개발자 도구에서 찾을 수 있습니다. vscode.dev 사용하면 도구 자체 외에도 개발자 환경을 위한 편리하고 친숙한 웹 기반 기반을 제공할 수 있습니다.

이러한 포털은 로컬 사용으로 변환할 수 있는 친숙한 형식의 개발자 중심 포털 역할을 할 수 있습니다.

ChatOps

종종 간과되는 또 다른 기회는 ChatOps 인터페이스를 구현하는 것입니다. ChatGPT 및 GitHub Copilot와 같은 AI 제품의 증가로 인해 채팅 기반 인터페이스가 증가하는 경우 작업 명령 또는 슬래시 명령은 자동화 워크플로를 트리거하고 상태를 확인하는 유용한 방법을 제공할 수 있습니다. 대부분의 애플리케이션 CI/CD 플랫폼이 Microsoft Teams, Slack 또는 Discord와 같은 시스템을 기본적으로 지원하므로 다른 사용자 인터페이스 개발자와 통합하고 관련 작업 역할이 매일 사용하는 자연스러운 방법이 될 수 있습니다. 또한 이러한 모든 제품에는 확장성 모델이 있습니다.

새 개발자 포털에 투자

기본으로 사용할 기존 포털 또는 인터페이스가 없다고 가정하면 새 개발자 포털을 빌드할 수 있습니다. 시작점이 아닌 대상으로 생각해 보세요. 개발자와 함께 작업하는 개발 팀이 아직 없는 경우 이 작업을 시작할 때입니다. 모든 조직이 다르기 때문에 이런 종류의 환경에 있어야 하는 것에 대한 한 가지 크기에 맞는 답은 없습니다. 결과적으로, 당신이 회전 하 고 오늘 같은 것에 대 한 그대로 사용할 수 있는 미리 포장 된 제품에 대 한 실용적 대답이 있다.

사용자 지정 기본 제공 자체 호스팅 옵션의 경우 일반 웹 포털 프레임워크는 새로운 것이 아니며 개발 팀에서 이미 활용할 수 있는 프레임워크를 사용하고 있을 수 있습니다. 초기 피드백을 위해 사용자 앞에서 무언가를 꺼내려는 경우 코드가 낮은 Power Pages 처럼 간단한 것으로 시작하여 일반적인 개발자 플랫폼 API에 연결할 수도 있습니다.

더 최근의 개발자 포털 노력은 더 많은 의견이 있습니다. 예를 들어 Backstage.io 스포티 파이의 요구를 충족하기 위해 처음에 구축 된 사용자 지정 개발자 포털 도구 키트입니다. 여기에는 create-react-app이 React.js 위해 수행하는 것처럼 소스 트리를 부트스트랩하는 데 도움이 되는 CLI가 포함되어 있습니다.

Backstage.io 있는 구성 요소를 선택하는 스크린샷

포털 도구 키트는 작업을 수행해야 하며 사용자 지정을 수행하려면 TypeScript, Node.js 및 React에 대한 지식이 필요합니다. 그러나 가장 좋은 점은 도구 키트로서 거의 모든 것을 변경할 수 있다는 것입니다. 자체 소프트웨어 카탈로그 및 템플릿 메커니즘도 있지만 해당 사용은 필요하지 않으며 플러그 인이라는 새로운 1st 및 3rd 파티 코드를 가져올 수있는 잘 정의 된 방법이 있습니다.

관련 콘텐츠