yancis Posted April 3, 2015 Report Share Posted April 3, 2015 Sveiki, esmu nonācis nelielā darba grupā, kas cenšas sākt strādāt ar versiju kontroli. Visi esam nūbi un ir radušās lielas problēmas. Situācija - programmē 4 cilvēki, katrs pie sava datora. Gitam ir pieejami merge, bet vienalga mums nav skaidrs kā tikt galā ar darbu dalīšanu. Piemēram, ir jāsāk projekts pilnīgi no nulles. Darījām tā, ka izlozējām "viedāko" no mums, kurš dažas dienas programmēja viens un izveidoja pietiekami plašu pamatu, lai būtu it kā četras vietas projektā, kuras var programmēt paralēli, nemaisoties viens otram pa kājām. Realitātē tas negāja pārāk gludi. Kamēr viens veic kaut kādas izmaiņas datubāzē, tikmēr otrs nezina, kāda informācija viņam būs pieejama vēlāk un vai View strādās.. Un tml. Varbūt mēs neesam kaut ko līdz galam sapratuši? Mēs tāpat maisāmies viens otram pa kājām un liekas ka ātrāk būtu kodēt vienam cilvēkam. Tiesa gan mēs saprotam, ka atsacīšanās no git pavisam būtu katastrofa, jo koda pārsūtīšana epastā vai kā citādi būtu vēl briesmīgāk. Quote Link to comment Share on other sites More sharing options...
maaceeklis Posted April 3, 2015 Report Share Posted April 3, 2015 projekta vadiitajs? Quote Link to comment Share on other sites More sharing options...
F3llony Posted April 3, 2015 Report Share Posted April 3, 2015 Vispirms ir jāvienojas par GIT workflowu, jeb veidu, kā strādāsiet. Viens no vienkāršākajem flowiem ir šis: Ir master branch. Master branch izmaiņas pa tiešo nekad neveic; Ir integration branch - integration branch ir branch kurā tiek mergotas visas izmaiņas; Ir feature branchi - katrai atsevišķai funkcijai; Mēģinam šadi: Tiek izdomāts kaut kāds darbs, piemēram, pievienot pogu kaut kādā skatā; Cilvēks no master (!!!) branch izveido jaunu branch, sauksim par "add-view-button" branch. Šis būs mūsu feature branch; Code, code, code; Autors "add-view-branch" izveido pull request pret integration (!!!) branch; Kāds cits izlasa un pārbauda kodu, apstiprina pull request; Konkrēto pull request iemērdžo integration (!!!) branch; Atkārtojam pāris reizes; Kad integration iemērdžoti pāris branchi, viss ir notestēts, un kad ir juša, ka vajadzētu šo likt "produkcijā", integration branch iemērdžo master branch. Normāli ne retāk kā reizi dienā - keep it small; Par konfliktiem: Normālā gadījumā pat ar GIT ir jācenšas nebāzties vienam otra darbā - ar tevis minēto piemēru, viens pilsonis uztaisa datubāzes stuff, pēc tam otrs kaut kādus kontrolierus, trešais pēc tam kaut kādus viewus. Ir ļoti jācenšas izvairīties no tā, ka 2 cilvēki strādā pie viena un tā paša feature, kas vēl nemaz nav pabeigts. Ja tā darīs, tad būs diezgan lieli murgi, konflikti utml. Taču brīžos, kad tas nav iespējams piemēram es mēdzu strādāt ar mokiem, un strādā tas šādi: Ir nepieciešams paralēli strādāt piemēram, pie prezentācijas un dba, utt; Viens pilsonis izveido mocku - reāli nefunkcionējošu crap, piemēram, kontrolieri, kas atgriež mock datus viewam, kādi tie būs realitātē - tas ir jaizdomā un jāizplāno. Minimālas novirzes ir pieļaujamas. Tas saucas feature promise; Feature promise liekam branch, kas izveidots no master; Tālāk viens pilsonis uztaisa branch no feature promise brancha, sauksim, dba branch; Otrs pilsonis uztaisa branch no feature promise, sauksim, view branch; Kad abi pabeidz, abi uztaisa pull request un samērdžo abus branchus iekš feature promise branch; Ja kaut kas nestrādā, salabo tieši promise branch; feature promise branch iemērdžo integration; etc. Quote Link to comment Share on other sites More sharing options...
codez Posted April 3, 2015 Report Share Posted April 3, 2015 Pievienoju fellony aprakstam smukus zīmējumus: http://nvie.com/posts/a-successful-git-branching-model/ Ar datubāzēm ir tā, ja sourcē glabā vai nu modeļu aprakstus, vai shēmu aprakstus, kurus tālāk pēc katrām izmaiņām katrs var uzpūlot un ar komandu iegūt jaunāko db struktūru. Piemēram, Symfony izmanto doctrine un modeļus raksta kā php klases no kurām ar konsoles komandām tiek atjaunotas db shēmas. Piemēram, ja viens kādam modelim pieliek kādu laiku, viņš to ieraksta modelī un iepušo. Cits nopūlo, palaiž shēmas atjaunošanas komandu un var strādāt ar jaunāko db. Ar šo var veiksmīgi strādāt, taču es dodu priekšroku 2 soļu procesam, kad no modeļiem tiek izveidotas aktuālās shēmas un tālāk tiek veidotas migrācijas, kuras var manuāli arī papildināt, piemēram, ar kaut kādu nepieciešamo bāzes datu migrāciju. Piemēram, tev datu bāzē glabājas naudas daudzums kā EUR daļskaitlis, bet tad tu saproti, ka tā īsti nav labi un gribi glabāt kā veselu skaitli centos. Ja izmainīsi tikai modeļa lauka tipu, migrācija nebūs pilnīga, tāpēc to papildina ar update, lai visiem pārējiem kolēģiem pēc migrācijas izpildīšanas dati būtu konsistenti. Quote Link to comment Share on other sites More sharing options...
qwerty Posted April 3, 2015 Report Share Posted April 3, 2015 Tas nav pārāk saistīti ar gitu, bet: Man pēdējā laikā sanāk rakstīt daudz single page aplikācijas jeb SPA. Tiem, kas tādas vēl neprot rakstīt, laikam jāiesaka paskatīties, jo workflowā var baigi labi nodalīt frontendistus no backendistiem ar F3llony pieminētajiem mockiem. Proti, backends sākumā sastāv tikai un vienīgi no mock metodēm, kas atgriež kaut kādus example crap datus. Tad frontendistu uzdevums ir izveidot frontendu, kas darbojas pie example datu struktūras, bet backendisti veido reālo kodu, kas atgriež tieši tādu backenda struktūru. Frontends no backenda vienkārši izcili atdalīts.. + vēl ātrums, ko piedāvā kešotais single-page-app javascripts, pati javascript struktūra un citi labumi Quote Link to comment Share on other sites More sharing options...
F3llony Posted April 3, 2015 Report Share Posted April 3, 2015 Pievienoju fellony aprakstam smukus zīmējumus: http://nvie.com/posts/a-successful-git-branching-model/ Šis ir redzēts, bet es esmu konkrēti pret "release" branchiem, hotfixes branchiem utml. izdarībām, kas vienkārši piesārņo workflowu. Rolling release un continuous integration FTW. Un tam, ka feature branchus taisa no "develop" brancha arī es nepiekrītu, jo faktiski tad sanāk bāzēt feature branchus uz integrācijas branchiem, bet integrācijas mērķis ir sinhronizēt visas izmaiņas pret master. Ja laikā, kad taisa feature branch integrācijā ir izmaiņas, izmaiņas jābāzē uz master, un pirms feature branch merge integrācijā jātaisa merge master=>feature, neturot integrācijā vienlaikus vairāk par pāris konkurējošiem aizvērtiem pull requestiem. Tas nodrošina nekonfliktējošu integrāciju un master nekad nelagos aiz integrācijas, therefore, CI un rolling release. Vienīgais izņēmums ir kad tiek strādāts pie kaut kāda milzīga feature, bet tad feature branch pats par sevi ir būs bāze citiem feature branchiem, kas strādās tā pat, kā feature promise. Quote Link to comment Share on other sites More sharing options...
foxsk8 Posted April 7, 2015 Report Share Posted April 7, 2015 F3llony: Izcilts apraksts. Tā arī notiek, un bieži nākas šķendēties, ka piemest pogu tev aizņem pāris sec, bet salikt, sainhronizēt un smuki sastrukturizēt git tree, logs, featured brančus paņem vairāk laika. Šeit noteikti kādam no 4 džekiem ir jāuzņemas leadership, ņem tieši tas, kurš ieviesīs dienas izmaiņas un izies cauri kodam. Šobrīd tā arī būs, ja neveidos feature, tu taču nečekosi visu laiku vai masterī ir kāds paspējis ātrāk piem kādu js, css vai ko izmainīt, nekā tu, un tā rezultātā radīsies konfliktu kaudzes, kuras varēsi šķetināt diezgan ilgi caur diff vieweriem. Par sql sinhronizāciju, tur arī ir savi tūļi, kā nosinhronizēt saturiskās lietas, jo dažreiz man piem ir tā, ka produkcijā viss ir, dev ir testa sql murgi, un tad vai nu manuāli tu ņem un meklē konkurētā view kontentu no sql dumpa un liec sev lokāli, vai visu dev murgu aizstāj ar reālo saturu un tad veic testēšanu, izmaiņas utt.. Ko kāds varētu ieteikt tieši sql sakarā? Quote Link to comment Share on other sites More sharing options...
Joyride Posted April 8, 2015 Report Share Posted April 8, 2015 @F3llony - paldies par detalizēto aprakstu. Mani arī interesētu DB versionēšana. Uz doto brīdi labākais variants, ko esmu atradis - visas DB struktūras izmaiņas tiek veidotas ar migrācijām un, laiku pa laikam, kad to paliek par daudz, tās tiek nodzēstas, un tekošais DB struktūras dumps tiek ielikts versiju kontrolē kā bāze, pārrakstot iepriekšējo. Quote Link to comment Share on other sites More sharing options...
F3llony Posted April 8, 2015 Report Share Posted April 8, 2015 @F3llony - paldies par detalizēto aprakstu. Mani arī interesētu DB versionēšana. Uz doto brīdi labākais variants, ko esmu atradis - visas DB struktūras izmaiņas tiek veidotas ar migrācijām un, laiku pa laikam, kad to paliek par daudz, tās tiek nodzēstas, un tekošais DB struktūras dumps tiek ielikts versiju kontrolē kā bāze, pārrakstot iepriekšējo. Vai nu tā, vai nu vienkārši ar migrācijām, nedzēšot. Parasti jau "par daudz" nemēdz būt, un ja tu seko rolling release augstāk, neizpildītās migrācijas pamatā ir tikai pāris. Par testēšanu, tam var turēt integrācijas vidi - kaut kādu serveri vai virtuālmašīnu, kas ik pa brīdim sinhronizējas ar produkcijas DB un datiem, cik tas reāli iespējams. Tad tur arī deploy darbus, kas pabeigti un atrodas integrācijas branch, un tad var notestēt gandrīz kā produkcijas vidē. Quote Link to comment Share on other sites More sharing options...
gurkjis Posted April 8, 2015 Report Share Posted April 8, 2015 Par SQL versionēšanu, es metu acis uz šo te: http://www.liquibase.org/ - bet vēl nav sanācis lietot. Izskatās, ka ir pieejami vēl citi, līdzīgi risinājumi. Šis open source. Quote Link to comment Share on other sites More sharing options...
codez Posted April 8, 2015 Report Share Posted April 8, 2015 Es izmantoju FlyWay, jo taisīts Javā un no Scalas var pa tiešo piekļūt pie API. Process: 1) no modeļiem uzģenerēju DDLi. 2) DDLi - DDLi-1 -> migrācija. 3) Papildinu migrāciju manuāli, ja kaut kas ir nepieciešams. 4) FlyWay migrē migrācijas iekš db. Quote Link to comment Share on other sites More sharing options...
Kasspars Posted April 8, 2015 Report Share Posted April 8, 2015 Ja jūs vēl neesat novienojušies par framework, tad paskaties uz Laravel, tur ir norelaizēts labs db migrāciju mehānisms Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.