Build, deploy

[Pepita73]

• [ ] - #30 - tárhely

Amennyire lehet, automatizáljuk a telepítést, élesítést.

• Nézzük meg, mit tud (ha tud) ebben segíteni a github
• Legyen legalább 1 ötlet arra, mit akarunk csinálni (írjuk le)
• Beszéljük meg, like stb
• Fejlesztés

[ghost]

Ha kell én szívesen viszem ezt a részét, a Travis jobban érdekel, mint a Drupal. A workflow-al kapcsolatban az jött le, hogy nem e szerint branch-elünk: https://nvie.com/posts/a-successful-git-branching-model/? hanem csak egy master van, aztán arra küldi mindenki a dolgait, amit localban lefejlesztett. A fenti branching model-nek lenne annyi előnye, hogy git hook-al lehet figyelni, hogy mikor változik a master, és elindítani olyankor automatikusan a build & deploy-t. Erre a workflow-ra talán azt lehetne kitalálni, hogy taggeljük a release-eket master-en: https://git-scm.com/book/en/v2/Git-Basics-Tagging , aztán ha új release van, akkor indítjuk el rá a deploy-t. Már nem emlékszem, hogy ahhoz, hogy a github valamit release-nek vegyen elég e feltaggelni ilyen semver-es taggel, vagy valami extra dolog is kell hozzá, de majd utánajárok. A github szerintem ennyit támogat: https://docs.travis-ci.com/user/languages/php/ Tesztelésre használtam már sokszor js-el. Amiben nem vagyok biztos, hogy privát repo-nál lesz e leaking, mert elvileg a travis veszi át a github-tól, és másolja le helybe, aztán indítja el a test scriptet az ottani másolaton. Szerintem csinálok egy külön repo-t, amin tudom tesztelni ezt az egészet.

[Pepita73]

Hát vigyed. :)

git hook-al lehet figyelni, hogy mikor változik a master

Szerintem az nem baj, ha meg kell nyomni a gombot kézzel... :) Ha már nem kézzel kell fájlokat másolni, bőven jók vagyunk.

[Pepita73]

lehet develop branch, cégnél is használom.

[ghost]

Nem muszáj a branching, megoldható így is. Lehet github + Travis-el deploy scriptet megadni: https://docs.travis-ci.com/user/deployment/script/ Én arra tippelnék, hogy ez minden push után lefut, ha lementek a tesztek. Ebbe esetleg beteszünk egy ellenőrzést, hogy van e új release, és csak akkor csinálunk depoy-t, ha ténylegesen van. Egyébként meg csak build és teszt fog menni minden commit-nál, feltéve, ha automatikusan tesztelünk. Várom a véleményeket arra az issue-ra #10 , illetve, hogy rábízzuk e a Travis-re, mint szolgáltatóra a kódunkat és a deploy-t, vagy indít valaki ilyen célra külön szervert. Ha az utóbbi lesz, akkor szükség van egy deploy felelősre. Elvileg docker-el fel lehet lőni helyben is egy Travis szervert https://andy-carter.com/blog/setting-up-travis-locally-with-docker-to-test-continuous-integration , aztán gondolom felveszi a deploy felelős gitignore-ba a deploy scriptet, és akkor az csak nála fog lefutni, a githubon meg csak a build és teszt. Persze nem muszáj automatizálni Travis-el, elég egy build.sh fájl is. Az automatizálás csak annyiban ad többet, hogy futtat egy ellenőrzést is előtte, tehát nem fordulhat elő, hogy elfelejtjük tesztelni a kódot élesítés előtt.

[ghost]

A deploy-al kapcsolatban kellene még info az éles szerverről. Leginkább azzal kapcsolatban, hogy hogyan tudok rácsatlakozni a scripttel, bemásolni a fájlokat, stb. ? Úgy sejtem, hogy a github-on lehet minden projektnek erre valami tárhelye, különben elég gázos lenne deploy scriptet megadni, mert benne kéne, hogy legyen publikusan, hogy milyen azonosítóval lépünk be a production szerverre. A b változat, hogy a github nem támogatja a deploy scripteket. Igazából akkor sincs gond, csak valakinek otthoni kell futtatni a release után a scriptet. Úgy sejtem, hogy két féle script lesz, az egyik csak a php kódot frissíti pl rsync-el, és elég egy karbantartás feliratot kitenni hozzá, a másik meg a függőségeket frissíti, és gondolom újraindítja a container-t hozzá. Esetleg valami útmutatás ezzel kapcsolatban? :D

[Pepita73]

A deploy-al kapcsolatban kellene még info az éles szerverről

Egyelőre nincs releváns info. Szó volt róla, hogy Dávidéknál, de ott probléma az ftp hozzáférés is, így felmerült, hogy más megoldást keresünk, de ha jól követem a dolgokat, megegyezés nem történt. Szerintem induljunk ki abból, hogy kezdetben egy shared hosting, aztán ha "kinőjük", akkor valami komolyabb. A jelenlegi infók alapján én Dotroll Plus csomagot javaslok. Ilyenem van is egy, tehát fejlesztés idejére még nem kell fizetni. Tippre ftp-ben gondolkodj. Az kb borítékolható, hogy indulásból élesben nem lesz Docker, tehát a deploy legenerálja a "cuccost", futtat tesztet, ha van, aztán fájl szintű másolást végez.

valakinek otthoni kell futtatni a release után a scriptet

Szerintem ezzel sincs gond, csak meg kell(ene) előzze, hogy feláll a szerkesztői - fejlesztő csapat (ez sincs még tisztázva). Ki, mikor, honnan tudja futtatni - ennyit kell megoldani.

az egyik csak a php kódot frissíti pl rsync-el

Ha jól vettem ki, egyelőre az a cél, hogy ez elegendő legyen, ne kelljen más. Ha a jövőben fog kelleni más is, az szerintem db schema upgrade lehet. (De lehet, hogy ezt nem jól gondolom, @Endyl , @hunsly ?)

a másik meg a függőségeket frissíti, és gondolom újraindítja a container-t hozzá

Élesben szerintem nem lesz container. A dev container-nek (2-nek) kell olyannak lennie, mint az éles szerver.

Elég ennyi útmutatás?

[Endyl]

Kérdés, hogy lesz-e shell hozzáférésünk az éles rendszerhez. Ha igen, akkor drush-sal meg lehetne oldani a karbantartási mód ki-/bekapcsolását, schema/config frissítést, stb. Egyébként a webes felületen is kellene matatni a kód szinkronizálásán túl.

[ghost]

Én benne vagyok a shared hosting-ban, ha szétosztjuk a költségeket egymás között. Az FTP-hez van git-ftp, ha sync-elni akarjuk a kódot. https://github.com/git-ftp/git-ftp Ami nem vili nekem, hogy kell e rollback, arra az esetre, ha valami balul sülne el, illetve, hogy mekkora hangsúlyt helyezünk a biztonságra. Ha pl titkosítatlan FTP-vel töltünk fel, akkor sync helyett jobb lenne a teljes kódot átküldeni egy digitálisan aláírt titkosított csomagban, aztán a szerveren ellenőrizni és kicsomagolni. Nem teljesen világos, hogy hogyan fogunk release-elni. Jól értem, hogy úgy lesz, hogy telepítitek dev gépen a docker container-be a Drupal-t, aztán abban összekattintotok valamit, utána pedig azt kellene feltenni a szerverre? Hát nem igazán tudom, hogy ez hogyan oldható meg, mert amit összekattintotok az inkább schema és adatbázis változással fog járni, esetleg létrejön néhány statikus fájl, kód meg max Drupal extension telepítéskor fog változni, ha tényleg alap Drupal-t használunk csak. Persze lehet, hogy én gondolom rosszul, nem értek a Drupal-hoz. Mindenesetre ha így van, akkor gondolom a Drush-al lehet megbízhatóan szinkronizálni ezeket a változásokat, és nem valami külső scripttel, és akkor viszont nekem nem is kell semmit írnom.

[Endyl]

Drupallal kapcsolatban szerintem ez a két "frissítési" feladat lenne eleinte (vagy ezeknek a keveréke):

1. Drupal vagy modul frissítés:
   1. dev-en composer update + kipróbálni a hozzátartozó db update-et
   2. prod-on karbantartási mód be, frissített forrásokat feltenni, lefuttatni a db update-et; ha hiba van, akkor rollback, egyébként karbantartási mód ki
2. Beállítások frissítése (1 vagy 2):
   1. dev-en config sync export
   2. prod-on karbantartási mód be, config sync import, hiba esetén rollback, egyébként karbantartási mód ki

Ezek egyszerűbbek, ha tudunk drush-t futtatni az éles szerveren.

[ghost]

Először akkor szerintem jussunk el oda, hogy manuálisan megy a deploy, aztán utána automatizálom.

[ghost]

Elvileg van rá mód, hogy a github-ról közvetlenül töltse le az új release-t a szerver, tehát nem kell FTP-vel szórakozni, hanem listázni lehet a release-eket, megnézni, hogy van e újabb a mostani kódnál, aztán lerántani curl-el az új kódot. https://developer.github.com/v3/repos/releases/ A dolognak annyi szépséghibája van, hogy a teljes kódot rántja le és nem sync-el. Nem tudom ez mekkora baj, de a deploy-nál a kód frissítést én ebbe az irányba vinném. Ha van elég önbizalmunk hozzá, akkor akár az is megoldható, hogy időzített legyen a kód frissítés, és betegye éjszakára.

Szerintem ennél tovább nem tudom vinni a dolgot, amíg nincs meg a tárhelyünk vagy legalább valami hozzá hasonló, és nem tudom, hogy pontosan hogyan megy kézzel a frissítés. Gondolom lesz olyan része, amit a Drupal-ban kell elindítani, és amire nincs API. Na az a része lesz, ami nem triviális és gondolom eltörik majd Drupal frissítésekkor.

[Pepita73]

Deploy-hoz az eddigi környezeti változók nevei:

MYSQL_DATABASE MYSQL_HOSTNAME MYSQL_PASSWORD MYSQL_PORT MYSQL_USER

Valószínű lesz még a hash salt, de szerintem minden ilyesmi a .env-be fog kerülni.