Partajați prin

Controlul sursei cu fișiere soluție

  • Articol

Instrumentul SolutionPackager poate fi utilizat cu orice sistem de control sursă. După ce un fișier soluție .zip a fost extras într-un folder, pur și simplu adăugați și trimiteți fișierele la sistemul dvs. de control sursă. 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 utilizați fișiere cu componente extrase în controlul sursei este că adăugarea tuturor fișierelor în controlul sursei poate provoca duplicarea inutilă. Consultați Referința fișierului componentelor soluției pentru a vedea 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 să editați fișierul de particularizări, editarea manuală a fișierelor cu componente extras și a fișierelor .zip nu este acceptată.

Când instrumentul SolutionPackager extrage fișierele componente, acesta nu va suprascrie fișierele componente existente cu același nume, dacă conținutul fișierului este identic. În plus, instrumentul onorează atributul numai de citire pe fișierele componente care produc un avertisment în fereastra consolei că anumite fișiere nu au fost scrise. Acest lucru permite utilizatorului să verifice, de la controlul sursei, setul minim de fișiere care se schimbă. 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 completată cu setul minim de fișiere verificate de la controlul sursei, un dezvoltator poate trimite fișierele schimbate înapoi la controlul sursă, așa cum se face cu orice alt tip de fișier sursă.

Dezvoltarea în echipă

Când există mai mulți dezvoltatori care lucrează la aceeași componentă de soluție, poate apărea un conflict în cazul în care modificările de la doi dezvoltatori au ca rezultat modificări la un 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 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 Microsoft Dataverse independente.

  3. Dezvoltatorul A particularizează vizualizarea de sistem „Contacte active” și formularul principal pentru entitatea Persoană de contact.

  4. Dezvoltatorul B particularizează formularul principal pentru entitatea Cont și modifică „Vizualizarea de căutare persoană de 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 „Persoane de contact active”.

    2. Dezvoltatorul B va trebui să verifice un fișier pentru formularul principal Cont și un fișier pentru vizualizarea „Vizualizarea de căutare persoană de contact”.

  6. Ambii dezvoltatori pot trimite, în orice ordine, întrucât 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 particularizările independente să necesite modificări într-un singur fișier. Pe baza exemplului prezentat mai sus, luați în considerare faptul că dezvoltatorul B a particularizat vizualizarea „Persoane de contact active”, în timp ce dezvoltatorul A o și particulariza. În acest nou exemplu, ordinea evenimentelor devine importantă. Procesul corect de reconciliere a acestei situații, redactat integral, este următorul.

  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 particularizează vizualizarea de sistem „Contacte active” și formularul principal pentru entitatea Persoană de contact.

  4. Dezvoltatorul B particularizează formularul principal pentru entitatea Cont și modifică „Persoane de contact active”.

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

    1. Dezvoltatorul A va trebui să verifice un fișier pentru formularul principal Contact și un fișier pentru vizualizarea „Persoane de contact active”.

    2. Dezvoltatorul B va trebui să verifice un fișier pentru formularul principal Cont și un fișier pentru vizualizarea „Vizualizare persoane de contact active”.

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

    1. Înainte ca dezvoltatorul A să se supună controlului sursei, trebuie să obțină cele mai recente surse pentru a se asigura că nu există înregistrări anterioare în conflict cu modificările lor.

    2. Nu există conflicte, așa că dezvoltatorul A poate trimite.

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

    1. Înainte ca dezvoltatorul B să trimită, trebuie să obțină cele mai recente surse pentru a se asigura că nu există înregistrări prealabile în conflict cu modificările lor.

    2. Există un conflict deoarece fișierul pentru „Contacte active” a fost modificat de când dezvoltatorul B a preluat ultima dată cele mai recente surse.

    3. Dezvoltatorul B trebuie să concilieze conflictul. Este posibil ca capacitățile sistemului de control sursă în utilizare să ajute acest proces; în caz contrar, următoarele alegeri sunt viabile.

      1. Dezvoltatorul B, prin istoricul controlului sursă, dacă este disponibil, poate vedea că dezvoltatorul A a făcut modificările anterioare. Prin comunicare directă pot discuta despre fiecare schimbare. Apoi dezvoltatorul B trebuie doar să actualizeze organizația cu rezoluția convenită. Dezvoltatorul B apoi exportă, extrage și suprascrie fișierul aflat în conflict și trimite.

      2. Permite 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 re-personalizează după cum este necesar. Apoi, dezvoltatorul B poate exporta, extrage și suprascrie fișierul aflat în conflict.

      3. Dacă modificarea anterioară poate fi considerată inutilă, dezvoltatorul B permite copiei fișierului să suprascrie versiunea în controlul sursei și trimite.

Indiferent dacă lucrează la o organizație comună sau organizații independente, dezvoltarea de echipă a soluțiilor Dataverse necesită ca cei care lucrează activ la o soluție comună să fie conștienți de munca altora. Instrumentul SolutionPackager nu elimină pe deplin această nevoie, dar permite îmbinarea ușoară a modificărilor care nu intră în conflict la nivelul controlului sursă și evidențiază proactiv componentele concise în care au apărut conflictele.

Următoarele secțiuni sunt procesele generice pentru a utiliza eficient instrumentul SolutionPackager în controlul sursei atunci când se dezvoltă cu echipe. Acestea lucrează în egală măsură cu organizații independente sau organizații de dezvoltare partajată, deși cu organizații partajate, exportul și extrasul vor include în mod natural toate modificările prezente în cadrul soluției, nu doar cele realizate de dezvoltatorul care efectuează exportul. În mod similar, atunci când importați o soluție de fișier .zip, va apărea comportamentul natural de a suprascrie toate componentele.

Crearea unei soluții

Următoarea procedură identifică etapele tipice utilizate la crearea unei soluții.

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

  2. Când sunteți gata de check-in, faceți următoarele.

    1. Exportați soluția negestionată.

    2. Folosind instrumentul SolutionPackager, 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. Utilizând instrumentul SolutionPackager, împachetați fișierele componente într-un fișier .zip al unei soluții negestionate.

  3. Importați fișierul cu soluții negestionate într-o organizație.

  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, faceți următoarele.

    1. Exportați soluția negestionată.

    2. Folosind instrumentul SolutionPackager, 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.

Consultați și

Referința fișierului Componentei de soluție (SolutionPackager)
Instrumentul SolutionPackager