Riadenie zdrojov pomocou súborov riešení

Nástroj Solution Packager je možné použiť s akýmkoľvek systémom správy zdrojového kódu. Po rozbalení súboru .zip s riešením do priečinka pridajte a odošlite súbory do systému správy zdrojového kódu. Tieto súbory potom môžu byť synchronizované na inom počítači, kde môžu byť zabalené do nového identického súboru .zip riešenia.

Dôležitým aspektom pri použití extrahovaných súborov komponentov v systéme riadenia zdrojového kódu je, že pridanie všetkých súborov do systému riadenia zdrojového kódu môže spôsobiť zbytočnú duplikáciu. Prejdite do Referenčnej príručky k súborom komponentov riešenia a zistite, ktoré súbory sa generujú pre každý typ komponentu a ktoré súbory sa odporúčajú na použitie v systéme správy zdrojového kódu.

Keďže pre riešenie sú potrebné ďalšie úpravy a zmeny, vývojári by mali upravovať alebo prispôsobovať komponenty pomocou existujúcich prostriedkov, znova exportovať a vytvoriť súbor .zip a extrahovať súbor komprimovaného riešenia do rovnakého priečinka.

Dôležité

Okrem častí opísaných v časti Kedy upraviť súbor s prispôsobeniami nie je podporovaná manuálna úprava extrahovaných súborov komponentov a súborov .zip.

Keď nástroj Solution Packager extrahuje súbory súčastí, neprepíše existujúce súbory súčastí s rovnakým názvom, ak je obsah súborov identický. Nástroj navyše rešpektuje atribút „len na čítanie“ v súboroch komponentov a v okne konzoly zobrazuje upozornenie, že konkrétne súbory neboli zapísané. Táto ochrana umožňuje používateľovi skontrolovať zo systému správy zdrojového kódu minimálnu sadu súborov, ktoré sa menia. Parameter /clobber možno použiť na prepísanie nastavenia a zapísanie alebo vymazanie súborov určených len na čítanie. Parameter /allowWrite možno použiť na posúdenie vplyvu operácie extrakcie bez toho, aby sa skutočne zapísali alebo vymazali akékoľvek súbory. Účinné je použitie parametre /allowWrite s podrobným protokolovaním.

Po dokončení operácie extrakcie s minimálnou sadou súborov odobratých zo správy zdrojového kódu môže vývojár odoslať zmenené súbory späť do správy zdrojového kódu, rovnako ako v prípade akéhokoľvek iného typu zdrojového súboru.

Formáty súborov na správu zdrojového kódu

Nástroj Solution Packager podporuje dva formáty súborov pre extrahované komponenty súbory. Výber správneho formátu hneď na začiatku vám umožní neskoršiu migráciu štruktúry repozitára.

XML formát (dedičstvo) YAML formát správy zdrojového kódu
Manifest riešenia Other\Solution.xml + Other\Customizations.xml solutions/<name>/solution.yml a podpora YAML súborov
Čitateľnosť Verbose XML Kompaktný YAML — jednoduchšie na čítanie a kontrolu
Kvalita diff v Git Veľké XML rozdiely Minimálne, zamerané diferenciály
Repozitár s viacerými riešeniami Nie je podporované Podporované — viaceré riešenia zdieľajú jeden priečinok
Canvas aplikácie (.msapp) Nie je podporované Podporované
Moderné toky Nie je podporované Podporované
Integrácia s natívnym Gitom Nepoužíva sa Vždy používané — Integrácia Git vždy zapisuje YAML

Kedy používať formát YAML: Pre všetky nové projekty a vždy, keď používate natívnu integráciu Dataverse s Gitom. Formát YAML je kompatibilný s dopredu a vytvára čistejšiu históriu zmien.

Kedy používať formát XML: Iba pri práci s existujúcimi repozitármi, ktoré už používajú XML formát, alebo pri používaní starších nástrojov, ktoré nepodporujú YAML.

Poznámka

Keď commitujete riešenia pomocou natívnej integrácie Git v Power Apps, vždy sú uložené vo formáte YAML source control. Na manuálne zabalenie alebo rozbalenie tohto zdroja pomocou SolutionPackager alebo pac solution pack, musí priečinok dodržiavať štruktúru priečinka YAML. Viac informácií: Nástroj SolutionPackager — formáty súborov na správu zdrojového kódu

Tímový vývoj

Keď na tej istej súčasti riešenia pracuje viacero vývojárov, môže vzniknúť konflikt, pri ktorom zmeny od dvoch vývojárov vedú k zmenám v jednom súbore. Tento výskyt je minimalizovaný rozkladom každého jednotlivo upraviteľného komponentu alebo subkomponentu do samostatného súboru. Zvážte tento príklad.

  1. Vývojár A aj B pracujú na rovnakom riešení.

  2. Na nezávislých počítačoch obaja získavajú najnovšie zdroje riešenia z správy zdrojového kódu, zabalia a importujú nespravované riešenie .zip súbor do nezávislých Microsoft Dataverse organizácií.

  3. Vývojár A prispôsobuje systémový pohľad "Aktívne kontakty" a hlavný formulár pre entitu Kontakt.

  4. Vývojár B prispôsobí hlavný formulár pre entitu Obchodný vzťah a zmení „Zobrazenie vyhľadávania kontaktov“.

  5. Obaja vývojári exportujú súbor .zip s nespravovaným riešením a extrahujú ho.

    1. Vývojár A si bude musieť pozrieť jeden súbor pre hlavný formulár Kontakt a jeden súbor pre zobrazenie "Aktívne kontakty".

    2. Vývojár B bude musieť rezervovať jeden súbor pre hlavný formulár obchodného vzťahu a jeden súbor pre „Zobrazenie vyhľadávania kontaktov“.

  6. Obaja vývojári mohli odoslať zmeny v ľubovoľnom poradí, pretože ich príslušné zmeny sa dotýkali samostatných súborov.

  7. Po dokončení oboch odovzdaní môžu zopakovať krok č. 2 a potom pokračovať vo vykonávaní ďalších zmien vo svojich nezávislých organizáciách. Každý z nich má obe skupiny zmien bez toho, aby prepísali svoju vlastnú prácu.

Predchádzajúci príklad funguje iba v prípade zmien samostatných súborov. Je nevyhnutné, že nezávislé úpravy vyžadujú zmeny v rámci jedného súboru. Na základe uvedeného príkladu si uvedomme, že vývojár B prispôsobil pohľad "Aktívne kontakty", zatiaľ čo vývojár A ho zároveň prispôsoboval. V tomto novom príklade je dôležité poradie udalostí. Správny postup na vyriešenie tejto ťažkej situácie je v plnom rozsahu opísaný tu.

  1. Vývojár A aj B pracujú na rovnakom riešení.

  2. Na nezávislých počítačoch získajú najnovšie zdroje riešenia z riadenia zdrojov, balenia a importovania nespravovaného súboru .zip do nezávislých organizácií.

  3. Vývojár A prispôsobuje systémový pohľad "Aktívne kontakty" a hlavný formulár pre tabuľku kontaktov.

  4. Vývojár B prispôsobí hlavný formulár pre tabuľku Obchodný vzťah a zmení pole Aktívne kontakty.

  5. Obaja vývojári exportujú súbor .zip s nespravovaným riešením a extrahujú ho.

    1. Vývojár A si bude musieť pozrieť jeden súbor pre hlavný formulár Kontakt a jeden súbor pre zobrazenie "Aktívne kontakty".

    2. Vývojár B si bude musieť pozrieť jeden súbor pre hlavný formulár účtu a jeden súbor pre zobrazenie "Aktívne kontakty".

  6. Vývojár A je pripravený ako prvý.

    1. Predtým, ako vývojár A odošle zmeny do systému správy zdrojového kódu, musí získať najnovšie zdrojové kódy, aby sa zabezpečilo, že žiadne predchádzajúce zmeny nebudú v konflikte s jeho zmenami.

    2. Neexistujú žiadne konflikty, takže vývojár A môže odoslať.

  7. Vývojár B je pripravený po vývojárovi A.

    1. Pred odoslaním musí vývojár B získať najnovšie zdroje, aby sa zabezpečilo, že žiadne predchádzajúce zmeny nebudú v konflikte s jeho zmenami.

    2. Je tu konflikt, pretože súbor pre "Aktívne kontakty" bol od posledného stiahnutia najnovších zdrojov vývojárom B upravený.

    3. Vývojár B musí konflikt zmieriť. Je možné, že možnosti používaného systému správy zdrojového kódu môžu tomuto procesu napomôcť; inak sú všetky nasledujúce možnosti schodné.

      1. Vývojár B si môže prostredníctvom histórie správy zdrojového kódu, ak je k dispozícii, všimnúť, že predchádzajúcu zmenu vykonal vývojár A. Prostredníctvom priamej komunikácie môžu diskutovať o každej zmene. Vývojár B potom už len musí informovať organizáciu o dohodnutom uznesení. Vývojár B potom exportuje, extrahuje a prepíše konfliktný súbor a odošle ho.

      2. Povoliť správe zdrojového kódu prepísať lokálny súbor. Vývojár B zabalí riešenie a importuje ho do svojej organizácie, potom vyhodnotí stav zobrazenia a podľa potreby ho znova prispôsobí. Vývojár B môže ďalej exportovať, extrahovať a prepísať konfliktný súbor.

      3. Ak sa predchádzajúca zmena považuje za zbytočnú, vývojár B umožní svojej kópii súboru prepísať verziu v systéme správy zdrojového kódu a odošle ju.

Či už pracujú na zdieľanom alebo nezávislom prostredí, tímový vývoj riešení vyžaduje, aby tí, ktorí aktívne pracujú na spoločnom riešení, poznali prácu ostatných. Dataverse Nástroj Solution Packager túto potrebu úplne neodstraňuje, ale umožňuje jednoduché zlúčenie nekonfliktných zmien na úrovni správy zdrojového kódu a proaktívne zvýrazňuje stručné komponenty, v ktorých vznikajú konflikty.

Nasledujúce časti predstavujú všeobecné procesy na efektívne používanie nástroja Solution Packager v systéme správy zdrojového kódu pri vývoji s tímami. Tieto fungujú rovnako s nezávislými prostrediami alebo zdieľanými vývojovými prostrediami, hoci v zdieľaných prostrediach export a extrakcia prirodzene zahŕňajú všetky zmeny prítomné v riešení, nielen tie, ktoré vykonal vývojár vykonávajúci export. Podobne aj pri importe súboru .zip riešenia dochádza k prirodzenému správaniu, ktoré prepíše všetky komponenty.

Vytvorenie riešenia

Tento postup identifikuje typické kroky používané pri prvom vytváraní riešenia.

  1. V čistom prostredí s Dataverse vytvorte riešenie a potom podľa potreby pridajte alebo vytvorte komponenty.

  2. Keď ste pripravení na registráciu, postupujte podľa týchto krokov.

    1. Exportujte nespravované riešenie.

    2. Pomocou nástroja Solution Packager extrahujte riešenie do súborov súčastí.

    3. Z týchto extrahovaných súborov komponentov pridajte potrebné súbory do riadenie zdroja.

    4. Tieto zmeny odošlite do riadenia zdroja.

Úprava riešenia

Nasledujúci postup identifikuje typické kroky použité pri úprave existujúceho riešenia.

  1. Synchronizujte alebo získajte najnovšie zdroje súborov súčastí riešenia.

  2. Pomocou nástroja Solution Packager zabaľte súbory komponentov do súboru .zip nespravovaného riešenia.

  3. Importujte súbor nespravovaného riešenia do prostredia.

  4. Prispôsobte a upravte riešenie podľa potreby.

  5. Keď ste pripravení skontrolovať zmeny v systéme správy zdrojového kódu, postupujte podľa týchto krokov.

    1. Exportujte nespravované riešenie.

    2. Pomocou nástroja Solution Packager extrahujte exportované riešenie do súborov komponentov.

    3. Synchronizujte alebo získajte najnovšie zdroje z ovládania zdrojov.

    4. V prípade akýchkoľvek konfliktov vykonajte zmierenie.

    5. Zmeny odošlite do riadenia zdroja.

    Kroky 2 a 3 sa musia vykonať skôr, ako dôjde k ďalším úpravám vo vývojovej organizácii. V kroku 5 musí byť krok b dokončený pred krokom c.

Pozrite tiež

Referenčný súbor komponentov riešenia (SolutionPackager)
Nástroj SolutionPackager
Formáty súborov na správu zdrojového kódu

  • Last updated on