GitHub 내보내기/복원

대화형 에이전트(Dialogflow CX)는 GitHub와 통합됩니다. 이러한 통합을 통해 에이전트를 JSON으로 내보내 GitHub에 푸시(push)하고 에이전트 복원을 위해 GitHub에서 풀(pull)할 수 있습니다. GitHub에 푸시된 JSON 내보내기 형식은 내보낸 에이전트의 펼쳐진 zip 파일 콘텐츠입니다.

이 기능을 사용하면 다음과 같은 GitHub 소스 제어 기능을 활용할 수 있습니다.

제한사항

다음과 같은 제한사항이 적용됩니다.

  • GitHub에는 시간당 요청 수에 대한 비율 제한이 있습니다(비회사 계정의 경우 5,000개, 회사 계정의 경우 15,000개). 에이전트 푸시가 이 한도를 초과하면 Dialogflow CX 콘솔에서 비율 제한 오류를 보고합니다. 1시간 후에 푸시를 다시 시도할 수 있습니다.
  • GitHub API는 단일 커밋에서 업데이트할 수 있는 파일 수에 제한이 있습니다. 파일 수가 500개를 초과하면 대화형 에이전트(Dialogflow CX)에서 GitHub에 푸시하지 못할 수 있습니다. 이 경우 에이전트를 zip으로 내보내고
    머신에서 Git CLI를 사용하여 에이전트 파일을 GitHub에 푸시할 수 있습니다. 이 제한은 이후 대화형 에이전트(Dialogflow CX) 출시에서 해결될 예정입니다.
  • 대화형 에이전트(Dialogflow CX)가 이러한 저장소에 액세스할 수 없으므로 비공개 액세스 자체 호스팅 저장소는 지원되지 않습니다.
  • GitHub 저장소에는 에이전트 내보내기에서 내보낸 에이전트 파일 이외의 파일은 포함될 수 없습니다. 저장소의 다른 모든 파일은 푸시할 때마다 삭제됩니다.

구성

이 통합을 구성하려면 다음 단계를 따르세요.

  1. Dialogflow CX 콘솔을 엽니다.
  2. Google Cloud 프로젝트를 선택합니다.
  3. 에이전트를 선택합니다.
  4. 관리 탭을 클릭합니다.
  5. 테스트 및 배포 섹션에서 Git을 클릭합니다.
  6. Git 통합 추가를 클릭하면 구성 대화상자가 열립니다.
  7. 다음을 입력합니다.
    • GitHub 연결의 표시 이름.
    • GitHub 저장소 URL(예: https://api.github.com/repos/<repository_owner>/<repository_name>).
    • 에이전트가 상호작용할 GitHub 브랜치를 추가합니다. 옆에 있는 별표 아이콘을 클릭하여 브랜치를 기본 브랜치로 지정할 수 있습니다.
    • GitHub 개인 토큰은 설정된 후에는 볼 수 없으며 업데이트만 지원됩니다. 세분화된 개인 액세스 토큰을 사용하는 경우 다음 권한에 액세스해야 합니다.
      • 저장소 권한 > 콘텐츠: 읽기 및 쓰기
      • 저장소 권한 > 메타데이터: 읽기 전용(콘텐츠 권한을 선택한 후 자동으로 선택됨)
  8. 연결을 클릭합니다.

이 구성은 수정 아이콘을 클릭하여 언제든지 변경할 수 있습니다.

푸시 및 복원

구성이 완료되면 GitHub에서 에이전트를 푸시/풀할 수 있습니다.

내보내기 버튼은 에이전트를 내보내고 Git 브랜치 드롭다운에서 선택한 GitHub 브랜치에 커밋하는 데 사용됩니다. 이 커밋은 특정 변경사항이 아닌 전체 에이전트로 구성되며 저장소의 기존 파일을 삭제합니다.

새 저장소의 경우 Dialogflow CX 콘솔에서 푸시 옵션을 사용하기 전에 GitHub의 커밋이 하나 이상 있는지 확인합니다.

Dialogflow 리더 역할이 있는 사용자는 GitHub 저장소로 푸시할 수 있습니다. 원치 않는 푸시를 방지하려면 이러한 에이전트를 읽기 전용 개인 액세스 토큰으로 구성하세요.

복원 버튼은 Git 브랜치 드롭다운에서 선택한 GitHub 브랜치에서 에이전트 데이터를 가져와 이 데이터에서 대화형 에이전트(Dialogflow CX) 에이전트를 복원하는 데 사용됩니다. 이렇게 하면 모든 에이전트 복원과 동일한 방식으로 에이전트가 덮어쓰기됩니다.

사용 사례

다음 예시에서는 여러 사용자가 이 기능을 사용하여 프로덕션 에이전트에 다양한 에이전트 변경사항을 제안하는 방법을 보여줍니다.

에이전트가 다음 GitHub 브랜치를 사용한다고 가정해 보겠습니다.

  • Prod: 프로덕션 에이전트를 위한 브랜치
  • Dev1: 에이전트 개발을 위한 브랜치
  • Dev2: 에이전트 개발을 위한 또 다른 브랜치

사용자 1이 에이전트 변경을 제안하려고 하며 다음 단계를 따릅니다.

  1. 프로덕션 에이전트를 새 에이전트로 내보냅니다.
  2. 이 에이전트 사본을 원하는 대로 변경합니다.
  3. 변경사항을 테스트합니다.
  4. 변경된 에이전트를 Dev1 브랜치로 푸시합니다.
  5. Prod 브랜치에 대한 병합 요청을 만듭니다.

사용자 2가 에이전트 변경을 제안하려고 하며 다음 단계를 따릅니다.

  1. 프로덕션 에이전트를 새 에이전트로 내보냅니다.
  2. 이 에이전트 사본을 원하는 대로 변경합니다.
  3. 변경사항을 테스트합니다.
  4. 변경된 에이전트를 Dev2 브랜치로 푸시합니다.
  5. Prod 브랜치에 대한 병합 요청을 만듭니다.

사용자 3이 두 사용자의 병합 요청을 검토하고 다음 단계를 따릅니다.

  1. 충돌을 해결합니다.
  2. 승인된 변경사항을 커밋합니다.
  3. 프로덕션 GitHub 브랜치를 프로덕션 대화형 에이전트(Dialogflow CX) 에이전트로 복원합니다.
이전
세션
다음
Sentiment