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

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

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

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

Приступая к работе

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

  Пользователь должен иметь следующие области:

  • repo

  • read:org

  • read:user

  • read:project

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

• Необходимо создать персональный токен доступа 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. В разделе Проекты щелкните ... рядом с проектом и выберите Создать новую ветку.

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

2. Выберите, чтобы создать ответвление от основной ветки.

3. Введите имя для ветки.

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

5. Щелкните Создать.

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

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

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

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

   Если изменения найдены, отображается диалоговое окно Применить удаленные изменения к рабочей области.

2. Теперь можно выбрать, к каким задачам применить изменения, и проверить изменения. Для каждого изменения можно выбрать, какую версию использовать: удаленную или версию в рабочей области.

3. Щелкните Применить удаленные изменения

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

Фиксация и отправка

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

1. В разделе Проекты щелкните ... рядом с проектом и выберите Зафиксировать и отправить.

   Если найдены изменения, отображается диалоговое окно Зафиксировать и отправить.

2. Добавьте сообщение о фиксации, которое поможет отслеживать, что изменено.

3. Щелкните Зафиксировать и отправить

Удаление ветки

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

1. В разделе Проекты щелкните ... рядом с веткой, которую нужно удалить, и выберите Удалить ветку.

   По желанию также можно удалить ветку в контроле версий.

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

Удаление контроля версий для проекта

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

1. В разделе Проекты щелкните ... рядом с проектом, который нужно отключить, и выберите Отключить от GitHub.

Совместное использование проекта в разных пространствах или клиентах

Можно использовать одну и ту же версию проекта в разных пространствах одного клиента или в разных клиентах. Это удобно, когда требуется создать две среды, например, одну для разработки, а другую для производства.

1. Создайте новый проект с тем же именем, что и у исходного проекта.

   Настройте такой же сценарий использования и тип платформы. Можно использовать разные подключения.

2. Подключите новый проект к тем же репозиторию и базовому каталогу, что и исходный проект.

   Примечание к информацииНе устанавливайте флажок Зафиксировать и отправить.

3. Если подключение платформы указывает на ту же цель, что исходный проект, убедитесь, что изменена база данных или схемы задач данных. Один из способов изменить схемы всех задач ― это изменить значение параметра Префикс для всех схем в настройках проекта Метаданные перед применением удаленных изменений. Это гарантирует, что все задания будут создаваться с указанным префиксом.

4. Примените удаленные изменения, выбрав все файлы.

5. Добавьте недостающие подключения к источнику для всех задач промежуточного хранения.

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

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

6. Добавьте недостающие подключения к источнику и цели для всех задач репликации.

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

Требования к обеспечению безопасности

Необходимо обеспечивать синхронизацию конфигураций безопасности между Qlik Talend Data Integration и GitHub.

• В Qlik Talend Data Integration разрешения основаны на пространствах, которые могут содержать несколько проектов. В GitHub разрешения основаны на репозиториях, которые также могут содержать несколько проектов. Рекомендуется привести их к взаимному соответствию и подключить все проекты в одном пространстве к одному репозиторию.

• Имейте в виду, что Qlik Talend Data Integration и GitHub используют разные разрешения и роли для пользователей.

Оптимальные методы работы

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

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

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

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

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

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

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

Ограничения

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

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

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

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

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

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

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

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