Azure Data Factory의 소스 제어

적용 대상: Azure Data Factory Azure Synapse Analytics

팁

기업용 올인원 분석 솔루션인 Microsoft Fabric의 Data Factory를 사용해 보세요. Microsoft Fabric은 데이터 이동부터 데이터 과학, 실시간 분석, 비즈니스 인텔리전스 및 보고에 이르기까지 모든 것을 다룹니다. 무료로 새 평가판을 시작하는 방법을 알아봅니다!

기본적으로는 Azure Data Factory 사용자 인터페이스 환경(UX) 작성자는 데이터 팩터리 서비스에서 직접 작성합니다. 이 환경에는 다음과 같은 제한 사항이 있습니다.

• Data Factory 서비스는 사용자의 변경 사항을 위한 JSON 엔터티를 저장하는 리포지토리를 포함하지 않습니다. 변경 내용을 저장하는 유일한 방법은 모두 게시 단추를 사용하는 것이며 모든 변경 내용은 데이터 팩터리 서비스에 직접 게시됩니다.
• Data Factory 서비스는 협업 및 버전 제어에 최적화되어 있지 않습니다.
• Data Factory 자체를 배포하는 데 필요한 Azure Resource Manager 템플릿이 포함되어 있지 않습니다.

작성 환경을 개선하기 위해 Azure Data Factory를 사용하면 Azure Repos 또는 GitHub를 사용하여 Git 리포지토리를 구성할 수 있습니다. Git는 변경 내용 추적과 협업 환경을 개선할 수 있는 버전 제어 시스템입니다. 이 문서에서는 git 리포지토리에서 구성하고 작업하는 방법과 함께 모범 사례 및 문제 해결 가이드를 간략하게 설명합니다.

또한 Azure Data Factory에서 CI/CD(연속 통합 및 지속적인 업데이트)를 참조하여 소스 제어가 중요한 측면인 더 큰 CI/CD 패턴에 대해 자세히 알아볼 수 있습니다.

참고 항목

21Vianet에서 운영하는 Azure Gov 및 Microsoft Azure에 GitHub 공용 지원을 추가했습니다. 공지 블로그를 참조하세요.

Azure Data Factory와 Git를 통합하는 방법에 대한 자세한 내용은 아래의 15분 자습서 비디오를 참조하세요.

Git 통합의 장점

Git 통합이 작성 환경에 제공하는 일부 장점이 아래에 나열되어 있습니다.

• 소스 제어: 데이터 팩터리 워크로드가 중요해지면서 팩터리를 Git에 통합하여 다음과 같은 여러 소스 제어 이점을 적용할 수 있습니다.
  • 변경 내용을 추적/감사할 수 있습니다.
  • 버그를 발생한 변경 내용을 되돌릴 수 있습니다.
• 부분 저장: 데이터 팩터리 서비스에서 직접 작성하면 변경 내용을 초안으로 저장할 수 없으며 모든 게시는 데이터 팩터리 유효성 검사를 통과해야 합니다. 파이프라인이 완료되지 않았거나 컴퓨터가 충돌할 때 변경 내용을 손실하지 않으려는 경우 git 통합을 사용하면 데이터 팩터리 리소스의 상태에 관계없이 데이터 팩터리 리소스를 증분 방식으로 변경할 수 있습니다. git 리포지토리를 구성하면 변경 내용을 저장할 수 있으므로 변경 내용을 만족할 때까지 테스트한 후에만 게시할 수 있습니다.
• 협업 및 제어: 동일한 팩터리에 기여하는 팀 멤버가 여러 명인 경우에는 코드 검토 프로세스를 통해 팀원이 서로 협업하도록 할 수 있습니다. 일부 기여자는 다른 권한을 갖도록 팩터리를 설정할 수도 있습니다. 일부 팀 멤버는 Git을 통해서만 변경할 수 있고, 팀에서 특정 사용자만 팩터리에 변경 내용을 게시하도록 허용할 수 있습니다.
• CI/CD 향상: 지속적인 업데이트 프로세스를 통해 여러 환경에 배포하는 경우 GIT 통합을 통해 특정 작업을 더 쉽게 수행할 수 있습니다. 이러한 작업 중 일부는 다음과 같습니다.
  • 'dev' 팩터리에 변경 사항이 생기는 즉시 자동으로 트리거되도록 릴리스 파이프라인을 구성합니다.
  • Resource Manager 템플릿에서 매개 변수로 사용할 수 있는 속성을 팩터리에서 사용자 지정합니다. 필수 속성 세트만 매개 변수로 유지하고 다른 모든 항목은 하드 코딩하면 유용할 수 있습니다.
• 성능 향상: git 통합을 사용하는 평균 팩터리는 데이터 팩터리 서비스에서 작성하는 경우보다 10배 더 빨리 로드됩니다. 이러한 성능 향상은 리소스가 Git를 통해 다운로드되기 때문입니다.

참고 항목

Git 리포지토리가 구성되면 Azure Data Factory UX에서 Data Factory 서비스를 사용하여 직접 작성할 수 없습니다. PowerShell 또는 SDK를 통해 변경한 내용은 Data Factory 서비스에 직접 게시되며 Git에 입력되지 않습니다.

Git 리포지토리에 연결

Azure Repos 및 GitHub 모두에 대한 데이터 팩터리에 Git 리포지토리를 연결하는 방법에는 네 가지가 있습니다. Git 리포지토리에 연결한 후 관리 허브에서 원본 제어 섹션의 Git 구성에서 구성을 보고 관리할 수 ​​있습니다.

구성 방법 1: 홈페이지

Azure Data Factory 홈페이지 맨 위에 있는 코드 리포지토리 설정을 선택합니다.

구성 방법 2: 제작 캔버스

Azure Data Factory UX 제작 캔버스에서 Data Factory 드롭다운 메뉴를 선택한 다음, 코드 리포지토리 설정을 선택합니다.

구성 방법 3: 관리 허브

Azure Data Factory 스튜디오의 관리 허브로 이동합니다. 소스 제어 섹션에서 Git 구성을 선택합니다. 연결된 리포지토리가 없는 경우 구성을 선택합니다.

구성 방법 4: 팩터리를 만드는 동안

Azure Portal에서 새 데이터 팩터리를 만들 때 Git 구성 탭에서 Git 리포지토리 정보를 구성할 수 있습니다.

참고 항목

Azure Portal에서 Git을 구성할 때 프로젝트 이름 및 리포지토리 이름과 같은 설정은 드롭다운에 포함되지 않고 수동으로 입력해야 합니다.

Azure Repos Git 통합을 통한 작성

Azure Repos Git 통합을 통한 시각적 작성은 데이터 팩터리 파이프라인에서 작업하기 위한 원본 제어 및 협업을 지원합니다. 사용자는 원본 제어, 협업, 버전 관리 등을 위해 Azure Repos Git 조직 리포지토리와 데이터 팩터리를 연결할 수 있습니다. 단일 Azure Repos Git 계정이 여러 리포지토리를 포함할 수는 있지만 각 Azure Repos Git 리포지토리는 데이터 팩터리 하나에만 연결할 수 있습니다. Azure Repos 조직 또는 리포지토리가 없는 경우 이러한 지침에 따라 리소스를 만듭니다.

참고 항목

Azure Repos Git 리포지토리에 스크립트 및 데이터 파일을 저장할 수 있습니다. 그러나 Azure Storage에 파일을 수동으로 업로드해야 합니다. 데이터 팩터리 파이프라인은 Azure Repos Git 리포지토리에 저장된 스크립트 또는 데이터 파일을 Azure Storage에 자동으로 업로드하지 않습니다. ARM 템플릿, 스크립트 또는 구성 파일과 같은 추가 파일은 매핑된 폴더 외부의 리포지토리에 저장할 수 있습니다. 이렇게 하는 경우 매핑된 Azure DevOps 폴더 외부에 저장된 파일을 빌드/배포하고 상호 작용하는 데 추가 작업이 필요합니다.

Azure Repos 설정

구성 창에서는 다음 코드 리포지토리 설정을 각각 구성하는 단계를 단계별로 안내합니다.

설정	설명	값
리포지토리 유형	Azure Repos 코드 리포지토리의 유형입니다.	Azure DevOps Git 또는 GitHub
Microsoft Entra ID	Microsoft Entra 테넌트 이름입니다.	<your tenant name>
Azure Repos 조직	Azure Repos 조직 이름입니다. Azure Repos 조직 이름은 https://{organization name}.visualstudio.com에서 확인할 수 있습니다. Azure Repos 조직에 로그인하여 Visual Studio 프로필에 액세스하고 리포지토리 및 프로젝트를 확인할 수 있습니다.	<your organization name>
ProjectName	Azure Repos 프로젝트 이름입니다. Azure Repos 프로젝트 이름은 https://{organization name}.visualstudio.com/{project name}에서 확인할 수 있습니다.	<your Azure Repos project name>
RepositoryName	Azure Repos 코드 리포지토리 이름입니다. Azure Repos 프로젝트는 프로젝트가 확장됨에 따라 소스 코드를 관리하기 위한 Git 리포지토리를 포함합니다. 새 리포지토리를 만들거나 프로젝트에 이미 있는 기존 리포지토리를 사용할 수 있습니다.	<your Azure Repos code repository name>
협업 분기	게시에 사용되는 Azure Repos 협업 분기입니다. 기본적으로 main입니다. 다른 분기에서 리소스를 게시하려는 경우 이 설정을 변경합니다.	<your collaboration branch name>
분기 게시	게시 분기는 게시 관련 ARM 템플릿이 저장 및 업데이트되는 리포지토리의 분기입니다. 기본적으로 adf_publish입니다.	<your publish branch name>
루트 폴더	Azure Repos 협업 분기의 루트 폴더입니다.	<your root folder name>
리포지토리로 기존 Data Factory 리소스 가져오기	UX 제작 캔버스에서 기존 데이터 팩터리 리소스를 Azure Repos Git 리포지토리로 가져올 것인지를 지정합니다. JSON 형식의 연결된 Git 리포지토리로 데이터 팩터리 리소스를 가져오려면 상자를 선택합니다. 이 작업은 각 리소스를 개별적으로 내보냅니다(즉, 연결된 서비스 및 데이터 세트를 별도 JSON으로 내보냄). 이 상자를 선택하지 않으면 기존 리소스를 가져오지 않습니다.	선택됨(기본값)
리소스를 가져올 분기	데이터 팩터리 리소스(파이프라인, 데이터 세트, 연결된 서비스 등)를 가져올 분기를 지정합니다. 다음 분기 중 하나로 리소스를 가져올 수 있습니다. a. 협업 b. 새로 만들기 c. 기존 항목 사용

참고 항목

Microsoft Edge를 사용하는 경우 Azure DevOps 계정 드롭다운에 값이 표시되지 않으면 신뢰할 수 있는 사이트 목록에 https://*.visualstudio.com을 추가합니다.

리포지토리 설정 편집

구성된 Azure Repos Git 리포지토리의 설정을 조정해야 하는 경우 편집하도록 선택할 수 있습니다.

게시 분기를 업데이트하고 ADF 스튜디오에서 게시 단추를 사용하지 않도록 설정할지 여부를 결정할 수 있습니다. 스튜디오에서 게시 단추를 사용하지 않도록 선택하면 게시 단추가 스튜디오에서 회색으로 표시됩니다. 이렇게 하여 마지막 자동화된 게시 배포를 덮어쓰지 않도록 방지할 수 있습니다.

다른 Microsoft Entra 테넌트 사용

Azure Repos Git 리포지토리는 다른 Microsoft Entra 테넌트에 있을 수 있습니다. 다른 Microsoft Entra 테넌트를 지정하려면 사용하고 있는 Azure 구독에 대한 관리자 권한이 있어야 합니다. 자세한 내용은 구독 관리자 변경을 참조하세요.

Important

다른 Microsoft Entra ID에 연결하려면 로그인한 사용자가 해당 Active Directory에 있어야 합니다.

개인 Microsoft 계정 사용

Git 통합에 개인 Microsoft 계정을 사용하려면 개인 Azure 리포지토리를 조직의 Active Directory에 연결하면 됩니다.

1. 개인 Microsoft 계정을 조직의 Active Directory에 게스트로 추가합니다. 자세한 내용은 Azure Portal에서 Microsoft Entra B2B 협업 사용자 추가를 참조하세요.

2. 개인 Microsoft 계정으로 Azure Portal에 로그인합니다. 그런 다음, 조직의 Active Directory로 전환합니다.

3. Azure DevOps 섹션으로 이동하면 이제 개인 리포지토리가 보입니다. 리포지토리를 선택하고 Active Directory와 연결합니다.

이러한 구성 단계 후, Data Factory UI에서 Git 통합을 설정할 때 개인 리포지토리를 사용할 수 있습니다.

Azure Repos를 조직의 Active Directory에 연결하는 방법에 대한 자세한 내용은 Azure DevOps 조직을 Microsoft Entra ID에 연결을 참조하세요.

GitHub 통합을 통한 작성

GitHub 통합을 통한 시각적 작성은 데이터 팩터리 파이프라인에서 작업하기 위한 원본 제어 및 협업을 지원합니다. 사용자는 원본 제어, 협업 및 버전 관리를 위해 GitHub 계정 리포지토리에 데이터 팩터리를 연결할 수 있습니다. 단일 GitHub 계정은 여러 리포지토리를 호스트할 수 있으며, 각 리포지토리를 여러 데이터 팩터리와 연결할 수 있습니다. 동일한 리포지토리 내에서 다른 분기를 사용하도록 각 데이터 팩터리를 구성하면 별도의 환경(예: 개발, 준비 및 프로덕션)을 유지하면서 구성을 독립적으로 관리할 수 있습니다. GitHub 계정 또는 리포지토리가 없는 경우 이러한 지침에 따라 리소스를 만듭니다.

Data Factory와의 GitHub 통합은 공용 GitHub(즉, https://github.com), GitHub Enterprise Cloud 및 GitHub Enterprise 서버를 모두 지원합니다. GitHub의 리포지토리에 대한 읽기 및 쓰기 권한이 있다면 Data Factory를 사용하여 공용 및 프라이빗 GitHub 리포지토리를 모두 사용할 수 있습니다. 퍼블릭 리포지토리에 연결하려면 리포지토리 이름의 드롭다운 메뉴에 표시되지 않으므로 링크 리포지토리 사용 옵션을 선택합니다. ADF의 GitHub 엔터프라이즈 서버 통합은 공식적으로 지원되는 GitHub 엔터프라이즈 서버 버전에서만 작동합니다.

GitHub 조직 계정이 소유한 리포지토리의 경우 관리자는 ADF 앱에 권한을 부여해야 합니다. GitHub 사용자 계정이 소유한 리포지토리의 경우 협력자 이상의 권한이 있는 사용자는 ADF 앱에 권한을 부여할 수 있습니다. 이 권한은 ADF 앱이 계정/조직이 소유한 모든 리포지토리에 직접 액세스할 수 있도록 하지 않으며, ADF 앱이 사용자의 액세스 권한에 따라 사용자를 대신하여 리포지토리에 액세스할 수 있도록 허용합니다.

참고 항목

Microsoft Edge를 사용하는 경우 GitHub Enterprise 버전 2.1.4 미만에서는 작동하지 않습니다. GitHub는 공식적으로 >=3.0을 지원하며 이 모든 것은 ADF에 적합합니다. GitHub의 최소 버전이 변경됨에 따라 ADF 지원 버전도 변경됩니다.

GitHub 설정

참고 항목

오류가 발생하면 GitHub 리포지토리를 나열하지 못했습니다. 계정 이름이 올바르고 작업을 수행할 수 있는 권한이 있는지 확인하세요. GitHub 리포지토리 URL이 아닌 올바른 소유자 이름을 사용하고 있는지 확인합니다. 예를 들어 리포지토리 URL이https://github.com/contoso/contoso-ads면 소유자는 전체 URL이 아닌 contoso입니다.

구성 창에 다음 GitHub 리포지토리 설정이 표시됩니다.

설정	설명	값
리포지토리 유형	Azure Repos 코드 리포지토리의 유형입니다.	GitHub
GitHub Enterprise 서버 사용	GitHub Enterprise 서버를 선택하는 확인란입니다.	선택하지 않음(기본값)
GitHub Enterprise 서버 URL	GitHub Enterprise 루트 URL(로컬 GitHub Enterprise 서버의 HTTPS여야 함) 예: https://github.mydomain.com GitHub Enterprise 서버 사용이 선택된 경우에만 필요합니다.	<your GitHub Enterprise Server URL>
GitHub 리포지토리 소유자	리포지토리를 소유한 GitHub 조직 또는 계정입니다. 이 이름은 https://github.com/{owner}/{repository name}에서 찾을 수 있습니다. 이 페이지로 이동하면 GitHub 조직 또는 계정에 GitHub OAuth 자격 증명을 입력하라는 메시지가 표시됩니다. GitHub Enterprise 서버 사용을 선택하면 액세스 토큰을 입력할 수 있는 대화 상자가 나타납니다.	<your GitHub repository owner name>
리포지토리 이름	GitHub 코드 리포지토리 이름입니다. GitHub 계정은 소스 코드를 관리하기 위한 Git 리포지토리를 포함합니다. 새 리포지토리를 만들거나 계정에 이미 있는 기존 리포지토리를 사용할 수 있습니다. 리포지토리 선택을 선택할 때 GitHub 코드 리포지토리 이름을 지정합니다.	<your repository name>
Git 리포지토리 링크	GitHub 코드 리포지토리 링크. 리포지토리 링크 사용을 선택할 때 GitHub 코드 리포지토리 링크를 지정합니다.	<your repository link>
협업 분기	게시에 사용되는 GitHub 협업 분기입니다. 이 분기가 기본 분기입니다. 다른 분기에서 리소스를 게시하려는 경우 이 설정을 변경합니다. 여기에서 새 협업 분기를 만들 수도 있습니다.	<your collaboration branch>
분기 게시	게시 관련 ARM 템플릿이 저장되고 업데이트되는 리포지토리의 분기입니다.	<your publish branch name>
루트 폴더	GitHub 협업 분기의 루트 폴더입니다.	<your root folder name>
기존 리소스를 리포지토리로 가져오기	UX 제작 캔버스에서 기존 데이터 팩터리 리소스를 GitHub 리포지토리로 가져올지 여부를 지정합니다. JSON 형식의 연결된 Git 리포지토리로 데이터 팩터리 리소스를 가져오려면 상자를 선택합니다. 이 작업은 각 리소스를 개별적으로 내보냅니다(즉, 연결된 서비스 및 데이터 세트를 별도 JSON으로 내보냄). 이 상자를 선택하지 않으면 기존 리소스를 가져오지 않습니다.	선택됨(기본값)
이 분기로 리소스 가져오기	데이터 팩터리 리소스(파이프라인, 데이터 세트, 연결된 서비스 등)를 가져올 분기를 지정합니다.

리포지토리 설정 편집

구성된 GitHub 리포지토리의 설정을 조정해야 하는 경우 편집하도록 선택할 수 있습니다.

게시 분기를 업데이트하고 ADF 스튜디오에서 게시 단추를 사용하지 않도록 설정할지 여부를 결정할 수 있습니다. 스튜디오에서 게시 단추를 사용하지 않도록 선택하면 게시 단추가 스튜디오에서 회색으로 표시됩니다. 이렇게 하여 마지막 자동화된 게시 배포를 덮어쓰지 않도록 방지할 수 있습니다.

GitHub 조직

GitHub 조직에 연결하려면 조직이 Azure Data Factory에 권한을 부여해야 합니다. 조직에 대한 관리자 권한이 있는 사용자는 아래 단계를 수행하여 데이터 팩터리의 연결을 허용해야 합니다.

Azure Data Factory에서 처음으로 공용 GitHub 또는 GitHub Enterprise Cloud에 연결

Azure Data Factory에서 처음으로 공용 GitHub 또는 GitHub Enterprise Cloud에 연결하는 경우 다음 단계에 따라 GitHub 조직에 연결합니다.

1. Git 구성 창의 GitHub 계정 필드에 조직 이름을 입력합니다. GitHub에 로그인하라는 메시지가 나타납니다.
2. 사용자 자격 증명을 사용하여 로그인합니다.
3. AzureDataFactory라는 애플리케이션으로 Azure Data Factory에 권한을 부여하라는 메시지가 표시됩니다. 이 화면에는 ADF에서 조직에 액세스할 수 있는 권한을 부여하는 옵션이 표시됩니다. 권한을 부여하는 옵션이 표시되지 않으면 관리자에게 GitHub를 통해 권한을 수동으로 부여하도록 요청합니다.

이러한 단계를 수행하면 팩터리는 조직 내에서 퍼블릭 및 프라이빗 리포지토리에 연결할 수 있습니다. 연결할 수 없는 경우 브라우저 캐시를 지우고 다시 시도합니다.

개인 계정을 사용하여 공용 GitHub 또는 GitHub Enterprise Cloud에 이미 연결됨

이미 공용 GitHub 또는 GitHub Enterprise Cloud에 연결했고 개인 계정에 대한 액세스 권한만 부여한 경우 아래 단계에 따라 조직에 권한을 부여합니다.

1. GitHub로 이동하여 설정을 엽니다.

   

2. 애플리케이션을 선택합니다. 권한 있는 OAuth 앱 탭에는 AzureDataFactory가 표시됩니다.

   

3. 애플리케이션을 선택하고 조직에 대한 액세스 권한을 애플리케이션에 부여합니다.

   

이러한 단계를 수행하면 팩터리는 조직 내에서 퍼블릭 및 프라이빗 리포지토리에 연결할 수 있습니다.

GitHub Enterprise 서버에 연결

GitHub Enterprise 서버에 연결하는 경우 인증을 위해 개인용 액세스 토큰을 사용해야 합니다. 개인용 액세스 토큰 만들기에서 개인용 액세스 토큰을 만드는 방법에 대해 알아봅니다.

참고 항목

GitHub Enterprise 서버는 자체 호스팅 프라이빗 환경에 있으므로 이 인증을 사용할 때 방화벽, 네트워크 정책 및 VPN에 대한 모든 권한이 필요합니다. 자세한 내용은 GitHub Enterprise 서버 정보를 참조하세요.

알려진 GitHub 제한 사항

• GitHub 리포지토리에 스크립트 및 데이터 파일을 저장할 수 있습니다. 그러나 Azure Storage에 파일을 수동으로 업로드해야 합니다. Data Factory 파이프라인은 GitHub 리포지토리에 저장된 스크립트 또는 데이터 파일을 자동으로 Azure Storage에 업로드하지 않습니다.

• 버전 2.14.0 이상의 GitHub Enterprise는 Microsoft Edge 브라우저에서 작동하지 않습니다.

• Data Factory 시각적 제작 도구와 GitHub 통합은 일반적으로 사용 가능한 Data Factory 버전에서만 작동합니다.

Azure DevOps Server 2022에 연결

Azure DevOps Server 2022에 연결하는 경우 인증에 개인 액세스 토큰을 사용해야 합니다. 여기에서 개인용 액세스 토큰을 만드는 방법을 알아봅니다.

Azure DevOps Server URL 및 Azure DevOps Project Collection을 제공하여 온-프레미스 Azure DevOps에 연결합니다.

코드에 대한 읽기/쓰기 권한으로 액세스 범위가 있는 토큰을 제공합니다.

버전 제어

원본 제어라고도 하는 버전 제어 시스템을 통해 개발자는 코드에 대해 공동 작업을 수행하고, 코드 베이스의 변경 내용을 추적할 수 있습니다. 소스 제어는 개발자가 여러 명인 프로젝트에 반드시 필요한 도구입니다.

기능 분기 만들기

데이터 팩터리와 연결된 각 Azure Repos Git 리포지토리에는 협업 분기가 생성됩니다. (main는 기본 협업 분기입니다). 분기 드롭다운에서 + 새 분기를 클릭하여 기능 분기를 만들 수도 있습니다.

새 분기 창이 표시되면 기능 분기의 이름을 입력하고 작업의 기반이 되는 분기를 선택합니다.

기능 분기의 변경 내용을 협업 분기에 병합할 준비가 되면, 분기 드롭다운을 클릭하고 끌어오기 요청 만들기를 선택합니다. 이 작업을 통해 끌어오기 요청을 수행하고, 코드 검토를 수행하고, 협업 분기에 변경 내용을 병합할 수 있는 Azure Repos Git로 이동합니다. (기본값은 main입니다.) 협업 분기에서 Data Factory 서비스에 게시할 수만 있습니다.

게시 설정 구성

기본적으로 데이터 팩터리는 게시된 팩터리의 Resource Manager 템플릿을 생성하여 adf_publish라는 분기에 저장합니다. 사용자 지정 게시 분기를 구성하려면 협업 분기의 루트 폴더에 publish_config.json 파일을 추가합니다. 게시하면 ADF는 이 파일을 읽고 publishBranch 필드를 찾아서 모든 Resource Manager 템플릿을 지정된 위치에 저장합니다. 분기가 없으면 데이터 팩터리가 자동으로 만듭니다. 이 파일의 모양은 다음과 같습니다.

{
    "publishBranch": "factory/adf_publish"
}

Azure Data Factory는 게시 분기를 한 번에 하나만 포함할 수 있습니다. 새 게시 분기를 지정할 때 Data Factory는 이전 게시 분기를 삭제하지 않습니다. 이전 게시 분기를 제거하려는 경우에는 수동으로 해당 분기를 삭제합니다.

참고

Data Factory는 팩터리를 로드할 때만 publish_config.json 파일을 읽습니다. 포털에 팩터리가 이미 로드되어 있으면 브라우저를 새로 고쳐서 변경 내용을 적용합니다.

코드 변경 내용 게시

협업 분기에 변경 내용을 병합한 후에(기본값은 main) 게시를 클릭하여 기본 분기의 코드 변경 내용을 Data Factory 서비스에 수동으로 게시합니다.

사이드 창이 열리면 게시 분기 및 보류 중인 변경 사항이 올바른지 확인합니다. 변경 내용을 확인한 후 확인을 클릭하여 게시를 확인합니다.

Important

기본 분기는 Data Factory 서비스에 배포된 내용을 반영하지 않습니다. 따라서 기본 분기를 반드시 Data Factory 서비스에 수동으로 게시해야 합니다.

Git 통합에 대한 모범 사례

사용 권한

일반적으로 Data Factory를 업데이트할 권한이 모든 팀 멤버에게 필요하지는 않습니다. 다음과 같은 권한 설정을 사용하는 것이 좋습니다.

• 모든 팀 멤버는 Data Factory에 대한 읽기 권한이 있어야 합니다.
• 선택된 사용자 세트만 Data Factory에 게시할 수 있어야 합니다. 이렇게 하려면 해당 사용자에게 Data Factory를 포함하는 리소스 그룹에 대한 Data Factory 기여자 역할이 있어야 합니다. 권한에 대한 자세한 내용은 Azure Data Factory의 역할 및 권한을 참조하세요.

협업 분기에 대한 직접 체크 인은 허용하지 않는 것이 좋습니다. 이렇게 제한하면 기능 분기 만들기의 설명대로 모든 체크 인이 끌어오기 요청 검토 프로세스를 거치기 때문에 버그를 방지하는 데 유용할 수 있습니다

Azure Key Vault의 암호 사용

Azure Key Vault를 사용하여 Data Factory 연결된 서비스에 대한 연결 문자열이나 암호 또는 관리 ID 인증을 저장하는 것이 좋습니다. 보안상의 이유로 데이터 팩터리는 Git에 비밀을 저장하지 않습니다. 암호와 같은 비밀을 포함하는 연결된 서비스에 대한 변경 내용은 Azure Data Factory 서비스에 즉시 게시됩니다.

Key Vault 또는 MSI 인증을 사용해도 연속 통합과 배포가 쉬워집니다. Resource Manager 템플릿 배포 중에 비밀을 제공할 필요가 없기 때문입니다.

Git 통합 문제 해결

부실한 게시 분기

다음은 부실한 게시 분기를 유발할 수 있는 상황의 몇 가지 예입니다.

• 사용자에게 분기가 여러 개 있습니다. 하나의 기능 분기에서 AKV와 관련이 없는 연결된 서비스를 삭제한 후(AKV 이외의 연결된 서비스는 Git에 있는지 여부에 관계없이 즉시 게시됨) 기능 분기를 협업 분기에 병합하지 않았습니다.
• 사용자가 SDK 또는 PowerShell을 사용하여 데이터 팩터리를 수정했습니다.
• 사용자가 모든 리소스를 새 분기로 이동기고 처음으로 게시하려고 했습니다. 연결된 서비스는 리소스를 가져올 때 수동으로 만들어야 합니다.
• 사용자가 AKV 이외의 연결된 서비스 또는 Integration Runtime JSON을 수동으로 업로드합니다. 데이터 세트, 연결된 서비스 또는 파이프라인과 같은 다른 리소스에서 해당 리소스를 참조합니다. 사용자 인터페이스를 통해 만든 AKV 이외의 연결된 서비스는 자격 증명을 암호화해야 하기 때문에 즉시 게시됩니다. 연결된 서비스를 참조하는 데이터 세트를 업로드하고 게시를 시도하는 경우 사용자 인터페이스는 git 환경에 존재하기 때문에 이를 허용합니다. 하지만 데이터 팩터리 서비스에 존재하지 않기 때문에 게시할 때 거부됩니다.

게시 분기가 기본 분기와 동기화되지 않고 최근 게시에도 불구하고 오래된 리소스가 포함된 경우 아래 솔루션 중 하나를 사용할 수 있습니다.

옵션 1: 라이브 모드 덮어쓰기 기능 사용

협업 분기의 코드를 라이브 모드로 게시하거나 덮어씁습니다. 리포지토리의 코드를 진리의 소스로 간주합니다.

코드 흐름: 협업 분기 -> 라이브 모드

옵션 2: Git 리포지토리 연결 끊기 및 다시 연결

라이브 모드에서 협업 분기로 코드를 가져옵니다. 라이브 모드의 코드를 진리의 소스로 간주합니다.

코드 흐름: 라이브 모드 -> 협업 분기

1. 현재 Git 리포지토리 제거
2. 동일한 설정으로 Git을 재구성하되 기존 Data Factory 리소스를 리포지토리로 가져오기가 선택되어 있는지 확인하고 협업 분기(동일 분기)를 선택합니다.
3. 변경 내용을 협업 분기에 병합하는 끌어오기 요청을 만듭니다.

참고 항목

직접 커밋을 허용하지 않는 리포지토리에서 작업하는 경우에만 끌어오기 요청을 만들고 병합해야 합니다. 대부분의 조직에서 리포지토리에 제출하려면 병합하기 전에 검토가 필요하므로 일반적으로 이 방법을 사용하는 것이 가장 좋습니다. 그러나 경우에 따라 검토가 필요하지 않습니다. 이 경우 끌어오기 요청을 만들고 병합할 필요는 없지만 변경 내용을 협업 분기에 직접 커밋할 수 있습니다.

필요에 따라 적절한 방법을 선택합니다.

게시 시 새 것으로 표시되는 모든 리소스

게시하는 동안 모든 리소스는 이전에 게시된 경우에도 새 것으로 표시될 수 있습니다. 이 문제는 팩터리 ARM 템플릿을 다시 배포하거나 PowerShell 또는 REST API를 통해 팩터리 repoConfiguration 속성을 업데이트하여 팩터리의 repoConfiguration속성에서 lastCommitId 속성이 다시 설정되는 경우에 발생할 수 있습니다. 리소스를 계속 게시하면 문제가 해결되지만 다시 발생하지 않도록 하려면 팩터리 repoConfiguration 속성을 업데이트하지 마세요.

다른 Git 리포지토리로 전환

다른 Git 리포지토리로 전환하려면 소스 제어의 관리 허브에서 Git 구성 페이지로 이동합니다. 연결 끊기를 선택합니다.

데이터 팩터리 이름을 입력하고 확인을 클릭하여 데이터 팩터리와 연결된 Git 리포지토리를 제거합니다.

현재 리포지토리와 연결을 제거한 후에 다른 리포지토리를 사용하도록 Git 설정을 구성한 다음, 기존 Data Factory 리소스를 새 리포지토리로 가져올 수 있습니다.

중요

데이터 팩터리에서 Git 구성을 제거해도 리포지토리에서 아무것도 삭제되지 않습니다. 팩터리에는 게시된 모든 리소스가 포함됩니다. 서비스에 대해 직접 팩터리를 계속 편집할 수 있습니다.

관련 콘텐츠

• 파이프라인 모니터링 및 관리에 대한 자세한 내용은 프로그래밍 방식으로 파이프라인 모니터링 및 관리를 참조하세요.
• 연속 통합 및 배포를 구현하려면 Azure Data Factory의 CI/CD(연속 통합 및 지속적인 업데이트)를 참조하세요.