Controlul sursei cu fișiere soluție

Instrumentul Solution Packager poate fi utilizat cu orice sistem de control al sursei. După ce un fișier .zip al soluției este extras într-un folder, adăugați și trimiteți fișierele către sistemul de control al sursei. Aceste fișiere pot fi apoi sincronizate pe un alt computer unde pot fi ambalate într-un nou fișier identic .zip de soluție.

Un aspect important atunci când se utilizează fișiere componente extrase în controlul sursei este că adăugarea tuturor fișierelor în controlul sursei ar putea cauza duplicarea inutilă. Accesați *Referința fișierelor componentelor soluției* pentru a descoperi ce fișiere sunt generate pentru fiecare tip de componentă și ce fișiere sunt recomandate pentru utilizare în controlul sursei.

Deoarece sunt necesare alte particularizări și modificări pentru soluție, dezvoltatorii ar trebui să editeze sau să particularizeze componentele prin mijloace existente, să exporte din nou pentru a crea un fișier .zip și să extragă fișierul de soluție comprimat în același folder.

Important

Cu excepția secțiunilor descrise în Când se editează fișierul de personalizare, editarea manuală a fișierelor componente extrase și a fișierelor .zip nu este acceptată.

Când instrumentul Solution Packager extrage fișierele componente, acesta nu suprascrie fișierele componente existente cu același nume dacă conținutul fișierelor este identic. În plus, instrumentul onorează atributul „doar citire” pentru fișierele componente, generând un avertisment în fereastra consolei că anumite fișiere nu au fost scrise. Această protecție permite utilizatorului să extragă, din controlul sursei, setul minim de fișiere care se modifică. Parametrul /clobber poate fi folosit pentru a înlocui și face ca fișierele numai în citire să fie scrise sau șterse. Parametrul /allowWrite poate fi utilizat pentru a evalua ce impact are o operațiune de extragere fără a provoca efectiv scrierea sau ștergerea fișierelor. Utilizarea parametrului /allowWrite cu înregistrarea în jurnal detaliată este eficientă.

După ce operațiunea de extragere este finalizată cu setul minim de fișiere extrase din controlul sursei, un dezvoltator poate trimite fișierele modificate înapoi în controlul sursei, așa cum se întâmplă cu orice alt tip de fișier sursă.

Formate de fișiere pentru controlul sursei

Instrumentul Solution Packager suportă două formate de fișiere pentru fișierele componente extrase. Alegerea formatului potrivit de la început evită migrarea structurii depozitului ulterior.

Format XML (moștenire) Format de control versiune YAML
Manifestul soluției Other\Solution.xml + Other\Customizations.xml solutions/<name>/solution.yml și suport pentru fișiere YAML
Lizibilitate Verbose XML Compact YAML — mai ușor de citit și de revizuit
Calitatea diferențelor în Git Diferențe XML mari Diferențe minime, focalizate
Depozit multi-soluție Neacceptat Suportat — mai multe soluții împart un folder
Aplicații Canvas (.msapp) Neacceptat Acceptate
Fluxuri moderne Neacceptat Acceptate
Integrare nativă Git Neutilizat Întotdeauna folosit — integrarea Git scrie întotdeauna YAML

Când să folosești formatul YAML: Pentru toate proiectele noi și ori de câte ori folosești integrarea nativă Dataverse cu Git. Formatul YAML este compatibil înainte și produce un istoric al modificărilor mai curat.

Când să folosești formatul XML: Doar când lucrezi cu depozite existente care deja folosesc formatul XML sau când folosești unelte vechi care nu suportă YAML.

Notă

Când faci commit-uri folosind integrarea nativă Git în Power Apps, ele sunt întotdeauna stocate în formatul de control versiune YAML. Pentru a împacheta sau despacheta manual acea sursă folosind SolutionPackager sau pac solution pack, folderul trebuie să urmeze structura de foldere YAML. Mai multe informații: Instrumentul SolutionPackager — Formate de fișiere pentru controlul sursei

Dezvoltarea în echipă

Când există mai mulți dezvoltatori care lucrează la aceeași componentă a soluției, poate apărea un conflict în cazul în care modificările efectuate de doi dezvoltatori duc la modificări ale unui singur fișier. Această apariție este redusă prin descompunerea fiecărei componente sau subcomponente editabile individual într-un fișier distinct. Luați în considerare următorul exemplu.

  1. Dezvoltatorii A și B lucrează amândoi la aceeași soluție.

  2. Pe calculatoare independente, ambele primesc cele mai noi surse ale soluției prin controlul versiunii, pachete și importul unui fișier negestionat .zip soluție în organizații independente de Microsoft Dataverse.

  3. Dezvoltatorul A personalizează vizualizarea sistemului "Active Contacts" și formularul principal pentru entitatea de contact.

  4. Dezvoltatorul B personalizează formularul principal pentru entitatea Cont și modifică „Vizualizarea Căutare Contact”.

  5. Ambii dezvoltatori exportă o soluție negestionată fișier .zip și dezarhivează.

    1. Dezvoltatorul A va trebui să verifice un fișier pentru formularul principal Contact și un fișier pentru vizualizarea "Active Contacts".

    2. Dezvoltatorul B va trebui să extragă un fișier pentru formularul principal Cont și un fișier pentru „Vizualizarea Căutare Contact”.

  6. Ambii dezvoltatori pot trimite modificări, în orice ordine, pe măsură ce modificările lor au atins fișiere separate.

  7. După ce ambele trimiteri sunt finalizate, ei pot repeta pasul #2 și apoi continuă să facă modificări suplimentare în organizațiile lor independente. Fiecare are ambele seturi de modificări, fără a fi suprascrise de propria lucrare.

Exemplul anterior funcționează numai atunci când există modificări ale fișierelor separate. Este inevitabil ca personalizările independente să necesite modificări într-un singur fișier. Pe baza exemplului prezentat anterior, considerați că dezvoltatorul B a personalizat vizualizarea "Active Contacts" în timp ce dezvoltatorul A o personaliza și el. În acest nou exemplu, ordinea evenimentelor devine importantă. Procesul corect de reconciliere a acestei situații dificile, redactat integral, este descris aici.

  1. Dezvoltatorii A și B lucrează amândoi la aceeași soluție.

  2. Pe computere independente, ambele primesc cele mai recente surse ale soluției de la controlul sursei, arhivează și importă un fișier .zip de soluție negestionată în organizații independente.

  3. Dezvoltatorul A personalizează vizualizarea sistemului "Active Contacts" și formularul principal pentru tabelul de contacte.

  4. Dezvoltatorul B personalizează formularul principal pentru tabelul Cont și modifică „Contactele active”.

  5. Ambii dezvoltatori exportă o soluție negestionată fișier .zip și dezarhivează.

    1. Dezvoltatorul A va trebui să verifice un fișier pentru formularul principal Contact și un fișier pentru vizualizarea "Active Contacts".

    2. Dezvoltatorul B va trebui să verifice un fișier pentru formularul principal al contului și un fișier pentru vizualizarea "Active Contacts".

  6. Dezvoltatorul A este gata mai întâi.

    1. Înainte ca dezvoltatorul A să trimită modificările către controlul sursei, acesta trebuie să obțină cele mai recente surse pentru a se asigura că nicio arhivare anterioară nu intră în conflict cu modificările sale.

    2. Nu există conflicte, deci dezvoltatorul A poate trimite.

  7. Dezvoltatorul B este gata, urmându-l pe dezvoltatorul A.

    1. Înainte ca dezvoltatorul B să trimită modificările, acesta trebuie să obțină cele mai recente surse pentru a se asigura că nicio verificare anterioară nu intră în conflict cu modificările efectuate.

    2. Există un conflict deoarece fișierul pentru "Active Contacts" a fost modificat de când dezvoltatorul B a recuperat ultima dată cele mai recente surse.

    3. Dezvoltatorul B trebuie să concilieze conflictul. Este posibil ca capacitățile sistemului de control al sursei utilizat să ajute acest proces; în caz contrar, următoarele opțiuni sunt toate viabile.

      1. Dezvoltatorul B, prin intermediul istoricului controlului sursă, dacă este disponibil, poate observa că dezvoltatorul A a efectuat modificarea anterioară. Prin comunicare directă pot discuta despre fiecare schimbare. Apoi, dezvoltatorul B trebuie doar să actualizeze organizația cu rezoluția convenită. Dezvoltatorul B exportă, extrage și suprascrie fișierul în conflict și îl trimite.

      2. Permiteți controlului sursă să suprascrie fișierul local. Dezvoltatorul B împachetează soluția și o importă în organizația sa, apoi evaluează starea vizualizării și o recalibrează după cum este necesar. Apoi, dezvoltatorul B ar putea exporta, extrage și suprascrie fișierul în conflict.

      3. Dacă modificarea anterioară este considerată inutilă, dezvoltatorul B permite copiei sale a fișierului să suprascrie versiunea din controlul sursei și o trimite.

Indiferent dacă se lucrează într-un mediu comun sau independent, dezvoltarea în echipă a soluțiilor necesită ca cei care lucrează activ la o soluție comună să fie conștienți de munca celorlalți. Dataverse Instrumentul Solution Packager nu elimină complet această nevoie, dar permite îmbinarea ușoară a modificărilor neconflictuale la nivelul controlului sursei și evidențiază proactiv componentele concise în care apar conflicte.

Următoarele secțiuni prezintă procesele generice pentru utilizarea eficientă a instrumentului Solution Packager în controlul sursei atunci când dezvoltați cu echipe. Acestea funcționează în egală măsură cu medii independente sau medii de dezvoltare partajate, deși în mediile partajate exportul și extragerea includ în mod natural toate modificările prezente în soluție, nu doar pe cele făcute de dezvoltatorul care efectuează exportul. În mod similar, la importarea unui fișier .zip al unei soluții, apare comportamentul natural de suprascriere a tuturor componentelor.

Creați o soluție

Această procedură identifică pașii tipici utilizați atunci când creați pentru prima dată o soluție.

  1. Într-un mediu curat cu Dataverse, creați o soluție, apoi adăugați sau creați componente după cum este necesar.

  2. Când ești gata să te înregistrezi, urmează acești pași.

    1. Exportați soluția negestionată.

    2. Folosind instrumentul Solution Packager, extrageți soluția în fișierele componente.

    3. Din acele fișiere cu componente extras, adăugați fișierele necesare controlului sursă.

    4. Trimiteți aceste modificări controlului sursă.

Modificați o soluție

Următoarea procedură identifică etapele tipice utilizate când modificați o soluție existentă.

  1. Sincronizați sau obțineți cele mai recente surse de fișiere componente ale soluției.

  2. Folosind instrumentul Solution Packager, împachetați fișierele componentelor într-un fișier .zip de soluție negestionat.

  3. Importați fișierul soluției negestionate într-un mediu.

  4. Particularizați și editați soluția după cum este necesar.

  5. Când sunteți gata să verificați modificările în controlul sursei, urmați acești pași.

    1. Exportați soluția negestionată.

    2. Folosind instrumentul Solution Packager, extrageți soluția exportată în fișierele componente.

    3. Sincronizați sau obțineți cele mai recente surse de la controlul sursei.

    4. Reconciliați dacă există conflicte.

    5. Trimiteți aceste modificări controlului sursă.

    Pașii 2 și 3 trebuie făcuți înainte să apară alte particularizări în organizația de dezvoltare. În etapa 5, etapa b trebuie finalizată înainte de pasul c.

Vedeți și

Referință fișier componentă soluție (SolutionPackager)
Instrumentul SolutionPackager
Formate de fișiere pentru controlul sursei

  • Last updated on