Управление версиями файлов решения

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

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