Контрола извора помоћу датотека решења
Алатка SolutionPackager може се користити са било којим системом контроле извора. Када се .zip датотека решења распакује у фасциклу, једноставно додајте и проследите датотеке у ваш изворни систем контроле. Те датотеке се затим могу синхронизовати на другом рачунару где се могу спаковати у нову .zip датотеку идентичног решења.
Важан аспект приликом употребе распакованих датотека компоненти у контроли извора је да додавање свих датотека у контролу извора може узроковати непотребно дуплирање. Погледајте референцу на датотеку компоненте решења да бисте видели које датотеке се генеришу за сваку врсту компоненте и које се датотеке препоручују за употребу у управљању изворима.
Пошто су за решење потребна додатна прилагођавања и измене, програмери би требало да уређују или прилагођавају компоненте постојећим средствима, поново их извезу да би креирали .zip датотеку и распакују компримовану датотеку решења у исту фасциклу.
Важно
Осим одељака описаних у чланку Када уредити датотеку за прилагођавање, није подржано ручно уређивање распакованих датотека компоненти и .zip датотека.
Када алатка SolutionPackager распакује датотеке компоненти, оне неће заменити постојеће датотеке истог имена ако је садржај датотеке идентичан. Поред тога, алатка уважава атрибут само за читање на датотекама компоненти, креирајући упозорење у прозору конзоле да одређене датотеке нису записане. То кориснику омогућава да из контроле извора одјави минималан скуп датотека које се мењају. Параметар /clobber се може користити за измену и узрокује да датотеке само за читање буду записане или избрисане. Параметар /allowWrite се може користити за оцењивање утицаја који операција распакивања има, а да у ствари не проузрокује записивање или брисање датотека. Коришћење параметра /allowWrite са детаљним евидентирањем је ефективно.
Када се операција распакивања заврши са минималним скупом датотека које су одјављене из контроле извора, програмер може вратити измењене датотеке назад у контролу извора, као што се ради са било којом другом врстом изворне датотеке.
Развој тима
Када има више програмера који раде на истој компоненти решења, може доћи до сукоба где промене два програмера резултирају променама у једној датотеци. Ова појава се минимизује декомпозицијом сваке појединачне компоненте или подкомпоненте која се може уређивати у посебну датотеку. Размотрите следећи пример.
Програмери А и Б раде на истом решењу.
На засебним рачунарима, обојица добијају најновије изворе решења из контроле извора, пакују и увозе .zip датотеку некомплетног решења у независне Microsoft Dataverse организације.
Програмер А прилагођава системски приказ „Активни контакти“ и главни образац за ентитет Контакти.
Програмер Б прилагођава главни образац за ентитет Контакт и мења „Приказ проналажења контаката“.
Оба програмера извозе .zip датотеку некомплетног решења и распакују је.
Програмер А мора да одјави једну датотеку за главни образац Контакт и једну датотеку за приказ „Активни контакти“.
Програмер Б мора да одјави једну датотеку за главни образац Пословни контакт и једну датотеку за „Приказ проналажења контаката“.
Оба програмера могу проследити садржај било којим редоследом, пошто су се њихове промене бавиле засебним датотекама.
Када се оба прослеђивања заврше, могу да понове 2. корак, а затим да наставе са додатним променама у својим независним организацијама. Обојица имају оба скупа измена, без преписивања сопственог дела.
Претходни пример функционише само ако се измене дешавају на засебним датотекама. Неизбежно је да независна прилагођавања захтевају измене унутар једне датотеке. На основу приказаног примера, узмите у обзир да је програмер Б прилагодио приказ „Активни контакти“, док га је и програмер А прилагодио. У овом новом примеру, редослед догађаја постаје важан. Исправан поступак усклађивања ове тешкоће, описан у целости, спроводи се на следећи начин.
Програмери А и Б раде на истом решењу.
На засебним рачунарима, обојица добијају најновије изворе решења из контроле извора, пакују и увозе .zip датотеку некомплетног решења у независне организације.
Програмер А прилагођава системски приказ „Активни контакти“ и главни образац за ентитет Контакти.
Програмер Б прилагођава главни образац за ентитет Контакт и мења приказ „Активни контакти“.
Оба програмера извозе zip датотеку некомплетног решења и распакују је.
Програмер А мора да одјави једну датотеку за главни образац Контакт и једну датотеку за приказ „Активни контакти“.
Програмер Б мора да одјави једну датотеку за главни образац Пословни контакт и једну датотеку за приказ „Активни контакти“.
Програмер А је први спреман.
Пре него што програмер А поднесе контроли извора, они морају да добију најновије изворе како би се осигурало да нема претходних провјера у сукобу са њиховим промјенама.
Нема сукоба, тако да програмер А може да пошаље.
Програмер Б спреман као следећи после програмера А.
Пре него што програмер Б поднесе они морају да добију најновије изворе како би се осигурало да нема претходних провера у сукобу са њиховим променама.
Постоји конфликт јер је фајл за "Активне контакте" модификован од када је програмер Б последњи пут преузео најновије изворе.
Програмер Б мора да разреши ту неусаглашеност. Могуће је да могућности система за контролу извора који се користи могу помоћи овом процесу; у супротном, одрживи су следећи избори.
Програмер Б, кроз историју контроле извора, ако је доступан, може видети да је програмер А извршио претходну измену. Кроз директну комуникацију, они могу расправити сваку промену. Тада програмер Б мора само да ажурира организацију са договореном резолуцијом. Програмер Б затим извози, извлачи и преписује конфликтну датотеку и шаље.
Дозволи контроли изворног кода да препише локални фајл. Програмер Б пакује решење и увози га у своју организацију, а затим процењује стање погледа и поново га прилагођава по потреби. Затим, програмер Б може извозити, издвојити и преписати конфликтну датотеку.
Ако се претходна промена може сматрати непотребном, програмер Б дозвољава својој копији фајла да препише верзију у контроли изворног кода и пошаље.
Без обзира на то да ли ради у заједничкој организацији или независним организацијама, тимски развој Dataverse решења захтева да они који активно раде на заједничком решењу буду свесни рада других. Алатка SolutionPackager не уклања у потпуности ову потребу, али омогућава лако обједињавање измена које нису неусаглашене на нивоу контроле извора и проактивно наглашава конкретне компоненте тамо где је дошло до неусаглашености.
Следећи одељци су генерички процеси за ефикасно коришћење алата SolutionPackager у контроли извора приликом развоја са тимовима. Они раде равноправно са независним организацијама или заједничким развојним организацијама, мада ће са заједничким организацијама извоз и распакивање природно обухватати све измене које су присутне у решењу, а не само оне које је направио програмер који је обавио извоз. Слично томе, при увозу .zip датотеке решења јавиће се природно понашање да се замене све компоненте.
Креирање решења
Следећи поступак идентификује типичне кораке који се користе приликом првог креирања решења.
У чистој организацији креирајте решење на Dataverse серверу, а затим додајте или креирајте компоненте по потреби.
Када будете спремни за пријаву, урадите следеће.
Извезите некомплетно решење.
Користећи алатку SolutionPackager, распакујте решење у датотеке компоненти.
Из тих распакованих датотека компоненти, додајте потребне датотеке у контролу извора.
Проследите ове измене у контролу извора.
Измена решења
Следећи поступак идентификује типичне кораке који се користе приликом измене постојећег решења.
Синхронизујте или добијте најновије изворе датотека компоненти решења.
Помоћу алатке SolutionPackager спакујте датотеке компоненти у .zip датотеку некомплетног решења.
Увезите датотеку некомплетног решења у организацију.
Прилагодите и уредите решење по потреби.
Када будете спремни да проверите измене у контроли извора, урадите следеће.
Извезите некомплетно решење.
Користећи алатку SolutionPackager, распакујте извезено решење у датотеке компоненти.
Синхронизујте или добијте најновије изворе из контроле извора.
Усагласите неусаглашености ако их има.
Проследите измене у контролу извора.
Кораци 2 и 3 морају се обавити пре него што се у развојној организацији појаве даља прилагођавања. У кораку 5, корак б мора бити завршен пре корака в.
Такође погледајте
Референца датотеке компоненте решења (СолутионПацкагер)
Алатка СолутионПацкагер