Munka szinkron

Fejlesztés

Sziasztok!

Tanácsokra, ötletekre vágyom...

Szerkesztés: aki verziókövető rendszert akar ajánlani, az legyen szíves olvassa el, hogy mi a kérdés, és ha még mindig verziókövetőt ajánlana, akkor ne csak a nevét írja le, hanem azt, hogy miben lesz az jobb, mint a most használt verziókövető rendszerem! Köszi

A következő a feladat: fejlesztek*, és szeretném több gépre replikálni az egész mindenséget, biztonsági célból + ha mondjuk egy másik gép van nálam, azon is lehessen dolgozni.

* (hobbiból, meg az öcsémnek egy kis cuccot, de akár be is jöhet valami komoly munka).

Oracle az adatbázis, Oracle application expressben íródnak a "programok". +PL/SQL időnként (most épp nincs)

Első gép állandóan interneten lóg, (hívjuk szervernek) oracle folyamatosan fut (leállítható, de nem akármikor). Linux.
A másik kettő 1-1 laptop, az egyik linux, a másik windows, ezeken az adatbázist csak akkor indítom el, ha épp ezzel akarok vacakolni.

A következő módon működne a tökéletes megoldás:
linuxos laptopon fejlesztek, fejlesztés végén azt mondom, hogy új (napi) verzió kész, elindítok egy scriptet, ami eltárolja mondjuk egy bzr-ben a változásokat, és szinkronizálja a szerverrel.
A szerveren, ha nem muszáj, az adatokat nem bántja (feltételezve, hogy nem törlök mondjuk táblákat, oszlopokat... ha igen, majd kitalálom, mi legyen kézzel)

Windows laptopon ha vacakolok, onnan a linuxos laptopra lenne jó áthozni a dolgokat. Nem feltétlenül gombnyomásra, de lehetőleg foolproof módon. Az adatok és a program egyszerre csak az egyik laptopon változik.

Korábban kézzel ment a szinkronizálás 1 laptop és a szerver között, így:
PL/SQL forrást, dokumentációt és kézzel készült apex exportot, séma struktúra exportot (adatok nélkül, és kézzel itt-ott szerkesztve), meg néha adat dump xml-t bazárba tettem a laptopon.
Laptopról (bzr repóról) rsync-kel készült időnként mentés.
Telepíteni a másik gépre egy shell script futtatásával lehetett - ez scp-vel feltolta a scripteket, sqlplus-szal eldobta a sémát, újraépítette, az apex programot meg kézzel importáltam a webes felületről.

Ez így ment... de a kézi matyizást utálom, és ha nem csak egy program lesz, akkor elég sok a hibalehetőség. Meg ha már élesben megy, vannak adatok, akkor ez így nem mehet, nem dobhatom el a sémát.

Van több ötletem, de még egyik mellett se tettem le a garast.

Lehetne (biztonsági mentésként) adatbázis mentést készíteni (offline mentést egyszerűen, pl. éjjel scriptből a folyamatos üzemű gépen). Ez jó, mert mindent ment, de csak mentésre jó, másra nem. Lehet, hogy ezt megcsinálom (ha már élesben megy), de addig biztos nem.

Lehetne egyszerű dumpot készíteni, ezzel elméletileg bármiféle adatot és struktúrát mozgathatok. Meg biztonsági mentésnek is jó. Nem valószínű, hogy érdemes lenne a teljes adatbázisról dumpot készíteni, inkább sémánként - pl. minden projekt külön sémában lakik. De ez is csak addig jó igazán, amíg nem kezdi mondjuk öcsém használni a programját, mert akkor ugye már két helyen változhat a cucc.
Esetleg így lehetne a windows gépről a linuxosra, (és mielőtt a windows-ost viszem, azelőtt fordítva) vinni a fejlesztéseket.
Windowst nem tudom, lehet-e scriptelni, de mondjuk kézzel azt mondani, hogy eldobom a sémát, új séma, majd imp, az nem kibírhatatlan. (A win gépet egyébként se használom sokat, mondjuk heti 0-2 alkalommal maximum)

Készíthetnék install scriptet, ami adott verziók közötti séma struktúra különbségeket sql scripttel lemásolja a másik helyre. Ha nem szalad el velem a ló, akkor lehet sémákat összehasonlítani, és diffet készíteni programmal, szóval ez működhet, de erre sem ismerek pl. automatikus módszert, csak olyasmit, hogy elindítok egy toad-ot, vagy egy sqldevelopert, és a menüből kiválasztom... én meg automatizálni szeretném, ha lehet.

Szóval most valami ilyesmi lenne az ötletem:
-ha a win gépet viszem, akkor linuxos gépen dump, pendrive-ra, win gépbe erről betöltöm, dolgozom vele, amikor hazaérek, akkor meg fordítva, dump és import linuxos gépbe.
-linuxos gépen napi munka végén forrásfájlok, doksik, stb. bazárba, meg mondjuk egy automatikus dump sémánként külön (ez is bazárba). Szerverre bazár szinkronizálva, saját hobbiprojektek esetén dumpot egyszerűen be is tölthetem. Öcsém programjának sémáján meg mondjuk kézzel változtatok, kézzel töltöm fel a kiegészítő adatokat.
-szerveren nem fejlesztek.

Ez azért távolról sem optimális, de működhet. Kérdés, hogy van-e jobb ötlete valakinek.

  • 3213 megtekintés

ehm...

És ezt így hogy?

Úgy gondoltam, nem egy programot keresek, hanem egy munkafolyamatot, (amiben esetleg egy rcs is szerepel)

Vagy SVN tud oracle sémákat az én kézi matyizásom nélkül elemezni, a változásokat leszippantani és deltát készíteni?

G

Nem.

Azt írta, hogy érdemes a fejlesztés során a dolgokat verziókövető rendszerben tárolni.

A kérdésben leírtam, hogy jelenleg ezt csinálom.

Ha az SVN-t ajánljátok, akkor feltételezem, valamit javít a jelenlegi helyzeten, és ezért érdemes lenne a bzr-t lecserélni rá.

Azt kérdeztem, hogy az svn, +1, +1, +100 kommentelők mire gondolnak konkrétan, hogy az svn használatával mitől lesz nekem jobb

Kedves.

Tudod, de nem mondod meg, hanem kezdjem el átolvasni az svn doksiját, és hátha valahol ott van benne? És hátha észreveszem?

Az SVN book tartalomjegyzékét átfutottam semmiféle releváns címet nem találtam.

Szóval aki tudja, hogy nekem jobb lesz bzr helyett svn, az legyen olyan jó, és írja meg, hogy miért, mert eddig úgy gondolom, hogy a bzr jobb.

G

Tomentelen hook-ot ugy szerver, mint kliens oldalon, es az rsync eliminalasat. SSH-n at is mukodtetheto, viszonylag egyszeruen, tehat a titkositassal sincs gond. Windowsra lehet mysysgit-et rakni, beloni hogy menjen puttyal, es akkor pagent-be egyszer felveszi a kulcsot, oszt csa.

A hookokkal erdemes vigyazni, es csak a tenyleg jo dolgokat felloni. Esetleg lehet egy kulon git repot csinalni a kozponti szerveren, es oda csak akkor pusholni, ha biztos vagy benne, hogy az automata mukodore tudja hozni az oracle szervert. Ekkor a "deployment" hookokat ott intezni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( zeller | 2009. 07. 11., szo – 19:48 )

cvs :-) (Csakazértis... Meg persze Windowson TOAD)

( lguru | 2009. 07. 11., szo – 21:45 )

Bevallom nem olvastam végig pontosan mit szeretnél, de néhány szóra felfigyeltem.
Nagyon gagyi megoldásként - szigorúan ha csak néhány táblás, nem életbevágó dolgokról van szó - lehet triggerekkel operálni (központi adatbázis fontos tábláin triggerek + link távoli adatbázishoz, minden insert, update, delete esetén ott is), viszont komoly fejfájás lehet belőle ha egy távoli adatbázistól függ a központi működése. A korrekt, robosztus stb. és drága megoldást a replikáció adná.
Imp helyett az rman okosabb dolgokat tud, sőt, egész jó megoldást lehetne kihozni standby adatbázis használatával klasszikus betöltögetős biztonsági mentés helyett. Akár kombinálva távolra szinkronnal, itt pl. egy egyszerű példa.

( wladek1 | 2009. 07. 12., v – 01:53 )

Ugyan nem (egészen) jó a témához, de a fejlesztéseimet mindíg Dropbox -ba is letárolom.
Így minden gépen szinkronban van minden.

"-Pedig vegetariánus vagyok; csak növényevő állatokat fogyasztok!"
azenoldalamponthu

( gthomas | 2009. 07. 12., v – 06:53 )

sql struktúra mentés: dbms_metadata
ha nem nagy az adatbázis, akkor lehet exp/imp
ha nagy, akkor naplózni kell, hol, mi változott (triggerek), és csak azokat áttolni (azért a szinkron elcsúszhat).

verziózás: mercurial vagy git vagy svn (bzr lassú), de ízlés kérdése.

Esetleg írhatsz egy kis progit, ami valami egyszerű XML-be tolja a teljes adatbázist (objektumonként (tábla, stored proc) új fájl, és az importot is tudja - így nagyon jól verziókövethető (csak a különbség tárolódik), és a különbséget kell csak a gépek között mozgatnod.
Ajánlott az elosztott verziókövető (DVCS), mert mint mondod van, hogy a két laptop között kell az adatokat mozgatni - erre az svn körülményes (külön branch, és mindig láthatónak kell lennie a gépnek).

"ha nem nagy az adatbázis, akkor lehet exp/imp"

exp/imp oracle verziófüggő, és az orékül ballisztikus ívben a felülről kompatibilibilibilitást. Újabbakban _talán_ benne sincsen már, hézagos emlékeim szerint.

"verziózás: mercurial vagy git vagy svn (bzr lassú), de ízlés kérdése."

utolsó háromra (kettőre): +100000000000

ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne

exp/imp különböző verziók között akkor ment, ha a kliensből megvolt a másik verzió is. Tehát mondjuk 9-es szerverről készített exportot 10-es szerverre 9-es kliensprogrammal kellett betölteni.

Így emlékszem, de régen volt. Lehet, hogy 9-esből 10-essel kellett exportálni.

Mindenesetre ez itt nem téma, mert ugyanaz a 10-es XE van mindenhol, és ha verziót váltanék, akkor azt is egyszerre váltanám.

( asch v | 2009. 07. 12., v – 18:35 )

Bármit ha fejlesztesz ésrdemes úgy csinálni, hogy fejlesztés közben dokumentálnod, hogy a nulláról (értsd vas és telepítő lemezek) hogyan jutsz el egy teljes értékű fejlesztő környezetig, illetve a működő termékig (build lépései, release, telepítés indítás stb).

Egyrészt egy munka esetén enélkül sokkal kevesebbet ér a "forrás", másrészt ha csak hobbiból csinálod magadnak is jó gyakorlás, illetve mikor elfelejted van honnan elővenni.

A dokumentálás mellett érdemes a legtöbb lépést automatizálni szkriptekkel (pl Linux csomagok telepítése, szerver konfigurálása, forrás kicsekkelése és build készítése), ezáltal kb öndokumentált lesz a rendszered.

Ha több gépen fejlesztesz (de ha csak egyen, akkor is), akkor mindenképp használj verziókezelőt (svn, cvs stb) a források, a doksik és a build szkriptek - minden tárolására. Természetesen maga a verziókezelő nem old meg mindent, hanem jól végiggondolt build folyamat kell hozzá, hogy valóban használható legyen, ezt neked kell megtervezni.
Például adatbázisra a következő három dolgot érdemes megcsinálni:
* szkript, ami létrehozza a sémát
* szkript, ami létrehozza a kezdeti állapotot
* szkript, ami létrehozza a teszt adatokat

És ezeket a fejlesztés folytatása előtt verziókezelőből kihúzva mindig lefuttatod.

Ha így dolgozol, akkor a lehető legkisebb fájdalom áttérni egyik fejlesztő gépről a másikra, illetve mire kiadod a kezedből a munkát nem lesz fejfájás, hogy mit is kell a célplatformon telepíteni ahhoz hogy menjen a rendszer.

Verziókezelőre sajátot kell telepíteni (rendszeres backupot meg kell oldani!), vagy ha a dolog amit csinálsz nem "privát", akkor hosztolhatod sourceforge-on, vagy Google-n ingyen.

Igen, ezt írtam, hogy ezt csináltam eddig.

Korábban kézzel ment a szinkronizálás 1 laptop és a szerver között, így:
PL/SQL forrást, dokumentációt és kézzel készült apex exportot, séma struktúra exportot (adatok nélkül, és kézzel itt-ott szerkesztve), meg néha adat dump xml-t bazárba tettem a laptopon.
Laptopról (bzr repóról) rsync-kel készült időnként mentés.
Telepíteni a másik gépre egy shell script futtatásával lehetett - ez scp-vel feltolta a scripteket, sqlplus-szal eldobta a sémát, újraépítette, az apex programot meg kézzel importáltam a webes felületről.

És a sok kézi vacakolás helyett szeretném, ha megoldható, automatizálni a dolgok egy részét.

Pont ezt linkeltem be fent én is :-)

Gyakorlatilag nem az a baj, hogy nincs verziókezelő, amibe eltárolhatnám a fájlokat.

Most a bzr-t használom, elosztott, mindent tud, amit akarok. Az SVN (akár az elosztott SVN) nem látom, hogy mennyivel ad többet.

A gond az, hogy a fájlokat kézzel kell előállítanom, és amíg teszt rendszert telepítek, addig nincs is komoly gond, de éles rendszeren már nem tudom eldobni a sémát, diff-et csinálni meg megintcsak macerás (de persze megoldható).

G

Mi ezen úgy léptünk túl, hogy kétféle DDL scriptet
gyártunk:
- Egyik, amelyik nulláról létrehozott rendszerre jó
(pl. DROP TABLE + CREATE TABLE)

- Másik meg inkrementális
(ALTER TABLE)

Éles DBre inkrementális, teszt renedszert meg az első alapján.

Fejlesztési + tesztelési időben kicsit több, de megtérül.

Én is ezen gondolkoztam.

Itt elhangzott pár ötlet, aminek még nem néztem utána, de alapvetően ha most kellene nekilátnom, akkor ezt csinálnám:
SQLdeveloperből adatbázis mentés - ez a séma DDL-t menti ki, opcionálisan adatokkal. Ez jó a teszt adatbázis újragenerálásához.
SQLdeveloperből adatbázis összehasonlítás - ez két séma különbségét képzei le DDL-lel (remélem a segédtáblák tartalmát is tudom nézni).
Ez jó éles rendszerhez.

Ezzel az a gondom, hogy SQLdevelopert kell indítani, klikkelni kell.

A tökéletes megoldás ugyanezeknek az előállítása lenne scriptből (shell script, sqlplus script, ilyesmire gondolok)

Metadatával nincs tapasztalatom, annak még utánanézek, hátha jó lesz nekem. Illetve az biztos, hogy jó lenne, csak az nem biztos, hogy XE-vel megy.

G

Ha ugy veszem, azt a bizonyos scriptet is el kell inditani, okosan kell parameterezni, foleg a keletkezett diffet at kell ellenorizni (nem jo, ha az eles szerver csak ugy megborul). Gondolom idealis megoldas nem minden esetre van, idonkent kompromisszumot is kell kotni.

Foleg, ha csak deployment celjara kell: biztos hogy olyan nagy gond par klikkeles? Vegulis nem percenkent deployol az ember, hanem adott idokozonkent.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Fene tudja, milyen gyakran lesz release.
Mindegy, release esetén átnézni nem gáz, főleg, hogy úgy számítom, hogy az adatmodell maga nem fog hibajavításonként változni.

Korábban, amikor kézzel csináltam ilyesmit egy teljes projektnél, kezelhető volt, csak utáltam folyton végigklikkelni (mondjuk akkor apexből generáltam a ddl-t, és ott azért elég sokat kellett klikkelgetni, ráadásul a vége egy egeres kijelölés, vi-ban meg paste volt, mert az apex nem tudott jó scriptet menteni).

Az SQLdeveloper sokkal könnyebben és sokkal szebb scriptet generál.

De ha teljes mentést csinálok (verziókövetkéshez), akkor nem fogom átnézegetni, és sokkal egyszerűbb lenne elindítani a myexport.sh parancsot, ami konzolon hipp-hopp megcsinál mindent, mint elindítani az sqldeveloper.sh-t, megvárni, amíg betöltődik (lassú), remélni, hogy lesz neki elég memória (mert azért a java elég sokat zabál), klikkelni egyet, aztán bezárni az egész programot.

Ennél sokkal szomorúbb, hogy az apex programot nem lehet érdelmesen integrálni verziókezelőbe, csak exportálni az egészet, és az így keletkező sql-t. Viszont ez óriási, és nem sok közöset talál benne a cucc, tehát folyamatosan viszi a helyet.
Ezt is jó lenne kézi matyizás nélkül exportálni, de ezt elfogadom, úgyis, ha már valamit változtattam, akkor ott a felület, csak meg kell nyomni az export gombot.

G