Hvala. Takodje, dobra pitanja.
Svi ovi Ant-oliki alati su generalno vrlo mocni sa bezbroj mogucnosti za konfiguraciju i customizaciju.
Ono sto nas razlikuje od njih je kao prvo GUI - ali ne GUI koji je on-top tih resenja, vec GUI koji je od pocetka "projektovan" bez njihovog uticaja. Razlika je i u tome da ne moras da citas dokumentaciju da bi konfigurisao profil za deploy. Dakle akcenat na UX delu. I kao trecu stvari bih naveo gledajuci i malo subjektivno. Ne preferiram kada koristim neki sw i kada ima 1001 opciju, a ja samo koristim 20. Vise sam za varijantu da isti radi jednu stvar i da je radi dobro, stabilno, brzo. Da sve bude upeglano i koncizno. To bi bile one funkcionalnosti koje se mogu videti na sajtu.
Sto se tice migracija, mi imamo praksu da sam sql cuvamo u .php fajlovima. Tako da samu bazu ne pravimo iz db alata vec tako sto izvrsimo te .php fajlove. Na osnovu ovoga, moze da se same definicije SQL-a eksportuju u Domain klase tj. Modele ili Entitete kako ih mi nazivamo. Tako da u nasem slucaju je relativno "lako" raditi snapshotove baza, upgradeovati i downgradovati bazu. Podaci su najproblematicniji i tu trenutno radimo export baze u produkciji pre deploya, sto na velikim bazama nije najsrecnije resenje. Moze se isto i napraviti mirror baze i raditi na toj bazi migracija, pa ako sve prodje ok, obrise se stara i poturi nova. Ima jos par nacina - ali nisu silver-bullet.
Medjutim, kako svi ne koriste ovaj nacin za odrzavanje SQL-a i baza, te da baze mogu biti na vise klastera itd, trenutno istrazujemo kako ljudi to najcesce/najvise rade, pa trazimo neki NZS kako bi na osnovu toga napravili samo resenje. U sustini nisam radio sa nekim fw-cima za migraciju u PHP-u, pa bas i ne znam kako rade. Ali u svakom slucaju sam planirao da pogledam.
Kako je projekat u ranoj fazi, nemamo odgovore na sva pitanja. Dosta istrazujemo, eksperimentisemo i igramo se kako bi sagledali stvari iz vise uglova. Nadam se ipak da sam ti koliko-toliko odgovorio na pitanja.
|