A szoftverprojektekbe való integrálás zökkenőmentes lehet tippjeink segítségével

Az évek során csapatunk megpróbálta elsajátítani, hogyan lehet úgy integrálni a szoftverprojekteket, hogy az ne igényeljen túl sok erőfeszítést az ügyféltől. Úgy döntöttünk, hogy összegyűjtjük tapasztalatainkat, hogy segítsük leendő ügyfeleinket abban, hogy megértsék, hogyan integrálódunk a csapatokba, és hogy segítsünk azoknak a fejlesztőtársainknak, akik éppen munkahelyet váltanak, és a beilleszkedéssel küzdenek.

Hogyan lehet az integrációt mindenki számára megkönnyíteni?

Egy új szoftverprojekt elindítása mindig izgalmas és néha ijesztő, de együttműködés nélkül eléggé frusztrálóvá is válhat. Fontos, hogy ne csak a szoftverprojekt technikai aspektusait ismerje, hanem az új munkatársak puha készségeit és személyiségét, valamint a projekt alapértékeit is. Ez egy útmutató lesz, amely elsősorban a szoftverprojektbe való beilleszkedés technikai részleteire összpontosít.

Munkáltatóként győződjön meg arról, hogy az új tag számára minden erőforrást igényelt, mielőtt megérkezik a projekthez. Ha ez nem lehetséges, tervezze meg előre, hogy ezt akkor tegye meg, amikor megérkezik. Azzal, hogy elhúzza a lényeges erőforrásokhoz való hozzáférés biztosítását, csak hátráltatja a fejlődés sebességét. Írjon például egy ellenőrző listát az útmutatónk alapján, amely az Ön szoftverprojektjére vonatkozik.

Győződjön meg róla, hogy megfelelően vette fel őket, és hogy a vállalaton belül tudnak kommunikálni Önnel. Microsoft Outlook? Gmail? Szükségük van speciális hitelesítésre vagy kemény tokenre, hogy elérjenek bizonyos dolgokat? Esetleg egy speciális laptop, amelyet a vállalat operációs rendszerével biztosítanak? Az informatikai biztonsági megoldások manapság végtelenek, és gyakran lassan rendeződnek, ezért fontos, hogy időben elkezdje.

A kód megosztása

Hol található a kód? Fontos, hogy hozzáférést adjon nekik a verziókezelő eszközhöz, amelyet a verziókezeléshez használ. Gondoljon a : Github, Bitbucket vagy Gitlab? Ellenőrizze ezt az első napon, amikor megérkeznek, hogy megbizonyosodjon arról, hogy el tudják kezdeni beállítani mindazt, amire szükségük van a munkához.

Fejlesztőként, miután hozzáférsz a kódhoz, elkezdhetsz kutakodni, de azt javasoljuk, hogy először nézd meg, hogyan működnek a tárolók:

• Ellenőrizd a pull/merge kéréseket! Látsz hozzájuk kapcsolódó CI/CD-t? Ha igen, ellenőrizze, milyen lépéseket kell elvégezni, mielőtt valaki zöld utat kaphat. Milyen minőségi kapukat lát? Ideje megkérdezni a fejlesztőtársakat, hogy vannak-e trükkös tesztek, amelyeket időről időre újra kell futtatni.
• Ellenőrizze, hogy mit írnak be egy pull request(PR) kérésbe, van-e minta? Esetleg a leírásban linkelik a történetet, vagy ez automatikusan történik? Hagynak képernyőképeket vagy gifeket, hogy elmagyarázzák, mit csinál a PR?
• Kiket adnak hozzá bírálóként? Vannak olyan kódtulajdonosok, akiknek mindig látniuk kell a kéréseket? Ők lehetnek azok az emberek, akikhez később segítségért fordulhat.
• Kérdezd meg őket: Van olyan teszt, amely nincs összekapcsolva a CI-vel, de hasznos lenne lefuttatni? Néha a csapat még nem áll készen a minőségkapuk teljes integrációjára.
• Használják a verziókezelővel együtt érkező problémakövetőket?

Felhőalapú vagy helyi hozzáférés

A felhőben történő fejlesztés során általában létrehoz egy felhasználót az új fejlesztő számára, és csak a szükséges hozzáférési jogokat korlátozza. Ha egy nagyvállalatnál van, ez eltarthat egy ideig, ezért ha lehetséges, próbálja meg korán elkezdeni a folyamatot.

Felhőfejlesztőként meg kellene próbálnia bejelentkezni a vállalat által használt felhőplatformra, és ellenőrizni a fejlesztéshez szükséges dolgokat. Ha a felhő CLI-hozzáférést is biztosít, állítsa be azt is, hogy lássa, minden működik-e, és hogy a számítógépéről át tudja-e tolni a változtatásokat.

Az on-prem szoftverek egy kicsit bonyolultabbak lehetnek, de általában azt szeretné megkérdezni, hogy hol találhatók a szerverek, és hogyan férhet hozzájuk. Az ilyen szoftvereket általában CI-n keresztül telepíti, és az IP-címén keresztül éri el. A kubernetes esetében megúszhatod azzal, hogy megkérdezel valakitől egy kubeconfigot. A legtöbb esetben a csapat devops mérnökét kell megkeresned, de gyakran a tesztmérnökök is jól ismerik a rendszert.

Mindkét esetben győződjön meg róla, hogy fel tudja sorolni a rendszer néhány alapvető erőforrását, és kiáltson, ha nem tudja.

Az adatbázis-hozzáférésért gyakran nehéz harcolni; egyes iparágakban nagyon szigorú szabályok vonatkoznak arra, hogy ki férhet hozzá az adatokhoz és ki nem, ami gyakran számos képzéssel és aláírandó extra szerződéssel is jár. Ha munkáltatóként hozzáférést szeretne adni az adatbázishoz egy új munkavállalónak, győződjön meg róla, hogy tájékozódik a szükséges lépésekről. Gyakran előfordul, hogy a nem nélkülözhetetlen fejlesztők nem kapnak hozzáférést bizonyos adatbázisokhoz, de ettől még dolgozhatnak olyan adatokon, amelyeket szintetikusan generáltak, hogy a valódi adatbázis érzetét keltsék; ez több kockázatot is felvet magában a szoftverben, de bizonyos esetekben ez lehet az egyetlen járható út, és fejlesztőként ezt el kell fogadnia.

CI/CD csővezetékek

Fontos, hogy a fejlesztők hozzáférjenek a CI/CD-csatornákhoz, mivel így jut el a kód az ügyfelekhez. Fontos számukra, hogy lássák, hogyan viselkedik a kód, amikor frissen épül és elindul, és gyorsan kell reagálniuk, ha valami baj van az általuk szállított kóddal. Néhány vállalat nem szívesen teszi ezt, mivel a CI/CD néha információkat tartalmaz a termelési környezetekről. Bizonyos esetekben a CI/CD-hozzáférés elengedhetetlen, és meg kell kérdeznie a fejlesztőit, hogy megtudja, ez a helyzet.

Fejlesztőként nagyon értékes információkat találhat a CI-jén. A konzol kimenetéből láthatja, hogy a CI milyen parancsot futtat, és milyen kimenetet kap. Néha itt lehet kihalászni azokat a környezeti változókat, amelyeket nem találtál meg a tárolókban. Ez az az eszköz is, amely megadja a build környezetet, ha az helyesen van beállítva, és ezt megoszthatja a fejlesztőtársakkal vagy a terméktulajdonossal felülvizsgálat céljából.

Mielőtt elkezdené a buildet, győződjön meg róla, hogy tudja, hogyan távolítsa el a build erőforrásokat. A legjobb megoldás a clean up nevű feladat, de ha nincs megfelelő dokumentáció a feladatokhoz, akkor beszélhetsz a devops mérnökkel vagy valakivel, aki korábban már használta ezeket a feladatokat előtted, hogy megtudd, hogyan működnek.

Lehet, hogy túl sok állás van a platformon, és ha ez a helyzet, akkor érdemes lehet megkérni valakit, hogy gyorsan mutassa meg, hol találja meg. Mielőtt azonban ezt megtenné, nézze meg azokat, amelyeket fontosnak tart, és próbálja megérteni őket. Írja le az összes kérdését a bemenetekkel és kimenetekkel kapcsolatban, hogy a megbeszélés hatékonyabban menjen, és hogy ne legyenek üresjáratok.

A hátralék megosztása

Hol található a hátralék? Jira, Rally, Trello... vagy egy táblára ragasztott jegyzetek? Bár az utóbbival nehéz lehet dolgozni, ha távoli fejlesztőt alkalmaz, a többihez fontos, hogy hozzáférjen. Az is fontos, hogy elmagyarázza az új csapattagnak a backlog munkafolyamatait.

• A fejlesztő hozzáadhat egy hibát a backloghoz, vagy meg kell kérdeznie a terméktulajdonost? Vagy van egy külön hely számukra, például a Github Issues?
• Milyen a jegyek életciklusa? Backlog -> teendők -> felülvizsgálat -> kész, vagy vannak külön fázisok, hogy megmutassuk a megvalósítást például a tervezőnek vagy egy építésznek?
• Hogyan hozod létre a történeteket? A terméktulajdonos adja meg őket, vagy a csapat írja őket valamilyen megbeszélésen, amelyen az új fejlesztőknek is részt kell venniük?
• Hogyan méretezed a történeteidet? Póló? Fibonacci? Vagy szabad szellem vagy, és egyáltalán nem használsz méretezést?
• Milyen történetfajtákat használsz? A felhasználói történetek gyakoriak, de egyes csapatok szeretik a technikai adósságot, a hibákat, a tesztelési adósságot és a felhasználói élmény javítását célzó különálló történettípusokat.

Agilis folyamatok, scrum és kanban

Ha még nem hívta meg az új csapattagot a scrum-szertartásokra, itt az ideje, hogy megtegye. Néhány szóban azt is elmondhatod nekik, hogyan használod a szertartásokat. Bár lehet, hogy eszedbe jut, hogy azonnal elkezdj dolgokat kiosztani az új csapattársadnak, fontos, hogy adj neki néhány napot, hogy beilleszkedjen, beállítsa a laptopját és a munkafolyamatokat, és beállítsa a tárolókat.

Új fejlesztőként meg kell figyelnie, hogy a csapat hogyan használja ezeket a szertartásokat, mert az agilis, nos, az agilis, és minden csapat másképp alkalmazza.

• Milyen szertartásaik vannak? Backlog finomítás, Grooming, Daily Standup (vagy nem annyira napi), Sprint Demo, Sprint Review, Sprint Retrospective... Termék Iteráció tervezés?
• Néha a szertartások kicsúszhatnak az irányítás alól, és átfedésekbe kerülhetnek, ha látod, hogy a csapat küszködik, különösen, ha egy friss csapatról van szó, segítsd ki őket azzal, hogy elmagyarázod nekik, mik ezek a szertartások, és hogyan lehetnek hasznosak. Ha a követelmények hiányoznak, az egy jel lehet arra, hogy elkezdjetek néhány Grooming foglalkozást.

Fejlesztőként valószínűleg a Daily Standup az első találkozó, amelyre meghívást kap. Kínosan bemutatkozhatsz, és elsüthetsz néhány viccet, de ne feledd, hogy ez a megbeszélés nagyon rövidnek van szánva, így valószínűleg nem itt fogod elkezdeni a szükséges információk megszerzését, de fontos, hogy figyelj a standupra: Ki vezeti azt? Mennyi ideig beszélnek az egyes fejlesztők? Ki min dolgozik? Lehet, hogy ez túlterhelő, mert ez a megbeszélés elég gyors, de jegyzetelhetsz, hogy ki a backend-fejlesztő és ki a devops mérnök, ki csinálja a frontendet és ki a teszteket.

A kommunikációs csatornák tesztelése

Bármilyen eszközt is használ a csapat, fontos megnézni, hogy milyen csatornáik vannak.

• Van olyan csatorna, ahol egy CI bot figyelmeztet a hibás buildekre? Ki a felelős az ott felmerülő problémák kezeléséért? Van egy dedikált személy, vagy bárki felveheti?
• Van egy csatorna a kódértékelések közzétételére?
• Hol kommunikál a vezetőséggel, és hol található a tech talk? Van olyan csatorna, ahol csak úgy lógni lehet?
• Mutatkozz be! Nem kell, hogy hosszú legyen, de egy egyszerű "Helló" néha sokat segíthet.

A tárolók ellenőrzése

Miután befejezted a bemutatkozást, belevetheted magad a kódba. Cégünk főleg Node és frontend projektekkel foglalkozik, de akkor is lehet valami hasznos, ha nem vagy Node fejlesztő, szóval még ne hagyd el az Alt F4-et!

Talán érdemes megemlíteni, hogy a legtöbb esetben be kell állítanod az SSH-kulcsokat a verzióvezérléshez, hogy képes legyél lehívni a tárolót. De ha ezt valamiért még nem tudod megtenni, akkor a Git webes verziójában is megnézheted a kódot.

Git konfiguráció

Mielőtt elkezdenéd, ellenőrizd, hogy a git konfigurációd megfelelően van-e beállítva. Hozzáadtad a neved és az email címed, beállítottad a sor vége a konfigurációdban? Nézze meg a listát, amit beállíthat a git-config dokumentáció.

A VsCode felhasználók személyes kedvence:

 git config -global core.editor "code -wait"

README és CODEOWNERS

Az első feladatod minden repositoryban az, hogy elolvasd a README-t, kövesd és javítsd.

Lehet, hogy a szent Gopher küldte, de lássuk be, a readmes hajlamos elavulni és elhagyni. Fontos, hogy frissítsd őket, mint új tag, aki még csak most állítja be a dolgokat. Vegyél elő egy jegyzettömböt, és írj le minden lépést, amit meg kell tenned, hogy a dolgok működjenek. Ez azt is lehetővé teszi, hogy a CI-t és a pull request munkafolyamatot kockázat nélkül tesztelhesd, mit tudsz elrontani egy readme-mel?

Egy másik szöveges fájl, ami hasznos lehet, a CODEOWNERS, ha ez rendben van tartva, talán ki tudsz halászni néhány nevet, akikhez fordulhatsz, ha rájössz, hogy a README elavult, és segítségre van szükséged.

Mély merülés: Ellenőrizze a fájlokat az adattárban

A package.json fájl tartalmazza a projektben futtatható általános szkripteket.Próbálja ki az összes teszt és linter szkriptet, mielőtt elkezdené a munkát, hogy megbizonyosodjon arról, hogy helyesen vannak telepítve.

Azt is ellenőrizheti, hogy a projekt milyen csomagokat használ. Ha valamelyik ismeretlen számodra, mindenképpen olvass bele gyorsan az npm vagy a Github oldalain.

Környezeti változók általában egy .env fájlba kerülnek mentésre, és elengedhetetlenek néhány tesztszkript futtatásához vagy a kód építéséhez és futtatásához. Ezek szintén olyan erőforrások, amelyeket egy README-ben is szeretnél megemlíteni, így ha ez sincs ott, akkor meg kell kérdezned a fejlesztőket. Előfordulhat, hogy a tároló nem használ környezeti változókat.

Git horgok kiváló eszköz a commitok tisztán tartására. A tárolókban lehetnek olyan horgok, amelyek a commit vagy push előtt lefutnak, és megakadályozzák, hogy szalagozatlan, nem tesztelt kódot commitolj. Lehet, hogy a commit üzenetek megírására is van egy konvenciójuk, amelyet követned kell. Érdemes tehát gyorsan elolvasni a hookot. Néhány eszköz a horgok számára husky és leftthook, ha ezeket látja a csomaglistában, próbálja megkeresni a konfigurációjukat.

Ellenőrizze, hogy mi szerkesztők a csapat használja. A .gitignore-ban a .idea és .vscode sorok azt jelenthetik, hogy a csapat több szerkesztőt használ, ezért számolj azzal, hogy a szerkesztőkre jellemző formázást és szalagozást láthatsz, ha a linterek és formázók nincsenek megfelelően beállítva. (Akár segíthetsz is nekik ebben)

Egyes csapatok inkább a .vscode mappát rögzítik, hogy a beállítások mindenki számára azonosak legyenek. Itt helyezik el az olyan fájlokat is, mint például a .extensions.json, amely a projekthez telepítendő hasznos bővítmények listáját adhatja meg.

A különböző szerkesztők fájdalmasak lehetnek. Győződjön meg róla, hogy a projektben látható konfigurációs fájlok alapján hozzáadja a szükséges bővítményeket a szerkesztőhöz. A VsCode felhasználók számára néhány ilyen lehet: eslint, prettier, stylelint, editorconfig. Szükség lehet arra is, hogy engedélyezze a formátumot mentéskor, és adja meg, hogy az egyes fájltípusoknál milyen kiterjesztést szeretne használni a formázáshoz.

Dockerfile és Jenkinsfile elárulhatja, hogyan épül fel a tároló, és milyen CI/CD lépésekkel rendelkezik a tároló, és talán arra is ad egy tippet, hogyan futtassunk néhány npm szkriptet, amit a package.json-ban találtunk.

Ha minden a helyén van, akkor mindent megtettél annak érdekében, hogy ne rontsd el a kódbázist.

Élvezted az olvasást?

Tudassa velünk véleményét a Facebook oldal! Lenyűgözte az útmutatónk, és szeretné első kézből kipróbálni, milyen az integráció? Vegye fel velünk a kapcsolatot az alábbi űrlap segítségével!