(Moderaattori siirsi Digiruokalista-projektista.)
Mariapori kirjoitti:
Pyörittelen palvelua omalla palvelimella ja jokaisesta (GitHubin) commitista automaatio julkaisee suoraan uuden version palvelimelle käytettäväksi.
Miten olet automatisoinut homman päivittämisen? Minulla GIT:stä pitää pull requestin jälkeen manuaalisesti päivittää sovellus Linux-komentorivillä.
Nuo asennukset saa vaikka github actionsissa hoidettua, eikä tarvitse manuaalisesti tehdä.
groovyb kirjoitti:
Nuo asennukset saa vaikka github actionsissa hoidettua, eikä tarvitse manuaalisesti tehdä.
Hyvä tietää... mutta ihmettelen silti kuka tekee VPS-päässä siltikin git pull -komennon sitten.
Voi walkout_.
Esimerkiksi jos vain haluat käynnistää käsin 15 minuutin välein automaattisen skriptin, voit laittaa sen screeniin:
screen watch -p -n $((15 * 60)) git pull
Tai voit tehdä siitä palvelimelle ajatetun tehtävän (ennen crontab, nykyisemmin systemd.timer).
Ja sitten se oikea ratkaisu tähän tilanteeseen, kuten groovyb mainitsi, eli GitHubista voi tilata palvelimelle ilmoituksen (HTTP-pyynnön) erilaisista muutoksista (issue, commit, release jne.), katso GitHub Docs: About webhooks. Omalla palvelimella voi sitten tämän tullessa ajaa päivitykset yksinkertaisimmillaan ihan vaikka PHP-skriptin kautta. Eli tyyliin ilmoitusosoitteeksi https://example.com/SECRET-ADMIN-PAGES/github-webhook-pull.php, jota GitHub kutsuu automaattisesti, ja kyseisessä skriptissä ajetaan git pull.
Ajastettu taustapalvelu voi olla siinä mielessä parempi, että muutokset tulisivat voimaan esimerkiksi yöllä, ettei kenenkään käyttäjäkokemus hajoa, kun sivu muuttuu kesken istunnon.
Tämä on tärkeää ttietoa minulle.. vaikka osasin arvata, että cronilla pistäs ajaa. Mutta minulla kehitystyössä on aina release date ja sovellusta kehitetään salaisessa osoitteessa sitä ennen ja vasta kun kaikki on valmista tästä salaisesta uudesta alidomanista pistetään release julkisesksi ja asiakkaiden päässä kaikki päivityy automaatisesti ja asiakkat saa uuden version käöyttöön nappia painamalla ja voivat nappia painalla palta edellisiin versioihin jos uudet versit eivät miellytä.
Koodin deplaaminen tuotantoon automaattisesti on kyllä hullun hommaa.
Aika usein isomman muutoksen jälkeen tarvitsee tehdä tietokantaan muutoksia. Nämä voi karkeasti jakaa kahteen kategoriaan sen perusteella, että tarvitseeko muutoksia tehdä pelkästään tietokannan skeemaan vai myös tietokantaan tallennettuun dataan.
Vaikka migraatiot itsessään voikin automatisoida, niin aina sieltä tuotantokannasta voi löytyä sellainen kompastuskivi, jota ei testikannan datan perusteella osannut huomioida.
Ihan töissäkin on käynyt välillä niin, että kun kiireessä laittaa illan viimeisenä asiana uutta koodia masteriin, sitten se onkin onnistuneesta testiajosta huolimatta vetänyt kaikki demoympäristöt solmuun.
PHP-koodia voi sentään paperilla vain dumpata levylle ja webbisovellus maagisesti päivittyy kuin itsestään. Esimerkiksi Node.js-sovellus pitää bootata ja se voi aiheuttaa yllättäviä yhteysongelmia käyttäjille.
Toisaalta modernit PHP-sovellusalustat turvautuvat aika paljolti monitasoisiin välimuisteihin ja sovellus voi hajota siihen, kun vanhat välimuisteissa olevat palikat eivät olekaan yhteensopivia uuden koodin kanssa.
Mitä enemmän välivaiheita koodin deplaamiseen tulee, niin sitä hitaammaksi deplaaminen myös muuttuu. Koko tämän ajan sovellus / nettisivusto voi olla täysin rikki ja sekoilla ihan ihmeellisillä tavoilla.
muuskanuikku kirjoitti:
Koodin deplaaminen tuotantoon automaattisesti on kyllä hullun hommaa.
Mielestäni koodin deplaaminen tuotantoon automaattisesti on äärimmäisen viisasta. Täytyy vaan olla riittävät testit tehtynä.
Tietenkin automaattinen päivitys edellyttää että järjestelmä on sellainen että se toimii. Automaattisen päivityksen täytyy tehdä samat asiat kuin manuaalinen päivityskin tekisi. Esim. jos järjestelmä "voi hajota siihen, kun vanhat välimuisteissa olevat palikat eivät olekaan yhteensopivia uuden koodin kanssa", niin sitten automaattiseen päivitykseen täytyy ottaa mukaan välimuistien tyhjentäminen.
Itse asiassa tuollaisessa tapauksessa pitäisin automaattista päivityksen etuja jopa keskimääräistä suurempina, koska jos manuaalisesti täytyy tehdä 10 asiaa niin joku niistä on helppo unohtaa.
lainaus:
Vaikka migraatiot itsessään voikin automatisoida, niin aina sieltä tuotantokannasta voi löytyä sellainen kompastuskivi, jota ei testikannan datan perusteella osannut huomioida.
Eikö se testaus kannattaisi tehdä tuotantokannan kopiolla, jos tuollaisia riskejä on? Toki jos tuotantokantoja on useinta niin sitten se ehkä täytyisi tehdä niistä jokaisella. Pitäisin kuitenkin tuota huomattavasti parempana kuin että vika tulee esille vasta tuotannossa ja sitten kiireellä aletaan korjata tuotannon manuaalisen päivittämisen rikottua systeemin.
Klassinen ohjelmointiputkan ketju.
1. OP kysyy asiasta Y
2. grez/metabolix/walkout/groovyb/lautapelimestari saapuu derailaamaan keskustelua tokassa tai kolmannessa viestissä
3. derailattua keskustelua jatketaan usean viestin verran. nettikikkelit kasvavat
4. minä saavun tänne pätemään
5. joku kakkosstepin henkilö lätisee jotain
6. ketju vanhenee ja OP:sta ei kuulla enää koskaan
Ongelma ratkaistu: Mod. lohkaisi uuden aiheen kohdasta 2!
walkout_ kirjoitti:
Miten olet automatisoinut homman päivittämisen?
Mulla on tosiaan github action ja oma github runner palvelimella, kun commit tulee github action triggeröityy ja artifact vedetään rsyncilla tuotantoon ja komennan linuxilla systemd serviceä joka sitten pyöräyttää softani uudelleen käyntiin.
Tässä minun automaatio putki
https://github.com/Mariapori/Digiruokalista.com/
Eli kuten huomaatte se on self-hosted runner.
noutti kirjoitti:
(29.09.2022 20:59:36): Klassinen ohjelmointiputkan ketju. ...
Sori mutta en saa minkäänlaisia ilmoituksia että minun ketjuihini on edes vastattu..
Ajattelin että täältä tulee spostilla viestiä jos olis jotain asiaa, mut ei.
Grez kirjoitti:
(23.09.2022 10:15:53): ”– –” Mielestäni koodin deplaaminen tuotantoon...
Juuri tämä, kun tälläinen putki tuotantoon on tehty, koodari voi keskittyä siihen koodamiseen ja koodin testaamiseen.
Tottakai testaan kaiken aina lokaalisti ennenkuni pusken versiohallintaan (jolloin automaatio triggeröityy) minulla on käytössä sqlite kanta joten skenaarioiden testaus on äärimmäisen helppoa.
Ja minulla on samalla vielä rollback systeemi et jos jokin ei onnistu niin palataan vanhaan, mutta yleensä kaikki menee nappiin jos testaa kunnolla.
walkout_ kirjoitti:
(23.09.2022 08:38:30): Tämä on tärkeää ttietoa minulle.. vaikka osasin...
Ei tarvitse croneja, github runner self-hostattuna on todella kätevä.
Olen tehnyt softastani systemd servicen jolla nostan aina softan pystyyn ja laitan paussille.
Itse te perkele katoatte. 😁
Mariapori kirjoitti:
Itse te perkele katoatte. 😁
?
groovyb kirjoitti:
Mariapori kirjoitti:
Itse te perkele katoatte. 😁
?
Viittasin tuohon noutti:n tapahtumaketjuun.
noutti kirjoitti:
1. OP kysyy asiasta Y
2.grez/metabolix/walkout/groovyb/lautapelimestari saapuu derailaamaan keskustelua tokassa tai kolmannessa viestissä
3. derailattua keskustelua jatketaan usean viestin verran. nettikikkelit kasvavat
4. minä saavun tänne pätemään
5. joku kakkosstepin henkilö lätisee jotain
6. ketju vanhenee ja OP:sta ei kuulla enää koskaan
No vastaan AP:n kysymykseen. Käytetään firmoissa, joissa työskentelen käytännössä aina AWS, Azure tai GCloudia. Jokaisesta näistä saa putkituksen Githubiin, joka triggeröityy oikean branchin päivittyessä. Docker osaa ajaa testit ja kun ne on ajettu automaattinen deploymentti kyseiseen instanssiin.
Jos ei jaksa itse vääntää devopsia niin GCloudista saa muistaakseni edelleen 300e krediittejä per kk. Sillä saa muutaman tovin buildata ja hostata sitten sivustoa cloud runissa tai app enginessä. Tietokannat ovat ne, joista se raha otetaan. Kannattaa konffata ne tarkkaan, koska UX on tarkoituksenmukaisesti sekava.
Itse olen käyttänyt tässö tosiaan github actioneita ja töissä taas TeamCityä
Aihe on jo aika vanha, joten et voi enää vastata siihen.