A cegnel ugy mukodik a fejlesztes, hogy van a dev repo, az lokalisan a gepemen (egyedul fejlesztek), van egy teszt, egy oktato es egy eles. Devrol pusholok tesztre, az post-receive checkoutol automatikusan, onnan oktatora, ott ugyanez, onnan pedig az elesre. Ott viszont nem checkoutol automatikusan, mert a site-frissites csak ejjel mehet ceges policy szerint, hogy tuti ne legyen fennakadas. Ekkor viszont mar nyilvan nem vagyok munkaban, szoval egy crontab bejegyzessel oldottam meg a checkoutot. Eddig rendben van, viszont itt jon a problema:
Teszten es oktaton tudom frissiteni az adatbazist checkout utan (alter table, create table, etc.), viszont az elesen nem. Pontosabban de, de akkor este 10-kor otthonrol fel kell masznom es ezzel kell foglalkoznom, ami nem biztos, hogy jo, mert megesik, hogy esetleg szeretnek valami mast csinalni szabadidomben, 10-kor pedig eselyes, hogy mondjuk egy buliban vagyok, amikor nem szeretnek ittas allapotban hazarohanni adatbazist frissiteni.
Szoval erre kellene valami megoldas. Ott tartok elmeletben, hogy csinalok egy filet, pl. sqlupdate.sql, amibe minden commit elott beleirom, mi valtozik, post-commit hookban pedig letorlom az egeszet, majd post-checkoutnal csinalok egy mysql < sqlupdate.sql.
Eddig ez viszonylag mukodokepesnek tunik, viszont van egy olyan problemam, hogy ha pl. csinalok egy olyat, hogy 12 commit utan pusholom ki elesre, mert tesztrol visszajon, hogy bugos, azokat kell fixelgetnem. A 12 commitbol lesz mondjuk 3-ban SQL script, tobbiben nem, akkor elvesztettem minimum kettot, ha az utolsoban nem volt, akkor mindharmat. Ezzel mit tudnek kezdeni? :) Vagy alapbol rossz a hozzaallasom esetleg?
- 1639 megtekintés
Hozzászólások
Nézd meg, hogyan működik ez Rails-en, az egy nagyon elegáns megoldás. (Rails database migrations)
Egyébként meg úgy szokás (Magento pl), hogy van egy verziószáma minden modulnak és ha frissül a kód, akkor a régi és frissített között lévő update.sql parancsokat szépen sorban lefuttatja. Magento-ban mondjuk akkor, amikor észleli, hogy valaminek a verziószáma nem egyezik az adatbázisban lévővel.
- A hozzászóláshoz be kell jelentkezni
Szoval akkor nem commitonkent ures filehoz nyulok hozza, hanem van egy updates.sql-em, amiben valamilyen delimiterrel vannak elvalasztva a verziok, ugye? Hol tartom szamon, hogy melyik a legfrissebb futtatott verzio?
- A hozzászóláshoz be kell jelentkezni
Látom a Magento-s példánál maradtunk. Ők egy adatbázistáblában tárolják a modulok neveit és a hozzá tartozó verziószámot. A modul tudja magáról, hogy éppen milyen verziószámmal fut (pl egy getVersion() method vagy konstans) A legközelebbi futásnál ha a kettő eltér, akkor végigcsinálja az update-t.
Rails esetén az egészet az ORM végzi, de lényegében ugyanez, csak nem kell SQL parancsokat írni, elég a migrációkat megírni, ez esetben pedig a visszalépés is megoldott korábbi verzióra.
De akár nézhetjük a Drupal-t is, ott is meg van oldva valahogy, szintén van egy tábla, ahol revíziókról van információ, ha lépünk egyet előre, végigcsinálja az update_1234 - update_1235 funkciókat. Ott kézzel kell futtatni az update.php-t.
Nem értem egyébként, hogy ennek mi köze a git-hez, gondolom valami egyedi deploy van.
- A hozzászóláshoz be kell jelentkezni
Githez igazabol csak annyi koze van, hogy git post-receivenek kell futtatnia a dolgot, es azt szeretnem, ha en egy fileba beleirnam az altereket es azokat lefuttatna szepen okosan, dinamikusan. Azt hiszem, kezdem erteni, mirol van szo, mindjart megvalositom :D
- A hozzászóláshoz be kell jelentkezni
Viszont meg van a kovetkezo problema... ha tobb fejlesztovel dolgozok, hogyan irunk bele az SQL fileba? Mindenki irkal bele, ahogy gondolja, aztan aki kesobb pushol, megoldja a conflictot es kesz?
- A hozzászóláshoz be kell jelentkezni
Igen. De ha ketten írnak oda, ott már mást is meg kell oldaniuk, nyilván ha a db változik, az azt használó dolgoknak is változnia kell. De hogyan fordul elő, hogy egy modulon egyszerre többen is dolgoznak?
- A hozzászóláshoz be kell jelentkezni
Nem feltetlen.
A rails pl ugy csinalja, hogy minden semamodositas kulon fajl a db/migration/ mappaban, az egyes fajloknak egy szamkoddal kezdodo neve van, es ezt az egyedi szamkodot (a fajl letrehozasanak ideje amugy) tarolja egy egysoros, egyoszlopos tablaban. Innentol tudja, hogy pontosan melyik verziotol kell rafuttatni az adott db-re az updateket.
A railsnel meg annyi extra van, hogy a modositasok - ha lehet -mindig ketiranyuak, van egy up es egy down ag is, az elso a tenyleges modositasert felel, az utobbi pedig azt csinalja vissza (pl ADD COLUMN / REMOVE COLUMN). Nyilvan nem minden esetben teljesen reverzibilis, de a sema szintjen mindenkeppen az.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Ne érts félre, nem akarlak sem korholni, sem lenézni az erőfeszítéseidet, amit abba a rendszerbe bele fektettél!
Viszont én ezt gyökeresen másként csinálnám. Mivel az adatbázis alterelés (szerintem) nem egy olyan folyamat amit egy buta automatikára rá lehet bízni (megszalad egy update, vagy delete, kimarad egy where és ott a baj). Ezt én eddig így oldottam meg és így is fogom, mert egy igen megbízható rendszernek érzem, tapasztaltam.
A dev gép (jelen esetben a te géped) csinálhatja az élesítést és a db update -et a post-receive scriptel, de nézze meg, hogy az utolsó pushban van-e bd-update-.sql nevű file. Ha igen futtassa le azt, ami kezdődjön, úgy, hogy egy pl.: version_update nevű táblában az egy darab oszlopot pl.: current_version (unique key) beállítja (insert into version_update(current_version) value('1.0.107.build6');) ha van ilyen az insert elszál és a push sikertelen (hisz elrontottunk valamit).
A teszt oktatói és prod gépekre pedig egy ügyes script (ant build.xml) tegye ki a kódot, úgy hogy előbb exportálja ki a forrást, majd végezze el a szükséges buildelést (osztálylista generálás, css, js strip, fordítás stb.), majd egy verzíószám nevű mappába (/var/www/build2063/) rsync-elje ki az elkészült kódot. Ezután egy symlink segítségével tegyen ki egy sorry pageet (mint a twitter fail whale, vagy a google 404) ha kifogytak az aktív szálak akkor véggezze el az adatbázis update -et majd a sorry pageről állítsa át a symlinket az új verzióra.
Ez így biztonságos, nem lesznek tranziens hibák az inkonzisztens adatbázis, vagy kód miatt és látogatót sem veszít az oldal.
Ezzel a módszerrel, bármikor, napközben is elvégezhető a verzió váltás
----
올드보이
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
Ez azert nem jo, mert az adminfeluletet hasznalniuk kell, amig nyitva vannak a szalonok. Ha az nem tolt be, akkor nem csak online visitorrol van szo, hanem kozvetlen fizeto vendegeket is meg kell varakoztatni, szoval a ceg ragaszkodik az este 7 utani updatehez.
- A hozzászóláshoz be kell jelentkezni
Nem érzem, hogy ez teljes mértékig ellent mondana annak amiről én beszélek, lévén a release ablak lehetne előre egyeztetett időpontban (exhas: kedd 19:00, ezen a napon mondjuk igazodik a munkarendetek ehhez, persze nem én vagyok a PM)
Ha ez egy kereskedelmi rendszer én annál inkább óckodnék az autómatika "inteligenciájától". Másik dolog: az általam vázolt rendszer egy cirka 25000 soros PHP projektet kb másfél tucat serveren képes volt cirka 1,5 perc alatt élesíteni. probléma mentesen.
Ha gondolod tudok küldeni privátban build.xml -t (apache ant hoz)
----
올드보이
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni