localhost - éles weboldal közti szinkronizálás

Szotyi képe

Sziasztok!

Általában localhoston fejlesztek weboldalakat kisebb cégeknek. Ami ha 'készen van', akkor kiteszem a netre egy webszerverre.
- adatbázis dump
- fájlok és adatbázis FTP-vel felmásolása
- adatbázis import

Megmutatom az ügyfélnek, s ha elöbb-utóbb kell valamit még igazítani, akkor ismét localhost, majd jöhet az előző 3 lépés.

Addig már eljutottam, hogy 2 drush és egy rsync paranccsal ez megvan. Tehát localról webszerverre kivinni az adatokat.

De tudom, hogy ez a módszer nem igazán hatékony/jó/elegáns.

Többek közt azért sem, mert ha az ügyfél visz fel tartalmat (képet, szöveget), akkor az már nem fog megegyezni az én localhostomon tárolttal.

Ti ezt hogyan csináljátok a gyakorlatban? Hogy megy ez például ott, ahol többen dolgoznak egy projekten?

Szeretném használni, megtanulni a git-et és a featurest is. Gondolom, hogy ezek kellenek hozzá. Erre tudtok iránymutatást adni?

Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
Drupal verzió: 
Fórum: 
szantog képe

Zömében így: http://szantogabor.com/cimkek/git
NG-nél is van sok okosság: http://nevergone.hu/hu/cimkek/git

0
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.

Szotyi képe

Köszönöm a linkeket. 1 napot csak googlizással, olvasással töltöttem.
Nincs mese: meg kell tanulnom a git kezelését. :)

A helyi gépemen be kell állítanom a dolgokat.
A munkakönyvtárat, a git-et.
Valamint a távoli webszerveren is.

S a git parancsokkal lehet szinkonizálni valahogy a fájlokat.
Azt látom, hogy annak aki programozgat php-ben, elég hasznos.

De drupal esetében, - ahol mondjuk modulokat próbálgatunk ki, telepítünk, állítgatunk, törlünk - hogy van ez?
Itt is vissza tudunk állni előző verzióra?
Hiszen itt azért van ugye az adatbázis is. Azt is tudjuk verziókezelni?

0
0

Péter

pp képe

Első körben el kell döntened, hogy mi az amit szeretnél szinkronizálni a fejlesztői rendszerről az élesre.

Azután fel kell dolgoznod egy rossz hírt:

Nincs adatbázis tartalomra verzió kezelés. (az adatbázis sémára vannak kezdeményezések, de az adatokra nincsenek)

Ebből következik, hogy minden olyan adatot, amit verziókezelés alá akarsz tenni, ki kell tenned kódba. A views, rules, tartalomtípusok, valamint minden olyan aminek van mashine-name-e(általad megadott név), és amibe a felhasználó nem nyúlhat bele, könnyedén kitehetőek. (de pl. ha engeded, hogy a views-t módosítsa, vagy új rule-okat adjon hozzá, vagy belepiszkáljon a tartalom típusokba, akkor gondban leszel)

Azok az elemek, amiknek generált azonosítójuk van (tartalmak, menük, kategóriák stb.) azok mind, mind csak körülményesen tehetőek ki. Általános megoldás, hogy valahogyan generálnak neki egy egyedi azonosítót, ami általában pont attól nem függ amitől szeretnéd, és pont attól függ amitől nem szeretnéd. (mert a készítők aktuális workflow-jába úgy illeszkedett bele.) A másik véglet, amikor annyira általánosra csinálják meg, hogy visszavezettük a problémát az eredetire, mégpedig, hogy nem a felhasználó adja meg az egyedi azonosítót.

Fentiek igazak a nyolcas konfiguráció managemant-re is.

Ilyenkor vagy együtt élsz ezekkel a problémákkal, vagy programozol. (sokat, tesztelsz, programozol)

Kezdetben javaslom a Features és Strongarm modulokat felrakni.

2011-ben többek között erről beszéltem a Drupal Hétvégén: http://videotorium.hu/hu/recordings/details/3692,Instant_Drupal

Git-hez ajánlom még Nevergone videóit és a tanarurkerem.hu tanfolyamát(x) tagsággal tudod csak megnézni.

1
0
Szotyi képe

Szia István,

köszönöm a részletes választ.

A Git-hez, nézegettem publikus videóitokat amelyek nagy segítséget nyújtanak kezdőknek.

Akkor egy weboldal élettartamánál meg kell különböztetni ha
- css-t, php-t módosítunk
- modult telepítünk, állítgatunk, törlünk
- menüpontokat hozunk létre
- taxonómia változik
- node jön létre, vagy meglevő változik, esetleg meglevő törlődik
- tartalomtípus hozunk létre, változtatunk
- webhely információ (név, slogan) módosul
- valamilyen fájlt tölt fel a felhasználó

S ki kell alakítanom valamilyen szemléletet, hogy mi az amit könnyen lehet és érdemes, mi az amit nehezen lehet csak szinkronizálni. S mi az amit lehetetlen.

Ezután ki kell találnom, mindegyiknek a hogyanját.

Hm.. Mibe vágtam a fejszémet?! :)

1
0

Péter

fox mulder képe

ahogy a fentebbi válaszokban olvasható:
- git (kód szinkronizálás)
- features (beállítások szinkronizálása, pontosabban a features az adatbázisból kódot csinál [innentól git], de csak a beállításokból. Entitás-példányokból nem, vagyis pl. user beállítások átvihetők features-szel, de maguk a user-ek nem [ ugyanígy: node beállítások igen, maguk a node-ok nem, taxonomy term beállítások igen, maguk a term-ek nem ]. De általában ez nem is fontos. A dev-en kamu adatokkal [user-ek, node-ok, term-ek...] dolgozol, az élesen a frankó adatokkal, a megrendelő látni fogja a működést / kinézetet kamu adatokkal is)
- https://www.drupal.org/project/stage_file_proxy (ez arra jó, hogy a képeket [files mappa] nem kell feltenned dev-re, mert dev-en is az élesről tölti be)

0
0

Fox Mulder

Szotyi képe

Köszönöm a választ. Kezdem érteni. Elméletben. :)
Most jön a gyakorlat.

Rövid távú célom: itt az asztali gépen módosítok egy css fájlt, majd ezt a változást kiteszem a github-ra, majd onnan az éles gépre.

Az éles gépről lemásoltam a helyi localhostra egy oldalt. Működik is.
De már itt elakadtam. Hogy hogyan lehet egy már meglevő drupal projektet verziókezelő alá vinni?
lemásolom - git init - git add . - git checkout -b projektnév a jó sorrend?

Illetve lehet, hogy fogalmi zavaraim is vannak.
A 'dev' alatt az asztali gépen levő (localhostos) mappát értjük vagy inkább a neten kinn levő webszerveren egy almappát, amire egy dev.domainnév.hu mutat?
------

Update:
Én így vontam már neten kinn levő éles oldalaimat veziókezelés alá:
1. localhoston üres projektmappába:
- git init
- az összes weboldalfájl bemásolása ebbe a mappába
- adatbázis export - import localhostra
- weboldal beélesítése
- git add .
- git commit -a -m "Alaphelyzet"
- módosítottam egy css fájlt
- git commit -a -m "css fájl változtatva"

2. github-on
- új repositoryt készítettem neki
- az url jét kimásoltam a vágólapra

3. localhoston
- csináltam egy összerendelést: git remote add origin + vágólap url
- git origin mester
- név jelsz megadása után már kinn is van a kód, amit a weben le lehet ellenőrizni.

4. éles szerveren:
- kiüríteni az üres mappát, a . gitignore, settings.php és a sites/default/files/ mappa kivételével
- git init
- távoli elérés összerendelése: git remote add origin + vágólap url
- git pull origin master

S tadamm! Már a webszerveren is változáskezelés alatt áll az oldal az új css-el.

------

Most jön az, hogy
- mit is lehet szinkronizálni / változást kezelni
- azokat hogyan is kell megcsinálni
- ha valamit elrontottunk hogyan lehet mondjuk visszalépni 2 - 3 committel

0
0

Péter

szantog képe

Amit features, strongarm + kiegészítőivel kódba lehet rakni, azt lehet verziókezelni. De itt van ám a truváj, hogyha nem tudod, hogy mi az a cron_last variable, mi függ tőle, és beteszed feature-be, akár ki is nyírhatod az oldalt. Van olyan, hogy a file_temporary_path változót exportálni kell, mert a fejlesztés része, van olyan, amikor csak ártasz vele.
Nincs rá egzakt képlet, tudni kell, mi, mit jelent, és mit miért csinálsz.

2
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.