하나의 CI 도구 체인에서 여러 앱 구성

CI (Continuous Integration) 를 통해 서비스 오퍼링을 실행하는 경우 각 저장소에 대해 여러 도구 체인을 관리하는 대신 모든 오퍼링 마이크로서비스 또는 구성요소를 단일 공통 도구 체인으로 통합하는 것을 고려하십시오.

여러 애플리케이션의 저장소에 대해 작동하도록 CI 파이프라인가져오기 요청(PR)파이프라인 을 구성하는 것은 간단합니다. 다음 단계 및 변경을 사용하여 여러 애플리케이션을 사용으로 설정하십시오.

도구 체인 사용자 정의

여러 앱에 도구 체인을 추가하여 도구 체인을 사용자 정의하고 해당 기능을 향상시키십시오. 단계는 다음과 같습니다.

  1. 도구 체인 파이프라인에서 구축하려는 각 애플리케이션에 대해 도구 GitHub 통합을 추가하십시오.
  2. 특정 애플리케이션에 대해 구성할 수 있는 추가 문제, 인벤토리증거 저장소에 대해 더 많은 GitHub 통합을 추가하십시오.
  • 애플리케이션에 이러한 추가 저장소가 필요한지 이해하려면 문서 페이지 및 우수 사례를 참조하십시오.

  • 하위 시스템은 서로 의존하며 함께 개발 및 배포되는 관련 서비스들의 집합이다.

    • 단일 하위 시스템 내의 서비스는 공통 인벤토리 저장소와 증거 보관소를 공유해야 합니다. 각 하위 시스템은 재고 저장소와 증거 보관소 사이에 1:1 관계를 유지해야 합니다. 여러 보관함 간 증거 조회는 검색 범위를 확대하고 데이터 충돌 위험을 증가시키므로 지원되지 않습니다.
    • 여러 하위 시스템을 그룹화하여 동일한 공유 인벤토리와 보관함을 사용할 수도 있습니다.
    • 예시: 관련 서비스(예: authuser-profile)를 하나의 하위 시스템으로 그룹화합니다. 이 모델은 환경에서 Continuous Delivery 확장 가능한 마이크로서비스 관리를 지원합니다.
  • 애플리케이션 저장소는 자체 이슈 저장소 역할도 수행할 수 있습니다. 이는 도구 통합에서 GitHub 문제 옵션이 사용으로 설정된 경우에만 적용 가능합니다.

  • 인벤토리 저장소는 빌드 기록을 기록하기 위한 단일 통합 저장소로 충분해야 합니다. 기록은 이미 파라미터로 구분되어 app-name 있으므로, 해당 파라미터가 서로 다를 경우 기록이 분실되거나 혼동될 일은 없습니다. 이 저장소를 처리하는 방법에 대한 아이디어는 인벤토리 문서를 참조하는 것이 좋을 수 있습니다. 이 저장소의 주요 기능은 지속적 배포 파이프라인에서의 배포를 지원하는 데 도움을 주기 위함이기 때문입니다.

  1. 버킷을 IBM Cloud® Object Storage 설정하세요.

    IBM Cloud Object Storage은(는) 파이프라인 증거 아티팩트의 선호되는 증거 라커 방법이며 감사 규제 준수에 필요합니다. CI 도구 체인으로 가져오는 각 애플리케이션에 대해 동일한 Object Storage 버킷을 사용하십시오. 또한 CI 도구 체인을 CD 또는 CC 도구 체인과 통합할 때 동일한 Object Storage 버킷을 재사용하십시오.

  2. 선택사항: 추가 Hashicorp Vault 통합입니다.

    HashiCorp Vault 도구 통합이 하나의 경로만 지원하므로 HashiCorp Vault 시크릿이 구성되는 방법에 따라 더 많은 경로가 필요할 수 있습니다. 서로 다른 애플리케이션에는 서로 다른 신임 정보 또는 다른 신임 정보가 필요할 수 있습니다.

CI 및 PR 파이프라인 맞춤 설정

다음 단계를 사용하여 CI및 PR 파이프라인을 구성하여 사용자 정의하십시오.

  1. 각 애플리케이션에서 Git 트리거를 작성하십시오.

    • 트리거를 작성할 때 일부 tedium을 저장하려면 기존 트리거를 복사하십시오.
    • 각 트리거가 필요한 GitHub 저장소와 브랜치를 가리키도록 하십시오.
    • 다음 트리거 속성이 설정되어 있는지 확인하십시오:
      • app-name (텍스트): 앱 이름은 다른 애플리케이션에서 고유해야 합니다. 이는 앱 이름이 인벤토리, DevOps 인사이트 및 기타에서 아티팩트와 함께 배치되고 기록될 때 고유 ID로 사용되기 때문입니다.
      • cos-bucket-name 애플리케이션 증거가 저장되는 Object Storage 버킷의 이름.
  2. 각 애플리케이션에 대한 환경 특성이 변경됩니다.

    • 이는 각 애플리케이션에서 다른 값으로 변경해야 하는 가능한 환경 특성의 목록입니다. 파이프라인 트리거의 트리거 속성을 사용하여 환경 속성을 사용자가 선택한 값으로 재정의함으로써 이를 달성할 수 있습니다.
      • app-name 앱 이름은 인벤토리, DevOps 인사이트 등에서 아티팩트를 배치하고 기록할 때 고유 식별자로 사용되기 때문에, 서로 다른 애플리케이션 간에 항상 고유해야 합니다.
      • cos-bucket-name 애플리케이션 증거가 저장되는 Object Storage 버킷의 이름.
      • repository(텍스트): 이 매개변수는 파이프라인에 복제되는 애플리케이션 저장소를 제어하며 다양한 규제 준수 및 보안 태스크를 위한 CI 및 PR 파이프라인의 대상으로 사용됩니다.
      • 선택 사항: evidence-repo (텍스트): 애플리케이션의 증거 URL 보관소 역할을 하는 저장소의.
      • 선택 사항: incident-repo (텍스트): 애플리케이션의 이슈 URL 저장소 역할을 하는 저장소의.
      • 선택 사항: inventory-repo (텍스트): 애플리케이션의 인벤토리 URL 저장소 역할을 하는 저장소의.
  3. optional step 각 애플리케이션에 대해 수동 트리거를 설정하십시오.

    • 기술적으로는 매뉴얼 트리거 하나만 있으면 충분합니다. 호출 시점에 그 속성을 편집할 수 있기 때문입니다. 하지만 팀원들이 앱 간 모든 사소한 차이점을 작성하는 과정을 줄이기 위해 미리 구성된 매뉴얼 트리거를 보유하는 것이 유용할 수 있습니다.
  4. optional step 애플리케이션용 타이머 트리거 생성

    • 애플리케이션을 자주 재빌드하고 재검증하는 것이 좋은 관행입니다. 이를 통해 규정 준수 및 취약점 문제와 빌드 문제를 지속적으로 파악할 수 있습니다.
    • 타이머 트리거는 단순히 타이머에 설정된 수동 트리거이므로, 수동 트리거를 구성한 것과 동일한 방식으로 트리거 속성을 구성하십시오.
    • 각 크론 작업을 서로 시간차를 두고 실행하십시오. 그렇지 않으면 작업자 클러스터에 과부하가 걸려 빌드 시간이 증가하거나 단계 간 지연이 발생할 수 있습니다.

파이프라인 트리거 또는 환경 속성 내에서 설정할 수 있는 다른 속성에 대한 정보는 파이프라인 매개변수 카탈로그 를 참조하십시오.