Kódfolyamat-stratégia kiválasztása
Fontos, hogy olyan kódfolyamat-stratégiát válasszon, amely megfelel a csapat működésének. Több stratégiát is figyelembe kell vennie. A modul végén megismerkedhet a lehetőségekkel. A Tailspin webcsapata úgy dönt, hogy egy Giten és GitHubon alapuló kódfolyamat-stratégiát fejleszt.
Amikor Mara az Azure Boards konfigurálását végezte, ő és a csapat azonosítottak néhány feladatot, amelyekkel először foglalkozniuk kell. Az egyik feladat egy Git-alapú munkafolyamat létrehozása volt.
Hallgassuk, ahogy a csapat kidolgozza az együttműködés optimális módszereit. Jelenleg központosított verziókövetési rendszert használnak, de a terv az, hogy a Gitbe, egy elosztott rendszerbe költöznek.
Mara épp szorgosan dolgozik a hozzárendelt funkciókon, amikor Andy betoppan.
Andy: Szia Mara. A ma reggeli vezetői értekezleten kiderült, hogy csapatunk és a játékfejlesztő csapat különböző verziókövetési rendszereket használ. Az erőforrások csapatok közötti megosztásának egyszerűsítése érdekében arra kértek, hogy váltsunk egy elosztott verziókövetési rendszerre, amely jobban képes kezelni az együttműködést.
Ezt jó tudni. Ha emlékszel, feltesszük a táblánkra. Jelenleg egy központi verziókövetési rendszert használunk. Most már jól működik, de egyetértek azzal, hogy az elosztott verziókövetési rendszer jobb választás, amikor elkezdünk megosztani a csapatok között, és a csapatunk egyre nagyobb lesz. Az is feladat a táblán, hogy növelje a láthatóságot, hogy minden érdekelt tudja, mit csinál mindenki. Azt hiszem, egy elosztott forrás-vezérlő rendszer, mint a Git is segít.
Andy: Egy ideje ki akartam próbálni a Gitet. Úgy tűnik, nincs időm. Nehéz megtanulni és konfigurálni? Ha alkalmas, akkor talán most is dolgozhatnánk rajta. Unom már, hogy mindig halogatom a dolgokat. És jó lenne látni, hogy mindenki mit csinál, és hogy hozzáférhessen a teljes adattárhoz. Rendben, akkor miről is szól ez az egész?
Hadd magyarázzam el, majd eldöntheti, hogy úgy hangzik-e, mintha azonnal megvalósítanánk.
Mara és Andy a táblához lép, és elbeszélget a verziókövetésről.
Mi az a Git és az elosztott verziókövetés?
Mara: A bal oldali rajz központosított verziókövetés, mint a most használt. A team foundation verziókövetésben (TFVC) található kódbázis 
központi verziója mindenki által használt. Mindegyik a módosítani kívánt fájlokon dolgozik, majd újra egyesítjük őket a fő adattárban, amikor elkészültünk velük.
Andy: Igen, és ez működik nekünk. Nos, kivéve, amikor blokkoltak abban az időben, amikor beolvadt egy törés a központi adattárba.
Mara: Jobbra! Letiltottuk 
. A blokkolási probléma megoldásához használhatnánk elágaztatási stratégiát a TFVC-n, de a jelenlegi konfiguráció mellett az egyesítés bonyolulttá válhatna. És amikor ezt a törést megváltoztattuk 
, senki sem tudta elvégezni a munkát, amíg meg nem oldottuk. Ez a probléma mindig leselkedik, mert mindannyian ugyanazt a kódot használjuk.
A rajz jobb oldalán az elosztott verziókövetés látható. Még mindig van egy központi adattárunk 
, amely a kódbázis stabil verziója, de minden fejlesztő saját másolatot 
készít róla, amelyből dolgoznia kell. Ez lehetővé teszi számunkra a kísérletezést és a különböző megközelítések kipróbálását anélkül, hogy hatással lenne a központi adattárra.
Az elosztott verziókövetés azt is biztosítja, hogy csak a munkakód 
legyen egyesítve a központi adattárban. Akár úgy is beállíthatjuk, hogy a kód ne egyesíthető a felülvizsgálatig.
Az Azure DevOpsban az a jó, hogy a központosított verziókövetési és az elosztott verziókövetési rendszerekkel egyaránt jól működik.
Andy: Mi történik, ha egynél több személy módosítja ugyanazt a fájlt?
Mara: A Git gyakran több módosítást is képes automatikusan egyesíteni. Természetesen szeretnénk mindig meggyőződni arról, hogy a módosítások kombinációja olyan kódot eredményez, amely működik. Amikor a Git nem tudja automatikusan egyesíteni a módosításokat, közvetlenül a fájlban megjelöli az ütközéseket, így egy ember kiválaszthatja az elfogadni kívánt módosításokat.
Andy: Jelenleg a kód a saját kiszolgálón van tárolva. Ha elosztott verziókövetést használunk, hol tárolja a kód?
Örülök, hogy megkérdezted. Erre való az üzemeltetés.
Hol üzemeltethetem az adattáramat?
Amikor eldöntjük, hogy hol tároljuk az adattárakat, van néhány lehetőségünk. Üzemeltethetjük őket például egy helyi kiszolgálón, a Bitbucketben vagy a GitHubon. A Bitbucket és a GitHub webalapú üzemeltetési megoldások. Mindkettő bárhonnan elérhető.
Andy: Használta valamelyiket?
Korábban a GitHubot használtam. A fejlesztők számára fontos funkciókkal rendelkezik, például a naplók módosításához és a verziókövetési funkciókhoz a parancssorból vagy az online portálról.
Andy: Hogyan működik a Git?
Hogyan tudom használni?
Mara: Ahogy már említettem, elosztott rendszerek esetén a fejlesztők szabadon hozzáférhetnek minden szükséges fájlhoz anélkül, hogy más fejlesztők munkáját befolyásolnák, mert saját másolatuk van az adattárról. A klón az adattár helyi példányát jelenti.
Amikor egy funkción vagy egy hiba kijavításán dolgozunk, általában több megközelítést is kipróbálunk, amíg rátalálunk az ideális megoldásra. A kód kipróbálása azonban a fő kódbázis másolatán nem jó ötlet, mert előfordulhat, hogy nem szeretné megtartani az első néhány próbálkozást.
A jobb megoldás érdekében a Git rendelkezik egy elágaztatás nevű funkcióval, ahol annyi példányt tarthat fenn, amennyit csak szeretne, és csak azt egyesítheti vissza, amelyet meg szeretne tartani. Ezáltal a fő ág stabil marad.
Andy: Eddig értem a fogalmakat. Hogy illeszthetem vissza a kódomat?
Hogyan jutnak el a helyi módosítások a fő kódbázishoz?
Mara: A Gitben az alapértelmezett ágat vagy törzset általában .main
Ha úgy érzi, hogy a kód készen áll arra main , hogy az összes fejlesztő által megosztott központi adattár ágába egyesíthető legyen, létre kell hoznia egy lekéréses kérelmet. Amikor létrehoz egy lekéréses kérelmet, azt mondja a többi fejlesztőnek, hogy a kód készen áll az áttekintésre, és azt szeretné, hogy az main elágazásba egyesítve legyen. A lekéréses kérelem jóváhagyása és egyesítése után a központi kódbázis részévé válik.
Hogy néz ki az elágaztatási munkafolyamat?
1. lépés: Amikor egy új szolgáltatáson vagy hibajavításon kezd dolgozni, először győződjön meg arról, hogy a legújabb stabil kódbázissal kezd. Ehhez szinkronizálja a main ág helyi példányát a kiszolgáló példányával. Ez beolvasja a helyi példányba az összes olyan fejlesztői módosítást, amelyet a main legutóbbi szinkronizálás óta a kiszolgáló ágába küldtünk.
2. lépés: Annak biztosítása érdekében, hogy csak a kód másolatán dolgozik, hozzon létre egy új ágat csak az adott funkcióhoz vagy hibajavításhoz. Ahogy el tudja képzelni, hogy sok ágat kell használnia az összes művelethez, nehéz lehet megjegyezni, ezért a jó elnevezési konvenció használata kritikus fontosságú.
Mielőtt módosításokat végez egy fájlon, ki kell jelölnie egy új ágat, hogy tudja, hogy az adott ág fájljain dolgozik, nem pedig egy másik ágból. Az ágak között bármikor válthat egy másik ág kivételével.
3. lépés: Most már nyugodtan elvégezheti a kívánt módosításokat, mert ezek a módosítások csak az ágban vannak. Munka közben véglegesítheti a módosításokat az ágon, hogy ne veszítsen el semmilyen munkát, és módot biztosítson a korábbi verziókban végrehajtott módosítások visszaállítására. A módosítások véglegesítése előtt úgy kell előkészítenie a fájlokat, hogy a Git tudja, melyiket szeretné véglegesíteni.
4. lépés: A következő lépés a helyi ág leküldése vagy feltöltése a távoli adattárba (például a GitHubra), hogy mások láthassák, min dolgozik. Ne aggódjon, ez még nem jelenti a módosítások egyesítését. Munkáját olyan gyakran töltheti fel, amilyen gyakran csak szeretné. Valójában ez egy jó módszer arra, hogy biztonsági másolatot készítsen a munkájáról, vagy lehetővé tegye, hogy több számítógépről dolgozzon.
5. lépés: Ez a lépés gyakori, de nem kötelező. Ha meggyőződik arról, hogy a kód a kívánt módon működik, lekérheti vagy egyesítheti a távoli main ágat a helyi main ágba. Bizonyára abban is számos olyan módosítás történt, amellyel a helyi main ág még nem rendelkezik. Miután szinkronizálta a távoli main ágat a sajátjaival, egyesítse a helyi main ágat a munkaágban, és tesztelje újra a buildet.
Ez a folyamat segít biztosítani, hogy a funkció a legújabb kóddal is működjön. Azt is segít biztosítani, hogy az írt kód zökkenőmentesen integrálódjon a lekéréses kérelem elküldésekor.
6. lépés: A helyi kódot le kell véglegesíteni, és le kell küldeni az üzemeltetett adattárba. Ez megegyezik a 3. és 4. lépéssel.
7. lépés: Végre készen áll arra, hogy javaslatot tegyen a távoli main ág módosításaira. Ehhez lekéréses kérelmet kell indítania. Ha az Azure Pipelinesban vagy egy másik CI/CD-rendszerben van konfigurálva, ez a lépés elindítja a buildelési folyamatot, és megtekintheti, ahogy a módosítások végighaladnak a folyamaton. Miután a build sikeres volt, és mások jóváhagyták a lekéréses kérelmet, a kód egyesíthető a távoli main ágba. (Még mindig egy emberen múlik, hogy egyesítse a módosításokat.)
Andy: Ez minden úgy néz ki, bonyolult és nehéz tanulni.
Mara: Git tűnhet ijesztő, mert olyan erős, de miután kap a lefagy a folyamat, kezd érezni természetes.
Naponta csak néhány parancsot fog használni. Íme egy összegzés:
| Kategória | Végrehajtandó feladat | Ezt a parancsot használja |
|---|---|---|
| Adattár kezelése | Git-adattár létrehozása | git init |
| Távoli adattár letöltése | git clone |
|
| Ág | Ág létrehozása | git checkout |
| A változások előkészítése és véglegesítése | A módosult fájlok listájának megtekintése | git status |
| Fájlok előkészítése véglegesítésre | git add |
|
| Fájlok véglegesítése az ágba | git commit |
|
| Távoli szinkronizálás | Ág letöltése egy távoli adattárból | git pull |
| Ág feltöltése egy távoli adattárba | git push |
Andy: Ez úgy hangzik, mint egy jó kiindulási pont. Ez biztosan menni fog. A speciálisabb parancsokat pedig majd menet közben megtanulom.