Контроль версий с использованием файлов решения

Инструмент "Упаковщик решений" можно использовать с любой системой управления версиями. После того как ZIP-файл решения будет извлечен в папку, добавьте и отправьте файлы в систему управления версиями. Затем эти файлы можно синхронизировать на другом компьютере, где они могут быть упакованы в новый идентичный ZIP-файл решения.

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

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

Important

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

Когда средство "Упаковщик решений" извлекает файлы компонентов, оно не будет перезаписывать существующие файлы компонентов с одинаковыми именами, если содержимое файлов идентично. Кроме того, инструмент учитывает атрибут "только для чтения" в файлах компонентов, создавая в окне консоли предупреждение о том, что определенные файлы не были записаны. Эта защита позволяет пользователю извлекать из системы управления версиями минимальный набор файлов, которые меняются. Параметр /clobber может использоваться для принудительного переопределения прав и записи или удаления файлов, доступных только для чтения. Параметр /allowWrite может использоваться для оценки того, какое влияние оказывает операция извлечения, фактически не вызывая запись или удаление каких-либо файлов. Использование параметра /allowWrite с подробным ведением журнала эффективно.

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

Форматы файлов системы управления версиями

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

ФОРМАТ XML (устаревшая версия) Формат контроля версий YAML
Манифест решения Other\Solution.xml + Other\Customizations.xml solutions/<name>/solution.yml и поддержка файлов YAML
Читаемость Объёмный XML Компактный YAML — проще читать и просматривать
Качество диффа в Git Большие диффы XML Минимальные, сфокусированные различия
Репозиторий с несколькими решениями Не поддерживаются Поддерживается— несколько решений совместно используют одну папку
Canvas Apps (.msapp) Не поддерживаются Поддерживается
Современные потоки Не поддерживаются Поддерживается
Нативная интеграция с Git Не используется Всегда используется— интеграция Git всегда записывает YAML

Когда используется формат YAML: Для всех новых проектов и при использовании собственной интеграции Dataverse Git. Формат YAML обладает обратной совместимостью с будущими изменениями и создает более чистый журнал изменений.

Когда используется xml-формат: Только при работе с существующими репозиториями, которые уже используют формат XML или при использовании устаревших средств, которые не поддерживают YAML.

Замечание

При совершении коммита решений с помощью встроенной интеграции Git в Power Apps они всегда хранятся в формате YAML для управления версиями. Чтобы вручную упаковать или распаковывать этот источник с помощью SolutionPackager или pac solution packпапка должна соответствовать структуре папок YAML. Дополнительные сведения: инструмент SolutionPackager — форматы файлов для системы управления версиями

Коллективная разработка

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

  1. Разработчики A и B оба работают над одним и тем же решением.

  2. На независимых компьютерах они получают последние версии исходных файлов решения из системы управления версиями, собирают пакет и импортируют неуправляемое решение в виде файла .zip в независимые организации Microsoft Dataverse.

  3. Разработчик A настраивает системное представление "Активные контакты" и основную форму для сущности Contact.

  4. Разработчик B настраивает основную форму для сущности "Счет" и изменяет "Представление поиска контакта".

  5. Оба разработчика экспортируют ZIP-файл неуправляемого решения и извлекают его.

    1. Разработчику A потребуется взять в работу один файл для основной формы "Контакт" и один файл для представления "Активные контакты".

    2. Разработчику B необходимо получить один файл для основной формы "Счёт" и один файл для "поискового представления контактов".

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

  7. После завершения обеих отправок они могут повторить шаг № 2, затем продолжить вносить дальнейшие изменения в свои независимые организации. У каждого из них есть оба набора изменений, без перезаписи их собственной работы.

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

  1. Разработчики A и B оба работают над одним и тем же решением.

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

  3. Разработчик A настраивает системное представление "Активные контакты" и основную форму таблицы Контактов.

  4. Разработчик B настраивает основную форму для таблицы "Контрагенты" и изменяет представление "Активные контакты".

  5. Оба разработчика экспортируют ZIP-файл неуправляемого решения и извлекают его.

    1. Разработчику A потребуется взять в работу один файл для основной формы "Контакт" и один файл для представления "Активные контакты".

    2. Разработчик B должен извлечь один файл для основной формы учетной записи и один файл для представления "Активные контакты".

  6. Разработчик А готов первым.

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

    2. Там нет никаких конфликтов, поэтому разработчик А может отправлять.

  7. Разработчик B готов следующим после разработчика А.

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

    2. Существует конфликт, так как файл для «Активные контакты» был изменен после того, как разработчик B в последний раз получил последние версии источников.

    3. Разработчик B должен урегулировать конфликт. Возможно, что возможности используемой системы управления версиями могут помочь этому процессу; в противном случае все следующие варианты являются возможными.

      1. Разработчик B через журнал системы управления версиями, если таковой имеется, может видеть, что разработчик A внес предыдущее изменение. Через прямое общение они могут обсудить каждое изменение. Затем разработчику B нужно всего лишь обновить организацию с согласованным решением. Затем разработчик B экспортирует, извлекает и перезаписывает конфликтующий файл и отправляет.

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

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

Независимо от того, выполняется ли работа в общей среде или в независимых средах, разработка рабочей группой решений в Dataverse требуют, чтобы те, кто активно работает над общим решением, были осведомлены о работе других. Инструмент "Упаковщик решений" не полностью устраняет эту необходимость, но позволяет легко объединять неконфликтующие изменения на уровне системы управления версиями и проактивно выделяет краткие компоненты, в которых возникли конфликты.

Следующие разделы представляют собой общие процессы для эффективного использования инструмента "Упаковщик решений" в системе управления версиями при разработке с рабочими группами. Они работают в равной степени с независимыми средами или совместно используемыми средами разработки, хотя в совместно используемых средах экспорт и извлечение, естественно, будут включать все изменения, присутствующие в решении, а не только изменения, сделанные разработчиком, выполняющим экспорт. Аналогично, при импорте ZIP-файла решения возникает естественное поведение для перезаписи всех компонентов.

Создание решения

Эта процедура идентифицирует типичные шаги, используемые при первом создании решения.

  1. В чистой среде с Dataverse создайте решение, а затем добавьте или создайте компоненты по мере необходимости.

  2. Когда вы будете готовы зарегистрироваться, сделайте следующее.

    1. Экспортируйте неуправляемое решение.

    2. С помощью инструмента "Упаковщик решений" извлеките решение в файлы компонентов.

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

    4. Отправьте эти изменения в систему контроля версий.

Изменение решения

Следующая процедура идентифицирует типичные шаги, используемые при изменении существующего решения.

  1. Синхронизируйте или получите новейшие исходные файлы компонентов решения.

  2. С помощью инструмента "Упаковщик решений" упакуйте файлы компонентов в ZIP-файл неуправляемого решения.

  3. Импортируйте файл неуправляемого решения в среду.

  4. Настройте и отредактируйте решение по мере необходимости.

  5. Когда вы будете готовы зафиксировать изменения в системе контроля версий, сделайте следующее.

    1. Экспортируйте неуправляемое решение.

    2. С помощью инструмента "Упаковщик решений" извлеките экспортированное решение в файлы компонентов.

    3. Синхронизируйте или получите последние исходные файлы из системы контроля версий.

    4. Согласуйте, если какие-либо конфликты существуют.

    5. Отправьте изменения в систему контроля версий.

    Шаги 2 и 3 должны быть выполнены до того, как в организации разработки будут выполнены дальнейшие настройки. На шаге 5 шаг b должен быть завершен до шага c.

См. также

Справочник по файлам компонентов решения (SolutionPackager)
Средство SolutionPackager
Форматы файлов системы контроля версий

  • Last updated on