Управление проектами конвейеров с помощью контроля версий

Вы можете использовать контроль версий для управления разработкой проекта конвейера и отслеживания изменений.

При работе с контролем версий вы можете фиксировать версии проектов во время проектирования. Это позволяет видеть изменения между двумя версиями проекта. Вы также можете разрабатывать свои проекты данных, используя стратегию ветвления. Это позволяет работать над изолированной версией проекта в каждой рабочей области или ветке. Рабочая область может быть доступна нескольким пользователям. Затем вы можете объединить свои изменения из рабочей области в главную ветку для развертывания в рабочей среде.

GitHub используется в качестве поставщика для контроля версий. Реализация следует модели общего репозитория.

• GitHub Enterprise Cloud и GitHub Enterprise Server не поддерживаются.

• Для получения дополнительной информации о модели общего репозитория см. О моделях совместной разработки.

• Для получения дополнительной информации о Git и GitHub см. О GitHub и Git.

• Соображения безопасности GitHub

  Qlik Talend Cloud поддерживает протокол безопасности HTTPS и личные токены доступа (PAT), что является режимом аутентификации по умолчанию для GitHub. Для получения дополнительной информации см. Об аутентификации в 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. Нажмите Создать

Новая ветка создается из главной и извлекается из репозитория. Ветка содержит новую версию проекта со всеми задачами в статусе «Новая». То есть они не подготовлены и не содержат никаких данных.

Применение удаленных изменений

Вы можете применить изменения из удаленного репозитория в свою рабочую область. Это могут быть изменения, созданные вне интегрированного контроля версий Qlik Cloud, например, в GitHub или с помощью других инструментов. Это помогает избежать конфликтов, когда вы хотите зафиксировать и отправить свои изменения в ветку.

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 используют разные разрешения и роли для пользователей.

Лучшие практики

Вот некоторые общие лучшие практики при работе с проектами с использованием контроля версий.

• Добавьте файл README, который описывает репозиторий в GitHub. Для получения дополнительной информации см. О файлах README.

  Если вы начинаете с пустого репозитория, контроль версий Qlik Talend Cloud автоматически добавит пустой файл README.md.

• В целом вам следует позволить контролю версий Qlik Talend Cloud управлять репозиторием GitHub.

• Фиксируйте только те проекты, которые действительны и протестированы на выполнение.

  Если вы добавляете проекты с задачами посадки или зарегистрированных данных, которые не были подготовлены или преобразованы, исходные столбцы еще не включены. Исходные столбцы добавляются при подготовке и преобразовании задачи.

• Когда вы создаете ветку для проектов репликации, вы должны знать, что ветки по умолчанию используют одну и ту же цель. Это означает, что выполнение задач в ветке может перезаписать данные главной версии. Чтобы избежать потери данных, измените целевые настройки в ветке, чтобы они не конфликтовали с главной версией.

• Когда вы создаете ветку, могут быть удаленные изменения, которые еще не применены к рабочей области. Примените удаленные изменения до или после создания ветки, если только вы не хотите отменить удаленные изменения.

• Внесение изменений в один и тот же набор данных в двух разных ветках может привести к конфликтам слияния, которые трудно разрешить, и к повторному созданию набора данных.

  Примечание к информацииКогда набор данных добавляется к задаче, он получает внутренний идентификатор. Внутренние идентификаторы используются для обеспечения беспрепятственного переименования и других операций с метаданными в конвейере. При создании того же набора данных в отдельном проекте или ветке внутренний идентификатор будет другим, что может вызвать конфликт при объединении двух веток. Это может привести к тому, что процесс подготовки удалит и заново создаст набор данных, даже если он имеет то же имя.

Работа в ветках

Вы можете создать проект, спроектировать его и, когда он будет готов, развернуть его в рабочей среде, используя ветку MAIN. Версия в MAIN соответствует вашему рабочему конвейеру. Вы никогда не должны редактировать ветку MAIN напрямую после первого развертывания.

Каждый раз, когда разработчик хочет внести новое изменение в проект, например, добавить функциональность или исправить ошибку, необходимо создать новую ветку.

Разработчики могут создавать любое количество веток для своих нужд разработки

• Используйте префиксы схем для веток, чтобы избежать конфликтов баз данных при внесении изменений.

• В ветке разработчики могут вносить любое количество изменений, а также фиксировать и отправлять их столько раз, сколько необходимо. Рекомендуется изолировать каждое изменение в автономной отдельной фиксации. Например, если вы вносите изменение в задачу преобразования, которое также влияет на витрину данных, обязательно включите оба изменения в одну фиксацию

• Все члены команды должны использовать Применить удаленные изменения в любое время, чтобы убедиться, что их MAIN обновлена, особенно перед фиксацией своих изменений.

Когда разработчики закончат работу в своей ветке, они могут создать запрос на включение для экспертной оценки.

После проверки и утверждения другими членами команды вы можете объединить запрос на включение с версией MAIN в GitHub .

Наконец, используйте Применить удаленные изменения в проекте, чтобы перенести утвержденные изменения ветки обратно в ветку MAIN (рабочая среда).

Работа в пространствах

Для более крупных и критически важных развертываний рекомендуется использовать выделенные пространства для разработки и рабочей среды, чтобы изолировать изменения и обеспечить целостность конвейера. Используйте выделенные подключения к данным для источников и цели в каждом пространстве.

• Рабочая среда

  Ветка MAIN отражает то, что находится в рабочей среде. Это означает, что существует только одна версия MAIN проекта.

  Рабочая среда изолирована в выделенном пространстве данных, например, PROD. Выделенные подключения назначаются рабочему пространству.

  Никакие изменения не вносятся непосредственно в рабочее пространство/ветку MAIN. Все изменения вносятся в других пространствах с выделенными подключениями с использованием веток.

  Вы можете повторно использовать версию MAIN существующего проекта в GitHub. Создайте пустой проект с тем же именем, что и существующий проект в GitHub. Это извлекает последнюю доступную версию в ветке MAIN для начала редактирования.

  Пользователи создают новую ветку, вносят свои изменения, создают запросы на включение, объединяют и переносят обратно в MAIN/Рабочую среду.

• Разработка

  Разработчики могут изолировать свои изменения в выделенном пространстве данных, например, DEV. Выделенные подключения назначаются пространству DEV.

  Изменения изолируются с помощью веток, обычно по одной ветке на разработчика. Используйте префиксы схем при создании ветки, чтобы избежать конфликтов баз данных при внесении изменений.

• Проверка / приемка качества

  Рецензентам предоставляется доступ к пространствам разработки и подключениям для:.

  • Открытия и тестирования веток проекта в Qlik Talend Cloud.

  • Утверждения запросов на включение для продолжения объединения в GitHub.

  • Информирования членов команды о том, когда утвержденные изменения могут быть перенесены обратно в MAIN/Рабочую среду.

При развертывании утвержденных изменений обратно в пространство MAIN/Рабочей среды вы должны переназначить подключения на подключения рабочего пространства.

Ограничения

• Контроль версий не поддерживается для проектов с Qlik Cloud (QVD) в качестве цели.

• Невозможно отключить или удалить проект, использующий контроль версий, если есть ветки. Ветки должны быть удалены, прежде чем вы сможете отключить или удалить проект.

• Невозможно переименовать проект, использующий контроль версий.

• Когда вы удаляете клиента, объекты, сохраненные с помощью контроля версий в GitHub, не будут удалены. Вам нужно удалить эти объекты вручную.

• Если репозиторий используется многими проектами или содержит много файлов, которые не хранятся в Qlik Talend Data Integration, производительность может снизиться.

• Схемы баз данных и подключения не поддерживаются в контроле версий.

• Детализированные личные токены доступа GitHub не поддерживаются.

• Ветка (кроме главной ветки) может использоваться только одним проектом на репозиторий, даже если два проекта находятся в одном репозитории.

• Невозможно применить удаленные изменения из проекта, который использует другую целевую платформу. Например, если вы фиксируете изменения в проекте на Snowflake, вы не можете применить изменения к проекту Databricks.