Бележка
Достъпът до тази страница изисква удостоверяване. Можете да опитате да влезете или да промените директориите.
Достъпът до тази страница изисква удостоверяване. Можете да опитате да промените директориите.
Инструментът Solution Packager може да се използва с всяка система за контрол на източника. След като решение .zip файл бъде извлечен в папка, добавете и изпратете файловете във вашата система за контрол на източниците. След това тези файлове могат да бъдат синхронизирани на друг компютър, където могат да бъдат опаковани в ново идентично .zip файл с решение.
Важен аспект при използването на извлечени файлове на компоненти в контрола на източника е, че добавянето на всички файлове в контрола на източника може да доведе до ненужно дублиране. Отидете в справката за файл на компонент на решение, за да откриете кои файлове се генерират за всеки тип компонент и кои файлове се препоръчват за използване в контрола на източника.
Тъй като са необходими допълнителни персонализиране и промени за решението, разработчиците трябва да редактират или персонализират компоненти чрез съществуващите средства, да експортират отново, за да създадат .zip файл, и да извлекат компресирания файл с решение в същата папка.
Важно
С изключение на разделите, описани в Кога да редактирате файла за персонализации, ръчното редактиране на извлечените файлове на компоненти и файловете .zip не се поддържа.
Когато инструментът Solution Packager извлича файловете на компонентите, той не презаписва съществуващите файлове на компоненти със същото име, ако съдържанието на файла е идентично. В допълнение, инструментът зачита атрибута само за четене на файловете на компонентите, създавайки предупреждение в прозореца на конзолата, че определени файлове не са написани. Тази защита позволява на потребителя да извади от контрола на източника минималния набор от файлове, които се променят. Параметърът /clobber може да се използва за отмяна и предизвикване на писане или изтриване на файлове само за четене. Параметърът /allowWrite може да се използва за оценка на въздействието на дадена операция за извличане, без всъщност да води до записване или изтриване на файлове. Използване на параметър /allowWrite с многословно регистриране е ефективно.
След като операцията за извличане приключи с минималния набор от файлове, извлечени от контрола на източника, разработчикът може да изпрати променените файлове обратно в контрола на източника, както се прави с всеки друг тип изходен файл.
Формати на файлове за контрол на изходния код
Инструментът Solution Packager поддържа два файлови формата за извлечени компонентни файлове. Изборът на правилния формат предварително избягва необходимостта да мигрирате структурата на хранилището по-късно.
| XML формат (наследство) | YAML формат за контрол на изходния код | |
|---|---|---|
| Манифест на решение | Other\Solution.xml + Other\Customizations.xml |
solutions/<name>/solution.yml и поддържащи YAML файлове |
| Четимост | Verbose XML | Компактен YAML — по-лесен за четене и преглед |
| Диференциално качество в Git | Големи XML диференции | Минимални, фокусирани разлики |
| Мулти-решение репо | Не се поддържа | Поддържано — няколко решения споделят една папка |
| Canvas приложения (.msapp) | Не се поддържа | Поддържани |
| Съвременни потоци | Не се поддържа | Поддържани |
| Нативна интеграция с Git | Не се използва | Винаги използвано — Git интеграцията винаги записва YAML |
Кога да използвате YAML формата: За всички нови проекти и когато използвате нативна интеграция с Dataverse Git. YAML форматът е съвместим с напред и осигурява по-чиста история на промените.
Кога да използвате XML формата: Само когато работиш с съществуващи хранилища, които вече използват XML формат, или когато използваш наследени инструменти, които не поддържат YAML.
Бележка
Когато комитирате решения, използващи нативната Git интеграция в Power Apps, те винаги се съхраняват във формата YAML source control. За ръчно опаковане или разопаковане на този източник с SolutionPackager или pac solution pack, папката трябва да следва структурата на YAML папката. Повече информация: SolutionPackager tool — Формати за файлови файлове за контрол на изходния код
Разработване на екип
Когато има няколко разработчици, работещи върху един и същ компонент на решението, може да възникне конфликт, когато промените от двама разработчици водят до промени в един файл. Това събитие е сведено до минимум чрез декомпозиране на всеки отделно редактируем компонент или подкомпонент в отделен файл. Обмислете следния пример.
Разработчиците A и B работят едновременно върху едно и също решение.
На независимите компютри и двете получават най-новите източници на решението от контрол на източниците, опаковат и импортират неуправлявано решение .zip файл в независими Microsoft Dataverse организации.
Разработчик А персонализира изгледа на системата "Активни контакти" и основната форма за обекта Контакт.
Разработчик Б персонализира основния формуляр за обекта "Акаунт" и променя "Изглед за търсене на контакти".
И двамата разработчици експортират неуправляемо решение .zip файл и екстракт.
Разработчик А трябва да провери един файл за основната форма Контакт и един файл за изгледа "Активни контакти".
Разработчик Б ще трябва да извади един файл за основния формуляр на акаунта и един файл за "Изглед за търсене на контакти".
И двамата разработчици могат да изпратят в произволен ред, тъй като съответните им промени засягат отделни файлове.
След като и двете предложения са завършени, те могат да повторят стъпка №2 и след това да продължат да правят допълнителни промени в своите независими организации. Всяка от тях има и двете групи промени, без презапис на собствената си работа.
Предишният пример работи само когато има промени в отделни файлове. Неизбежно е независимите персонализации да изискват промени в рамките на един файл. Въз основа на показания по-рано пример, имайте предвид, че разработчик Б е персонализирал изгледа "Активни контакти", докато разработчик А също го персонализираше. В този нов пример редът на събитията става важен. Правилният процес за помиряване на това затруднение, описан изцяло, е описан тук.
Разработчиците A и B работят едновременно върху едно и също решение.
На независимите компютри и двамата получават най-новите източници на решението от управление на източника, пакетират и импортират .zip файл с неуправлявано решение в независими организации.
Разработчик А персонализира изгледа на системата "Активни контакти" и основната форма за таблицата Контакти.
Разработчик Б персонализира основния формуляр за таблицата "Акаунт" и променя "Активни контакти".
И двамата разработчици експортират неуправляемо решение .zip файл и екстракт.
Разработчик А трябва да провери един файл за основната форма Контакт и един файл за изгледа "Активни контакти".
Разработчик Б трябва да провери един файл за основната форма на акаунта и един за изгледа "Активни контакти".
Програмист А е готов първи.
Преди разработчикът А да изпрати в контрола на източника, той трябва да получи най-новите източници, за да се увери, че предварителните проверки не са в конфликт с промените му.
Няма конфликти, така че разработчикът А може да изпрати.
Програмист Б е готов след разработчик А.
Преди разработчик Б да изпрати, той трябва да получи най-новите източници, за да се увери, че предварителните проверки не са в конфликт с промените му.
Има конфликт, защото файлът за "Активни контакти" е бил модифициран, откакто разработчик Б последно е възстановил последните източници.
Програмист Б трябва да разреши конфликта. Възможно е възможностите на използваната система за контрол на източника да подпомогнат този процес; в противен случай следните избори са жизнеспособни.
Програмист Б, чрез хронологията на контрола на източника, ако е налична, може да забележи, че разработчикът А е направил предишната промяна. Чрез пряка комуникация те могат да обсъждат всяка промяна. Тогава разработчик Б трябва само да актуализира организацията с договорената резолюция. След това разработчик Б експортира, извлича и презаписва конфликтния файл и изпраща.
Позволете на контрола на източника да презаписва локалния файл. Разработчик Б опакова решението и го импортира в своята организация, след което оценява състоянието на изгледа и го персонализира отново, ако е необходимо. След това разработчик Б може да експортира, извлече и презапише конфликтния файл.
Ако предишната промяна се счита за ненужна, разработчик Б позволява на своето копие на файла да презапише версията в контрола на източника и да изпрати.
Независимо дали работите в споделена среда или в независима среда, екипното разработване на Dataverse решения изисква тези, които активно работят върху общо решение, да са наясно с работата на другите. Инструментът Solution Packager не премахва напълно тази нужда, но позволява лесно обединяване на неконфликтни промени на ниво контрол на източника и проактивно подчертава кратките компоненти, където възникват конфликти.
Следващите раздели са общите процеси за ефективно използване на инструмента Solution Packager в контрола на източника при разработване с екипи. Те работят еднакво с независими среди или споделени среди за разработка, въпреки че при споделени среди експортирането и извличането естествено включват всички промени, присъстващи в решението, а не само тези, направени от разработчика, извършващ експорта. По същия начин, когато импортирате файл .zip решение се получава естественото поведение за презаписване на всички компоненти.
Създаване на решение
Тази процедура идентифицира типичните стъпки, използвани при първото създаване на решение.
В чиста среда с Dataverse създайте решение и след това добавете или създайте компоненти, ако е необходимо.
Когато сте готови да се регистрирате, изпълнете следните стъпки.
Експортиране на неуправлявано решение.
С помощта на инструмента Solution Packager извлечете решението във файлове на компоненти.
От тези извлечени компоненти на файлове добавете необходимите файлове към контрола на източника.
Изпратете тези промени в контрола на източника.
Промяна на решение
Следващата процедура идентифицира типичните стъпки, използвани при промяна на съществуващо решение.
Синхронизирайте или вземете най-новите източници на файлове на компонент на решение.
С помощта на инструмента Solution Packager опаковайте файловете на компонентите в незавършен файл .zip решение.
Импортирайте файла с незавършено решение в среда.
Персонализирайте и редактирайте решението, ако е необходимо.
Когато сте готови да проверите промените в контрола на източника, изпълнете следните стъпки.
Експортиране на неуправлявано решение.
С помощта на инструмента Solution Packager извлечете експортираното решение във файлове на компоненти.
Синхронизирайте или вземете най-новите източници от контрола на източниците.
Разрешете, ако има някакви конфликти.
Подайте промените в изходната контрола.
Стъпки 2 и 3 трябва да бъдат направени преди да се извършат допълнителни персонализиране в организацията за развитие. В рамките на стъпка 5, стъпка Б трябва да бъде завършена преди стъпка В.
Вижте също
Справка за файлов файл на компонент на решение (SolutionPackager)
Инструмент SolutionPackager
Формати на файлове за контрол на изходния код