Kirjautuminen

Haku

Tehtävät

Keskustelu: Projektit: Digiruokalista sovellukseen kehittäjiä?

Sivun loppuun

Mariapori [11.09.2022 18:07:04]

#

Hei,

Löytyisikö innokkaita C# ASP.NET Core osaajia?

Olen yksistään ylläpitänyt palvelua https://digiruokalista.com

Se on tehty .NET 6

Idea on yksinkertainen, sovelluksella näytetään ylläpidettäviä ravintoloiden ruokalistoja.

Sovelluksen lähdekoodi löytyy täältä:
https://github.com/Mariapori/Digiruokalista.com

Pyörittelen palvelua omalla palvelimella ja jokaisesta commitista automaatio julkaisee suoraan uuden version palvelimelle käytettäväksi.

Pull Requesteja vaan, kiitos.

carabia [12.09.2022 21:58:33]

#

laitoin linkkiin hiiri klik ja sain viiruxen ei kannata klik.

Metabolix [12.09.2022 23:44:48]

#

Onneksi carabialta saa aina hyvää ja asiallista palautetta. Mutta onhan tuon sivun ulkoasu aika pelottava tietokoneella, kun on niin monta leveää mutta matalaa elementtiä.

Mariapori [18.09.2022 19:53:07]

#

Joo, kiitoksia palautteesta. Itse en ole niin UI-puolta treenannut ja noiden on tarkoitus olla silmään pistäviä että ihmiset huomaa kyseisen disclaimerin :D

UI on enemmän suunnattu mobiilille.

Tilastojen mukaan yli 80% noin 1k kävijöitä per kuukausi käyttää mobiililla

walkout_ [21.09.2022 02:31:41]

#

Ihan hyvä saitti mutta ulkoasua pitäs vähän parannella.

walkout_ [21.09.2022 02:33:20]

#

Miten olet automatisoinut homman päivittämisen? Minulla GIT:stä pitää pull requestin jälkeen manuaalisesti päivittää sovellus Linux-komentorivillä.

groovyb [22.09.2022 13:16:00]

#

Nuo asennukset saa vaikka github actionsissa hoidettua, eikä tarvitse manuaalisesti tehdä.

walkout_ [23.09.2022 04:38:09]

#

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.

Metabolix [23.09.2022 08:24:27]

#

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.

walkout_ [23.09.2022 08:38:30]

#

Metabolix kirjoitti:

(23.09.2022 08:24:27): Voi walkout_. Esimerkiksi jos...

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ä.

muuskanuikku [23.09.2022 09:41:10]

#

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.

Grez [23.09.2022 10:15:53]

#

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.


Sivun alkuun

Vastaus

Muista lukea kirjoitusohjeet.
Tietoa sivustosta