버전 제어를 사용하여 파이프라인 프로젝트 관리

버전 제어를 사용하여 파이프라인 프로젝트의 개발을 관리하고 변경 사항을 추적할 수 있습니다.

버전 제어로 작업할 때 설계 중에 프로젝트의 버전을 커밋할 수 있습니다. 이를 통해 프로젝트의 두 버전 간의 변경 사항을 확인할 수 있습니다. 또한 브랜칭 전략을 사용하여 데이터 프로젝트를 개발할 수 있습니다. 이를 통해 각 작업 영역 또는 브랜치에서 격리된 버전의 프로젝트에 대해 작업할 수 있습니다. 작업 영역은 여러 사용자가 공유할 수 있습니다. 그런 다음 작업 영역의 변경 사항을 기본 브랜치로 병합하여 프로덕션에 배포할 수 있습니다.

GitHub는 버전 제어 공급자로 사용됩니다. 구현은 공유 리포지토리 모델을 따릅니다.

• GitHub Enterprise Cloud 및 GitHub Enterprise Server는 지원되지 않습니다.

• 공유 리포지토리 모델에 대한 자세한 내용은 협업 개발 모델 정보를 참조하십시오.

• Git 및 GitHub에 대한 자세한 내용은 GitHub 및 Git 정보를 참조하십시오.

• GitHub 보안 고려 사항

  Qlik Talend Cloud는 GitHub의 기본 인증 모드인 HTTPS 보안 프로토콜 및 개인 액세스 토큰(PAT)을 지원합니다. 자세한 내용은 GitHub 인증 정보를 참조하십시오.

시작하기

• 테넌트가 GitHub에 액세스하는 데 사용할 수 있는 사용자를 GitHub에 만듭니다. 관리자가 이미 생성했을 수도 있습니다.

  사용자는 다음 범위를 가져야 합니다.

  • repo

  • read:org

  • read:user

  • read:project

• 변경하려는 리포지토리에 대한 쓰기 액세스 권한이 필요합니다.

• GitHub 개인 액세스 토큰(클래식)을 생성해야 합니다. 세분화된 개인 액세스 토큰은 지원되지 않습니다.

  자세한 내용은 GitHub 설명서: 개인 액세스 토큰 관리를 참조하십시오.

• 조직은 GitHub 구성에서 필수입니다.

• 버전 제어 작업을 수행하려면 프로젝트가 있는 공간에서 편집 가능 역할이 필요합니다.

• 버전 제어 사용을 시작하려면 먼저 생성한 GitHub 사용자로 GitHub에 연결하도록 구성을 설정해야 합니다.

  GitHub에 대한 구성 설정

• GitHub에 대한 연결을 설정하면 프로젝트를 리포지토리에 연결할 수 있습니다.

  프로젝트를 리포지토리에 연결

GitHub에 대한 구성 설정

버전 제어로 작업하려는 모든 사용자는 GitHub 사용자 계정을 사용하여 GitHub에 연결하도록 구성을 설정해야 합니다.

파이프라인 프로젝트 또는 사용자 프로필 설정에서 GitHub를 구성할 수 있습니다. 시작하기에 따라 준비했는지 확인하십시오.

파이프라인 프로젝트에서 GitHub를 구성하려면:

1. 를 클릭한 다음 GitHub 구성을 클릭합니다.

2. 조직 및 시작하기에 설명된 GitHub 개인 액세스 토큰을 사용하여 인증을 설정합니다.

3. 확인을 클릭합니다.

이제 프로젝트를 리포지토리에 연결할 수 있습니다.

프로젝트를 리포지토리에 연결

버전 제어 사용을 시작하려면 먼저 프로젝트를 리포지토리에 연결해야 합니다. GitHub에 대한 연결을 설정했는지 확인하십시오.

1. 파이프라인 프로젝트에서 프로젝트의 ...을 클릭하고 버전 제어에 연결을 선택합니다.

2. 프로젝트를 연결할 리포지토리를 선택합니다.

3. 기본 디렉터리 경로를 추가합니다.

   GitHub의 기존 프로젝트에 연결하려면 동일한 경로를 사용해야 합니다.

4. 연결 후 프로젝트를 커밋하고 원격 리포지토리로 푸시하도록 선택할 수 있습니다. 커밋 메시지를 입력합니다.

   커밋하고 푸시하지 않으면 작업 영역에 기본 브랜치가 생성되지만 원격 리포지토리에는 생성되지 않습니다.

5. 연결을 클릭합니다.

이제 프로젝트가 선택한 리포지토리에 연결되었습니다. 이는 프로젝트 카드 하단에 , 리포지토리 이름 및 현재 브랜치로 표시됩니다.

프로젝트를 열면 이제 제목 행에 버전 제어 옵션이 있는 GitHub 메뉴가 포함됩니다. 프로젝트 이름에도 현재 브랜치의 이름이 추가됩니다.

버전 제어를 사용하여 프로젝트 개발

다양한 접근 방식으로 버전 제어를 사용할 수 있습니다.

• 기본 브랜치에서 직접 작업합니다. 이는 주로 변경 사항을 추적하려는 프로젝트의 단일 개발자에게 적합하지만 동기화하여 작업하는 개발자 그룹에서도 사용할 수 있습니다.

• 여러 개발자가 기여할 수 있는 브랜칭 전략으로 작업합니다. 또한 브랜치를 생성하여 새로운 기능이나 변경 사항을 서로 격리할 수 있습니다.

단일 개발자 프로젝트를 위한 단순화된 워크플로

프로젝트의 기본 브랜치에서 직접 작업할 수 있습니다. 이 접근 방식은 더 간단하고 작업 수가 적지만 여전히 변경 사항을 추적할 수 있습니다. 개발자가 두 명 이상인 경우 동기화되도록 주의해야 합니다.

적용하려는 프로젝트를 변경한 경우 커밋 및 푸시를 수행하기만 하면 됩니다.

다중 개발자 프로젝트를 위한 워크플로

이 워크플로는 프로젝트에서 작업하는 개발자가 두 명 이상이거나 변경 사항을 격리하려는 경우에 사용할 수 있습니다. 여기에는 다른 사용자와 공유할 수 있는 개발 브랜치를 생성하는 작업이 포함됩니다. 이 워크플로를 통해 개발자는 서로의 변경 사항을 추적하고 변경 사항을 기본 브랜치에 병합할 시기를 결정할 수 있습니다.

1. 새 브랜치 생성

   기본 브랜치에서 새 개발 브랜치를 생성합니다. 더 많은 사용자와 브랜치를 공유할 수 있습니다.

2. 개발

   프로젝트에서 필요한 모든 변경을 수행합니다.

   정보 메모데이터베이스 스키마 및 연결은 버전 제어에서 유지 관리되지 않습니다.

3. 원격 변경 사항 적용

   다른 브랜치의 원격 변경 사항을 작업 영역에 적용하여 다른 브랜치의 변경 사항으로 최신 상태를 유지합니다. 이는 충돌하는 변경 사항을 방지하거나 완화하는 데 도움이 됩니다.

   충돌할 수 있는 변경 사항이 포함된 두 개의 브랜치가 있는 경우 해결 방법은 다음과 같습니다.

   1. 두 작업 영역 모두에 변경 사항을 커밋합니다.

   2. 두 브랜치를 기본으로 병합합니다.

   3. 원격 변경 사항을 다시 적용합니다.

4. 커밋 및 푸시

   변경 사항을 개발 브랜치에 커밋하고 푸시합니다. 모든 개체가 푸시되므로 커밋하기 전에 프로젝트의 유효성을 검사하는 것이 좋습니다.

5. 풀 리퀘스트 생성 및 병합

   개발이 준비되면 작업 영역의 변경 사항을 기본 브랜치로 병합할 때입니다.

   프로젝트 버전 제어에서 풀 리퀘스트를 생성할 수 있지만 병합은 승인을 설정할 수도 있는 GitHub에서 수행해야 합니다. 자세한 내용은 GitHub 풀 리퀘스트 설명서를 참조하십시오.

새 브랜치 생성

1. 프로젝트에서 GitHub를 클릭하고 새 브랜치 생성을 선택합니다.

   프로젝트는 버전 제어에 연결되어 있어야 합니다. 또한 프로젝트의 대상 연결이 있는 공간에 대한 권한이 있어야 합니다.

2. 기본 브랜치에서 브랜치를 생성하도록 선택합니다.

3. 브랜치의 이름을 입력합니다.

4. 모든 스키마의 브랜치 접두사에서 프로젝트의 모든 스키마에 추가할 접두사를 설정합니다. 이를 통해 모든 스키마의 이름을 고유하게 지정하여 이름 지정 충돌을 방지할 수 있습니다.

5. 생성을 클릭합니다.

기본에서 새 브랜치가 생성되고 리포지토리에서 체크아웃됩니다. 브랜치에는 모든 작업이 신규 상태인 프로젝트의 새 버전이 포함되어 있습니다. 즉, 준비되지 않았으며 데이터가 포함되어 있지 않습니다.

원격 변경 사항 적용

원격 리포지토리의 변경 사항을 작업 영역에 적용할 수 있습니다. 이는 GitHub 또는 다른 도구와 같이 Qlik Cloud 통합 버전 제어 외부에서 생성된 변경 사항일 수 있습니다. 이는 변경 사항을 브랜치에 커밋하고 푸시할 때 충돌을 방지하는 데 도움이 됩니다.

1. 프로젝트에서 GitHub를 클릭하고 원격 변경 사항 적용을 선택합니다.

   변경 사항이 발견되면 작업 영역에 원격 변경 사항 적용 대화 상자가 표시됩니다.

2. 이제 변경 사항을 적용할 작업을 선택하고 변경 사항을 검사할 수 있습니다. 각 변경 사항에 대해 원격 버전 또는 작업 영역의 버전 중 사용할 버전을 선택할 수 있습니다.

   프로젝트와 가져온 프로젝트 간에 다른 매핑 연결에 대해 필요한 변경을 수행합니다.

   예를 들어 가져온 프로젝트는 SQL1이라는 소스 연결을 사용할 수 있지만 이 프로젝트는 SQL2라는 유사한 연결을 사용합니다. 이 경우 원본 버전에 추가된 작업에 대한 연결 설정에서 가져온 연결을 SQL2에 매핑합니다.

   변경 사항에 교차 프로젝트 소스가 포함되어 있고 참조된 프로젝트가 버전 제어 하에 있는 경우 각 교차 프로젝트 소스에 대해 브랜치 선택기를 사용할 수 있습니다. 사용할 브랜치를 선택합니다. 참조된 프로젝트가 버전 제어 하에 있지 않으면 브랜치 선택기가 표시되지 않습니다.

   정보 메모매핑할 연결을 선택할 때 새 데이터베이스 연결을 생성할 수 있지만 SaaS 응용 프로그램 연결은 생성할 수 없습니다.

3. 원격 변경 사항 적용을 클릭합니다.

변경 사항에 새 데이터 작업이 포함된 경우 소스 연결 및 대상 연결을 추가해야 합니다.

커밋 및 푸시

변경 사항을 브랜치에 커밋하고 푸시할 수 있습니다. 작업 영역에 적용되지 않은 원격 변경 사항을 덮어쓸 수 있으므로 커밋 및 푸시하기 전에 원격 변경 사항 적용을 수행해야 합니다.

1. 프로젝트에서 GitHub를 클릭하고 커밋 및 푸시를 선택합니다.

   변경 사항이 발견되면 커밋 및 푸시 대화 상자가 표시됩니다.

2. 변경된 내용을 추적하는 데 도움이 되는 커밋 메시지를 추가합니다.

3. 커밋 및 푸시를 클릭합니다.

풀 리퀘스트 생성

작업 영역의 변경 사항을 기본 브랜치로 병합하기 위한 풀 리퀘스트(PR)를 생성합니다.

1. 프로젝트에서 프로젝트의 GitHub를 클릭하고 풀 리퀘스트 생성을 선택합니다.

   풀 리퀘스트 생성 대화 상자가 표시됩니다.

2. 풀 리퀘스트의 제목과 설명을 추가합니다.

   생성 후 GitHub에서 풀 리퀘스트를 열도록 선택할 수도 있습니다.

3. 풀 리퀘스트 생성을 클릭합니다.

이제 풀 리퀘스트에 대한 승인을 설정하고 GitHub에서 병합을 수행할 수 있습니다.

브랜치 삭제

변경 사항을 기본 브랜치에 병합한 후 브랜치를 삭제할 수 있습니다.

1. 프로젝트에서 삭제할 브랜치를 클릭하고 브랜치 삭제를 선택합니다.

   버전 제어에서 원격 브랜치도 삭제하도록 선택할 수 있습니다.

   커밋되지 않은 변경 사항이 있는 경우 브랜치를 삭제할 때 이러한 변경 사항이 손실됨을 확인해야 합니다.

프로젝트의 버전 제어 제거

프로젝트를 버전 제어에서 연결 해제할 수 있습니다. 기존 브랜치가 있는 경우 프로젝트를 연결 해제하기 전에 삭제해야 합니다.

1. 파이프라인 프로젝트에서 연결 해제할 프로젝트의 ...을 클릭하고 GitHub에서 연결 해제를 선택합니다.

버전 제어에서 프로젝트 가져오기

예를 들어 다른 개발자의 프로젝트를 검토하거나 프로젝트에서 협업하려는 경우 버전 제어에서 프로젝트를 가져올 수 있습니다. 버전 제어에서 프로젝트를 가져오면 다른 공간이나 테넌트와 프로젝트를 공유할 수도 있습니다. 동일한 테넌트의 다른 공간이나 다른 테넌트와 프로젝트 버전을 공유할 수 있습니다. 이는 개발용과 프로덕션용 등 두 가지 환경을 생성하려는 경우에 유용합니다."

프로젝트를 가져오기 전에

프로젝트 가져오기를 시작하기 전에:

• 새 테넌트 또는 공간으로 가져오는 경우 필요한 모든 새 연결을 생성합니다.

• 프로젝트에서 테넌트 또는 공간에 아직 존재하지 않는 SaaS 응용 프로그램 연결을 사용하는 경우 가져오기를 시작하기 전에 연결을 생성하고 메타데이터를 생성해야 합니다.

• 교차 프로젝트 파이프라인을 가져오는 경우 업스트림 프로젝트를 먼저 가져와야 합니다.

프로젝트 가져오기

프로젝트가 다른 프로젝트의 작업을 사용하는 경우 공간 및 프로젝트의 이름이 동일하지 않는 한 프로젝트와 작업을 매핑해야 합니다.

1. 데이터 통합 > 프로젝트에서 새로 만들기를 클릭하고 버전 제어에서 프로젝트 가져오기를 선택합니다.

2. 리포지토리를 선택한 다음 브랜치를 선택합니다.

   필요한 경우 기본 디렉터리 경로를 선택하고 프로젝트 표시를 클릭합니다.

   목록에서 가져올 프로젝트를 선택합니다.

   다음을 클릭합니다.

3. 새 프로젝트에 대한 프로젝트 속성을 설정합니다.

   공간에서 프로젝트를 추가할 공간을 선택해야 합니다.

   데이터 플랫폼에서 프로젝트의 데이터 플랫폼 및 데이터 플랫폼에 대한 연결을 변경할 수 있습니다.

   다른 테넌트에서 프로젝트를 가져왔거나 이전 단계에서 데이터 플랫폼을 변경한 경우 연결을 변경해야 합니다.

   스테이징 영역에 대한 연결을 변경할 수 있습니다. 이는 다른 테넌트에서 프로젝트를 가져왔거나 경우에 따라 이전 단계에서 데이터 플랫폼을 변경한 경우에 필요합니다.

   다음을 클릭합니다.

4. 새 프로젝트에 대한 기본 프로젝트 설정을 설정합니다.

   모든 스키마의 접두사에서 프로젝트에 생성된 데이터 스키마에 접두사를 추가할 수 있습니다. 이는 가져온 프로젝트가 내보낸 프로젝트와 동일한 클라우드 데이터 웨어하우스에 있는 경우에 유용합니다.

   또한 데이터베이스 이름에서 기본 이름을 설정할 수 있습니다. Snowflake 프로젝트의 경우 기본 데이터 웨어하우스 이름을 설정할 수 있으며 Databricks 프로젝트의 경우 기본 카탈로그 이름을 설정할 수 있습니다. 모든 작업 유형에 프로젝트 기본 이름을 사용하거나 각 작업 유형에 대해 이름을 기본값 또는 사용자 지정 이름으로 설정할 수 있습니다.

   다음을 클릭합니다.

5. 연결 및 작업 설정을 설정합니다.

   가져온 소스 연결 또는 교차 프로젝트 소스를 바꿀 수 있습니다. 이는 다른 테넌트에서 프로젝트를 가져온 경우에 필요합니다.

   교차 프로젝트 소스를 버전 제어 하에 있는 프로젝트에 매핑할 때 브랜치 선택기를 사용할 수 있습니다. 사용할 참조된 프로젝트의 브랜치를 선택합니다. 참조된 프로젝트가 버전 제어 하에 있지 않으면 브랜치 선택기가 표시되지 않습니다. 교차 프로젝트 소스가 기본이 아닌 브랜치에 매핑된 경우 브랜치 이름이 프로젝트 이름 옆의 괄호 안에 표시됩니다.

   선택적 작업 설정에서 원본 프로젝트에서 재정의된 작업 설정을 변경할 수도 있습니다.

6. 준비가 되면 가져오기를 클릭합니다.

프로젝트가 데이터 통합 홈에 추가됩니다.

버전 제어에서 가져온 프로젝트 작업

일반적인 버전 제어 프로젝트와 동일한 방식으로 작업하지만 몇 가지 차이점이 있습니다.

• 기본 브랜치 또는 버전 제어에서 가져온 다른 브랜치로만 전환할 수 있습니다.

• 브랜치에서 가져온 경우 기본 브랜치는 비어 있습니다.

• 프로젝트를 삭제해도 원격 버전은 삭제되지 않습니다.

보안 고려 사항

Qlik Talend Data Integration 및 GitHub 간에 동기화된 보안 구성을 유지 관리해야 합니다.

• Qlik Talend Data Integration에서 권한은 여러 프로젝트가 포함될 수 있는 공간을 기반으로 합니다. GitHub에서 권한은 여러 프로젝트가 포함될 수 있는 리포지토리를 기반으로 합니다. 모범 사례는 이를 정렬하고 한 공간의 모든 프로젝트를 동일한 리포지토리에 연결하는 것입니다.

• Qlik Talend Data Integration 및 GitHub는 사용자에 대해 서로 다른 권한과 역할을 사용한다는 점을 명심하십시오.

모범 사례

다음은 버전 제어를 사용하여 프로젝트로 작업할 때의 몇 가지 일반적인 모범 사례입니다.

• GitHub의 리포지토리를 설명하는 README 파일을 추가합니다. 자세한 내용은 README 정보를 참조하십시오.

  빈 리포지토리로 시작하는 경우 Qlik Talend Cloud 버전 제어에서 빈 README.md 파일을 자동으로 추가합니다.

• 일반적으로 Qlik Talend Cloud 버전 제어에서 GitHub 리포지토리를 관리하도록 해야 합니다.

• 유효하고 실행되도록 테스트된 프로젝트만 커밋합니다.

  준비되거나 변환되지 않은 랜딩 또는 등록된 데이터 작업이 있는 프로젝트를 추가하는 경우 소스 열이 아직 포함되지 않습니다. 소스 열은 작업이 준비되고 변환될 때 추가됩니다.

• 복제 프로젝트에 대한 브랜치를 생성할 때 브랜치가 기본적으로 동일한 대상을 사용한다는 점에 유의해야 합니다. 즉, 브랜치에서 작업을 실행하면 기본 버전의 데이터를 덮어쓸 수 있습니다. 데이터 손실을 방지하려면 기본 버전과 충돌하지 않도록 브랜치의 대상 설정을 변경하십시오.

• 브랜치를 생성할 때 작업 영역에 아직 적용되지 않은 원격 변경 사항이 있을 수 있습니다. 원격 변경 사항을 삭제하지 않으려면 브랜치를 생성하기 전이나 후에 원격 변경 사항을 적용하십시오.

• 두 개의 다른 브랜치에서 동일한 데이터 세트를 변경하면 해결하기 어려운 병합 충돌이 발생하고 데이터 세트가 다시 생성될 수 있습니다.

  정보 메모데이터 세트가 작업에 추가되면 내부 식별자를 얻습니다. 내부 식별자는 파이프라인에서 원활한 이름 바꾸기 및 기타 메타데이터 작업을 허용하는 데 사용됩니다. 별도의 프로젝트 또는 브랜치에서 동일한 데이터 세트를 생성할 때 내부 식별자가 달라져 두 브랜치를 병합할 때 충돌이 발생할 수 있습니다. 이로 인해 준비 프로세스에서 이름이 같더라도 데이터 세트를 삭제하고 다시 생성할 수 있습니다.

브랜치에서 작업

프로젝트를 생성하고 설계한 다음 준비가 되면 MAIN 브랜치를 사용하여 프로덕션에 배포할 수 있습니다. MAIN의 버전은 프로덕션 파이프라인에 해당합니다. 첫 번째 배포 이후에는 MAIN 브랜치를 직접 편집해서는 안 됩니다.

개발자가 기능 추가 또는 버그 수정과 같이 프로젝트에 새로운 변경을 수행하려는 경우 새 브랜치를 생성해야 합니다.

개발자는 개발 요구 사항에 맞게 원하는 수의 브랜치를 생성할 수 있습니다.

• 변경하는 동안 데이터베이스 충돌을 방지하려면 브랜치에 스키마 접두사를 사용하십시오.

• 브랜치에서 개발자는 원하는 수의 변경을 수행하고 필요한 만큼 커밋 및 푸시할 수 있습니다. 각 변경 사항을 독립적이고 별도의 커밋으로 격리하는 것이 좋습니다. 예를 들어 데이터 마트에도 영향을 미치는 변환 작업을 변경하는 경우 단일 커밋 내에 두 변경 사항을 모두 포함해야 합니다.

• 모든 팀 구성원은 특히 변경 사항을 커밋하기 전에 MAIN이 최신 상태인지 확인하기 위해 언제든지 원격 변경 사항 적용을 사용해야 합니다.

개발자가 브랜치에서 작업을 완료하면 동료 검토를 위한 풀 리퀘스트를 생성할 수 있습니다.

다른 팀 구성원의 검토 및 승인 후 GitHub에서 풀 리퀘스트를 MAIN 버전과 병합할 수 있습니다.

마지막으로 프로젝트에서 원격 변경 사항 적용을 사용하여 승인된 브랜치 변경 사항을 MAIN 브랜치(프로덕션)로 다시 가져옵니다.

공간에서 작업

대규모의 중요한 배포의 경우 변경 사항을 격리하고 파이프라인 무결성을 보장하기 위해 개발 및 프로덕션 전용 공간을 사용하는 것이 좋습니다. 각 공간의 소스 및 대상에 전용 데이터 연결을 사용하십시오.

• 프로덕션

  MAIN 브랜치는 프로덕션에 있는 내용을 반영합니다. 즉, 프로젝트의 MAIN 버전은 하나만 있습니다.

  프로덕션은 전용 데이터 공간(예: PROD)에 격리됩니다. 전용 연결이 프로덕션 공간에 할당됩니다.

  프로덕션 공간/MAIN 브랜치에서 직접 변경되지 않습니다. 모든 변경 사항은 브랜치를 사용하여 전용 연결이 있는 다른 공간에서 수행됩니다.

  GitHub에서 기존 프로젝트의 MAIN 버전을 재사용할 수 있습니다. GitHub의 기존 프로젝트와 동일한 이름으로 빈 프로젝트를 생성합니다. 이렇게 하면 편집을 시작하기 위해 MAIN 브랜치에서 사용 가능한 최신 버전을 검색합니다.

  사용자는 새 브랜치를 생성하고, 변경을 수행하고, 풀 리퀘스트를 생성하고, 병합하고, MAIN/프로덕션으로 다시 가져옵니다.

• 개발

  개발자는 전용 데이터 공간(예: DEV)에서 변경 사항을 격리할 수 있습니다. 전용 연결이 DEV 공간에 할당됩니다.

  변경 사항은 브랜치(일반적으로 개발자당 하나의 브랜치)를 사용하여 격리됩니다. 변경하는 동안 데이터베이스 충돌을 방지하려면 브랜치가 생성될 때 스키마 접두사를 사용하십시오.

• 검토 / 품질 수용

  검토자에게는 개발 공간 및 다음에 대한 연결에 대한 액세스 권한이 부여됩니다.

  • Qlik Talend Cloud에서 프로젝트 브랜치를 열고 테스트합니다.

  • GitHub에서 병합을 진행하기 위해 풀 리퀘스트를 승인합니다.

  • 승인된 변경 사항을 MAIN/프로덕션으로 다시 가져올 수 있을 때 팀 구성원에게 알립니다.

승인된 변경 사항을 MAIN/프로덕션 공간에 다시 배포할 때 연결을 프로덕션 공간 연결에 다시 할당해야 합니다.

제한 사항

• Qlik Cloud(QVD)를 대상으로 하는 프로젝트에는 버전 제어가 지원되지 않습니다.

• 브랜치가 있는 경우 버전 제어를 사용하여 프로젝트를 연결 해제하거나 삭제할 수 없습니다. 프로젝트를 연결 해제하거나 삭제하려면 먼저 브랜치를 삭제해야 합니다.

• 버전 제어를 사용하여 프로젝트의 이름을 바꿀 수 없습니다.

• 테넌트를 삭제해도 GitHub의 버전 제어에 저장된 개체는 삭제되지 않습니다. 이러한 개체는 수동으로 삭제해야 합니다.

• 리포지토리가 많은 프로젝트에서 사용되거나 Qlik Talend Data Integration에 저장되지 않은 파일이 많이 포함된 경우 성능이 저하될 수 있습니다.

• 데이터베이스 스키마 및 연결은 버전 제어에서 유지 관리되지 않습니다.

• GitHub의 세분화된 개인 액세스 토큰은 지원되지 않습니다.

• 두 프로젝트가 동일한 리포지토리에 있더라도 브랜치(기본 브랜치 제외)는 리포지토리당 하나의 프로젝트에서만 사용할 수 있습니다.

• 다른 대상 플랫폼을 사용하는 프로젝트의 원격 변경 사항은 적용할 수 없습니다. 예를 들어 Snowflake의 프로젝트에 변경 사항을 커밋하는 경우 Databricks 프로젝트에 변경 사항을 적용할 수 없습니다.