Bevezetés: CI/CD, Cloud, DevOps

A mai téma a Vercel platform lesz ami lehetőséget biztosít arra hogy gyorsan deploy-oljuk frontend alkalmazásunkat. Az oldal biztosítja a gyors telepítést, automatikus skálázást, és nem igényel felügyeletet. Összegezve egy olyan cloud platform, ami automatikusan végigviszi a deploy folyamatot a tesztelésen át egészen a kód fordításáig, majd percek alatt egy teljesen beállított webalkalmazást kapunk. Ezzel gyakorlatilag megvalósítunk egy CI/CD folyamatot. Ezt a szoftvertechnológia témaköréből ismerhetjük, de röviden összefoglalom, hogy miről szól: agilis módon haladunk előre a fejlesztés során, a cél pedig az, hogy mindig egy működő szoftververziót szállítsunk le a megrendelőnek. Az agilitás velejárója, hogy kis lépésekben haladunk a fejlesztés során, emiatt is kisebb eséllyel hibázunk, sokszor commit-olunk és push-olunk git-re, amit utána jó rögtön eredményként látni az éles alkalmazásunkban. Ebben segít ez a CI/CD folyamat, de mikből is áll ez? Mit rejtenek a rövidítések?

• CI: Continuous Integration, vagyis folyamatos integrációt hajtunk végre: a kis fejlesztési részek fő fejlesztési ágba (master/main) történő beemelésével.
• CD: ennek kettős jelentése van:
1. Continuous Delivery, vagyis folyamatos leszállítást hajtunk végre: amit a folyamatos integráció során lefejlesztettünk (sok kisebb commit) és egyesítettük a fő fejlesztési ággal, azt az ágat elérhetővé tesszük az ügyfél számára úgy, hogy az egy megbízható szoftvermegoldás is lesz, mivel az automatikus tesztelési folyamatosan is átesett az alkalmazás legfrissebb verziója a "leszállítás" során. Viszont itt még a "leszállítás", vagyis az elérhetővé tétel manuálisan történik meg, tehát a programozó (csapat) dönti el, hogy mikor is teszi azt elérhetővé. A Delivery-vel tehát azt érhetik el, hogy "leszállítható, kihelyezhető" állapotúra csinálták az alkalmazást, de hogy mikor helyezik ki (deploy), azt ők döntik el és csinálják manuálisan. A CD rövidítésben gyakrabban gondolunk a "Delivery"-re, mint a ...
2. Continuous Deployment, vagyis folyamatos "leszállítást és kitelepítést" jelent, ami ugyanazt foglalja magába, mint a Continuous Delivery, viszont azon felül itt már maga a "leszállítás", "kihelyezés" az éles helyre is automatikusan történik meg.
   

Ez a terület nagyban kötődik a DevOps témaköréhez, amelyben a fejlesztési (developments) és üzemeltetési (operations) feladatok összefonódnak. A felhőszolgáltatások alkalmazásánál ez már alapvető elvárás, hogy (ha egyénileg dolgozunk, akkor) "működjünk" DevOps fejlesztőként és üzemeltetési mérnökként együttesen, illetve ha a cégnél külön csapatok vannak a fejlesztésre és az üzemeltetésre, akkor ők sokkal jobban működjenek együtt, mint korábban. Ez a DevOps gondolkodásmód tehát egy szemléletváltással jár együtt.

De nézzük is meg, hogyan működik ez a valóságban.

Első lépések

Látogassunk el a https://vercel.com/signup oldalra, majd használjuk GitHub fiókunkat a regisztrációhoz. Ezzel egy lépést ki is pipálunk, hisz szükséges lesz GitHub csatolása a profilhoz, azonban kényelmesebb már ezzel regisztrálni.

Ha ezzel megvagyunk, akkor ezt kell látnunk, itt pedig szükséges engedélyt adni a vercel számára, hogy hozzáférjen repository-ainkhoz. Ezt a bal oldalt található lenyíló menüben tudjuk megtenni:

Deployment

Ha megvolt a GitHub összekapcsolása a profillal, akkor kilistázásra kerülnek az eddig elkészített repository-aink. Keressük meg a React projektünket, majd kattintsunk az Import gombra a projektünk neve mellett. 

Itt a Deployment és a Build folyamattal kapcsolatos beállításokat tudjuk állítani, azonban a vercel felismeri, hogy create-react-app -ként hoztuk létre az alkalmazásunkat, így előre megcsinál nekünk mindent. Ha kíváncsiak vagyunk, megnézhetjük a "Build and Output Settings" részt, amelyben a már ismerős parancsok láthatóak ahhoz (npm run build és npm install), hogy "leszállításra és kihelyezésre" kész állapotba kerüljön majd az alkalmazásunk. Kattintsunk a Deploy gombra. Elindul a folyamat:

Ha elkészült a deployment, akkor ez az oldal részlet fogad minket, ahol kattintsunk rá a Continue to Dashboard gombra:

Majd ilyen oldal fog minket fogadni.

A Visit gomb át is fog minket navigálni a deploy-olt alkalmazásra, azonban jelenleg a repository default branch-e lesz a Production Build forrása lesz. Nyissuk is meg a Visit gombbal, és hagyjuk megnyitva, később még jól fog jönni.

Deployment folyamat - Production Branch átállítása

Vercel nagyon jól kezeli a repository-ban történt változásokat, minden ágon történt változás után automatikusan elindul egy deployment. Azonban fontos azt megjegyezni, hogy ez nem fogja felülírni a production deploy-t. Alapesetben elérhető a deploy-olt alkalmazásunk a Visit gombbal, de kapunk egy állandó URL-t is, ami https://<repositry_name>-<github_name>.vercel.app/ címen elérhető (természetesen a megfelelő részeket kicserélve benne és figyelve a köztük lévő kötőjel fontosságára). Ez az URL mindig a Production Branch build-jére fog mutatni, emellett minden ágon történt változtatás megtekinthető, amik kapnak egy-egy külön domain-t is. De nézzük is meg, hogyan tudjuk követni ezeket. A Deployment fülre kattintva kilistázva láthatjuk az eddig történt változásokból adódó deploy-t.

A teszt kedvéért egy módosítást hajtottam végre a blog-2 ágon:

1. VSCode-ban bal alul tudunk az ág nevére rákattintani és ágat váltani, válasszuk ki a blog-2 nevűt.
2. Írjuk át a fejléc szövegét Weather Project" - Vercel update" (az idézőjeles résszel bővítettem) az src/components/navbar/Navbar.js fájlban és mentsük el.
   
3. Következhet a git add . majd git commit -m "vercel commit tst" és git push
   

Így automatikusan elindul egy build-deploy folyamat a háttérben. Olvasható is a Vercel oldalon, hogy ez egy "Preview" szöveg a build neve alatt, szóval az adott változtatást tudjuk vele megtekinteni. Emellett láthatjuk az állapotát, mennyi idő alatt készült el, és melyik ág melyik commit-ja került deploy-olásra.

Kattintsunk is rá, az elkészült build-re, majd hasonló oldal fogad, mint amikor először deploy-oltuk alkalmazásunkat.

Ha rákattintunk a Visit gombra, megnyílik az adott commit-ból készült build. Látható, hogy ha össze hasonlítjuk a Production Branch-es build-del, ténylegesen csak a blog-2 ág változása látható az alsó ablakban. 

De, hogy teljesen lássuk, mit is tud a Vercel, próbáljunk ki még valamit! Ugyanerre a branch-re készítsük még egy változtatást, és menjünk vissza a Deployment oldalra. Itt láthatjuk is hogy másodpercek alatt el is készült a Preview build.

Azt már tudjuk, hogy a production build elérhető a repository név és a GitHub felhasználó nevünkkel (https://<repositry_name>-<github_name>.vercel.app/) , viszont egy adott branch-hez is tartozik domain: https://<repositry_name>-<branch_name>-<github_name>.vercel.app/ . Az én esetemben ez: https://react-weather-app-git-blog-2-zsoltgombocz.vercel.app/

Így az adott ághoz tartozó domain mindig a legfrissebb változtatást fogja tartalmazni. 

De a legtöbb esetben elég a Production branch-ből létrejött oldalt használni. Még nézzük meg, hogy mi van akkor, ha viszont nem a default branch-ről szeretnénk, hogy production build készüljön...?

Ha a Settings tab-ra kattintunk, akkor a bal oldali almenüben a Git kiválasztása utána Production Branch nevű kártyában láthatjuk, hogy jelenleg a master ágról deploy-olunk. Ez azt jelenti, hogy automatikusan ez lesz a production build és az alkalmazásunk URL-jéről is ezt fogjuk elérni, továbbá minden beérkezett push után el fog indulni a deployment folyamat. Írjuk át a teszt kedvért a master-t egy létező ágra, az én esetemben blog-2 lesz, majd Save. 

A mentés sikerességét jobb alul egy felvillanó üzenet fogja megerősíteni. Most menjünk át a Overview (most már Project) fülre: feltűnhet alul egy kis szöveges doboz, ami jelzi, hogy ahhoz, hogy a production branch URL-je az új ág változásait mutassa, push-oljunk fel rá valamit. 

Nem muszáj most push-olnunk változtatást, de kinevezhetünk egy adott deployment-et, hogy legyen a Production Build-ünk. Ez mondható átmeneti állapotnak is, hiszen bármilyen push elindít egy build-et és azzal felül lesz írva. De nézzük is meg, hogyan tudjuk az utolsó blog-2 ágból létrejött build-et kinevezni Production Build-nek. Az adott deployment sor jobb szélén kattintsunk a három pöttyre és a lenyíló listából válasszuk a Promote to Production menüpontot (majd erősítsük is meg az igényünket).

Ez annyit fog jelenteni, hogy a a "fő" URL-ünkkel érjük majd el ezt. (https://<repositry_name>-<github_name>.vercel.app/)

Navigáljuk vissza a Deployments tab-re, és láthatjuk, hogy a blog-2 ág utolsó push-olt állapota (commit-je) van érvényben a Production Build-ünkön.

Összegezzünk

A Vercel egy nagyon gyors és kifejezetten felhasználóbarát oldal. Ezen a blogbejegyzésen és az itt bemutatott lehetőségeken túl számos hasznos funkciója van, viszont talán még ezek az ismeretek is plusz dolgok voltak, amiket talán sokan nem is használtak még a gyakorlatban.

Legtöbbször csak szeretnénk egy adott ágat deploy-olni, hogy meg tudjuk mutatni másnak (esetleg az ügyfélnek) a projektünket és lehessen tesztelni, amihez ez a blogbejegyzés tökéletes segítséget nyújt. A következő részben az input mezők kezelésével fogunk továbbhaladni, majd a megszerzett tudással bővítjük oldalunkat. Ha esetleg valakinek kérdése, meglátása, ötlete van a bejegyzéssel kapcsolatban, itt tud kapcsolatba lépni velünk: Kapcsolat

A bejegyzést lektorálta, a programkódokat kipróbálta: Gludovátz Attila (az ő Github projektje itt érhető el).