Source control - in viata de zi cu zi

shiva, on 12 august 2015 - 15:23, said:

Mi e pare genial Jira in versiune noua si se integreaza foarte fain cu Stash si poti vedea schimbarile.
Bugzilla are un client, nu stiu daca e o versiune mai veche, da seamana ca un site din anii 90, cind am intrat prima data pe internet. Cu alte cuvinte imi aduce aminte de vremurile cind eram mic si prost, deci il urasc
Da cel mai fain tool mi se pare SmartGit

Mihai_3, on 12 august 2015 - 15:52, said:

Read-only nu este OK pentru ca vine Mosotti si face Get Latest Version, apoi da Build si primeste 1000 de erori si se uita ca boul, pina se prinde ca-s fisierele read-only si nu se pot suprascrie si de fapt nu e nici o eroare

De fapt, din cite am inteles, TFS 2012 deja are ceva optiune ca sa treci peste aiureala aia (sau feature dubios)...

Cit despre check out, n-am lucrat in viata mea cu asa ceva, check out pe fisier are rost daca vrei sa pui lock pe fisier, ca sa te injure toti cind pleci in concediu si-l uiti asa. Daca fac check out la proiect, pai lasa-ma sa modific ce am io chef, pentru ca-s pro, sau macar pune securitatea aia ca optiune, ca sa pot sa o scot dracului

Ce fisiere suprascrii la build, care sa fie si in TFS?

Părerea mea e că în general se pierde o grămadă de timp cu chestii precum vcs, ci, build tools etc. Dacă s-ar pierde atât de mult timp pe cod (design, practices, testing etc.) ar ieşi mult mai ok overall. Dar în general se face doar să meargă şi apoi se tot freacă la ele până...

De vreo 3 ani am folosit doar git; mai de mult am folosit şi svn. Mă şi mir că mai sunt echipe care încă nu folosesc git sau care folosesc TFS; chiar şi Microsoft foloseşte git.
Personal mi se pare foarte stupid git, deoarece trebuie să înveţi cum funcţionează să-l poţi folosi ok. Noroc cu ide-ul, care mai abstractizează; doar pe server tre' să folosesc cli.
Git merge OK dacă este instalat mecanism de pull request sau se dau release-uri paralele cu funcţionalităţi diferite.

Cel mai tare scm folosit vreodată a fost Dropbox; lucram în facultate cu un coleg la un proiect comun şi l-am pus în Dropbox. Vedeam aproape live schimbările făcute de el şi invers; imposibil de ajuns la conflicte. Sunt curios cum ar merge asta la o scară mai mare.

shiva, on 12 august 2015 - 12:17, said:

Pe proiect se foloseşte Jenkins configurat cu o grămadă de slave-uri; de fiecare dată când se face merge la un branch, ruleaza testele pe vreo 50 de slave-uri timp de vreo 40 de minute (îs o grămadă mare de teste). Dacă pica un singur test, nu intra codul şi blestemi când pică un test care nu te afectează.
Ca build tool e maven, care e ok dacă eşti familiarizat cu câteva plug-inuri de bază. Ce e fain la maven e că ştii unde găseşti codul, unde găseşti testele, unde găseşti alte resurse, unde-s dependinţele. Plus că Intellij oferă un suport foarte fain; mai ales atunci când ai vreo 7 versiuni de aceeaşi librărie pe classpath, fiecare de prin alt proiect dependinţă şi tre' să găseşti care de unde vine. Am auzit că Gradle ar fi mai fain desi încă nu m-am jucat cu el; poţi face chestii mai complicate, ceva mai simplu cu scripting, nu cu configurări complicate de plug-inuri.
Ca issue tracker e Redmine; e open source şi chiar foarte ok.
Pentru code review folosim Upsource de la Jetbrains; e ok.
Pentru db se foloseşte liquibase; am ales ăsta că avea rollback în plus faţă de flyway, deşi până acum n-am folosit niciodată.
E pupet pentru configuration; deşi ăsta e mai apreciat de cei de la Devops.
Şi mai e sonar configurat, dar nu prea-l bagă lumea în seamă prea des; o treabă parţială cu analiza de cod face şi Intellij când vrei să dai commit.

Mosotti, on 12 august 2015 - 15:15, said:

Tare.

Edited by m3th0dman, 12 August 2015 - 23:15.

dani.user, on 12 august 2015 - 20:33, said:

Dll-uri, nu ma intreba de ce-s in TFS, ca nu io le-am pus

Oricum primul lucru e sa modifici niste fisiere de configurare si alea-s read only

Ma bag si eu in vb desi nu prea am treaba cu partea de build. Mai mult decat jenkins mi-a placut bamboo integrat cu hipchat, jira si bitbucket.
build-uri automate, mesaj pe chat daca pica ceva, asa aflat toata lumea imediat si eventual si o eroare graitoare. a mers struna pe partea de build proiectul ala. (backend-ul era node).

Dilas: Cate proiecte aveati in bamboo si cati agenti de bamboo? La noi se misca de porc (ma rog, la client) cu backend mercurial.

Parerea mea e ca mercurialul e un fel de liant intre svn si git. Jumatate de om calare pe jumatate de iepure schiop, vorba povestii. Daca folosesti named branches si ai o echipa mare: moare in chinuri, daca nu faci merge la branchuri, chiar daca le dai close, moare in chinuri....

M-am jucat la un moment dat cu un plugin de ReviewBoard pt. tortoiseHg. As fi vrut sa nu poata sa faca push pe branchurile principale fara un code review. Pacat ca pluginul nu mai e intretinut si tot da erori. Plus ca si ReviewBoard e mai dificil de instalat, chiar si pe linux.
Alta data am facut un script de Groovy pt. Jenkins care sa-mi ia versiunea de build din Jira folosind rest api-ul Jira, sa faca build-ul, sa-l puna pe un network share si sa trimita mail la devi si qa-ii.

Edited by shiva, 13 August 2015 - 11:33.

m3th0dman, on 12 august 2015 - 23:12, said:

L-ai folosit (TFS), intr-un mediu configurat adecvat, si ti-a lasat o impresie nasoala? Are versiune aparuta anul acesta, e disponibil si online. Are o alta abordare fata de git, cu avantaje si dezavantaje.
De ce nu l-ar mai folosi lumea? Fiindca isi publica MS unele chestii open-source pe github? Asta-i total altceva...

m3th0dman, on 12 august 2015 - 23:12, said:

Se pierde, dar parca in lumea Java se pierde si mai mult, unul din motive fiind si diversitatea tool-urilor: plin de IDE-uri, plin de build-tools, etc.
"Monopolul" Microsoft mi se pare chiar benefic in cazul asta. Stii ca asta ti-e IDE-ul, asta e package manager-ul cel mai des folosit, integrat deja in IDE => da-i bataie si rezolva probleme utile, solutiile mergand la fel de bine si la colegul.
Apar si aici situatii mai delicate, dar aloci cateva ore sa intelegi ce se intampla si cum aborderzi mai bine problema (nu arunci doar ceva ce merge bine doar in primele 5 minute) si apoi vreo luna ai liniste.

Edited by dani.user, 13 August 2015 - 17:51.

@shiva pai cam toate, adica vreo 7-8 proiecte. n-am OBS probleme de viteza pe nici un proiect la deploy. oricum se facea deploy separat pt front end si backend pentru ca erau single page app-uri pe REST. (toate backend-urile erau node)

shiva, fara suparare sincer cat timp ai investit pentru studiul TFS-ului intr-un domeniu WINDOWS cu AD ?
Cine ti-a facut setupul ? Stima.

Mihai, n-am avut ocazia sa folosesc TFS. L-am instalat de curiozitate pe o masina de test, ca era vb. ca o sa folosim TFS dar n-a mai fost cazul.

Am folosit pe rand SVN/TFS/Git (cel putin cate 2 ani fiecare). Prefer Git (momentan).

dani.user, on 13 august 2015 - 17:51, said:

N-am folosit niciodată TFS, doar am auzit prieteni mai mulţi că se plâng de el.
Din întâmplare clientul pentru care de puţin timp e chiar Microsoft; şi folosim git şi Jenkins (şi Java) în env-ul lor, pe Azure. După cum spuneai, există avantaje şi dezavantaje.

Desigur e foarte frumos pentru proiecte simple şi medii. Dar pe proiecte mai mari, chestiile devin prea complicate şi dacă toate vin de la Microsoft nu prea ai altă alternativă. Pe când pe Java mai mulţi şi-au scris câte-o soluţie (de multe ori open source) la problema de care s-au lovit; chiar dacă eşti efectiv împotmolit poţi să faci ceva, să iei codul şi să faci upgrade ai tu nevoie. Ca mai sus, avantaje şi dezavantaje...

Edited by m3th0dman, 17 August 2015 - 22:27.

Ca tot ai amintit de Azure: pe un proiect anterior aveam codul sursa in github si CI server se folosea jenkins.
Joburile de deploy in jenkins faceau urmatoarele chestii:
- build la proiect
- creaza o masina in AWS cu setupul necesar
- deploy db
- deploy proiect in IIS
- deploy db upgrade
- rulare teste automate

Amu' daca sunt resurse hardware se poate folosi vagrant

Personal am folosit CVS, Subversion si Git.

CVS, mai precis WinCVS + CVSNT, l-am folosit de mult si inca il mai folosesc. E inca de baza.

De Subversion am avut nevoie la un moment dat, mai precis SVN standard in linie de comanda, dar pentru putin timp. Ce imi place la el fata de CVS si Git sunt numerele de revizie care iti dau o idee daca o anumita versiune e ‘mai noua’ sau ‘mai veche’ si cam pe unde e plasata in istoric. Git nu are asa ceva, acele SHA1 nu spun absolut nimic. CVS are dar la nivel de fisier, fara a grupa in nici un fel modificarile din fisiere diferite dar care formeaza o singura corectie/ evolutie/ etc.

Git folosesc regulat (GitEye), si ce imi place la el este usurinta de a lucra cu ramuri si de a rescrie istoricul pana iese cum vreau eu. Am mai incercat si SmartGIT pe acasa, da’ parca interfata de la GitEye mi-e ceva mai la indemana. Insa nu pot avea incredere asa multa in el, cu atat mai putin in GitEye care e bazat pe J/Git. Dupa mine, deviza potrivita pentru Git este ‘Din cârpeală în cârpeală/ Către f… praștia finală’. GitEye imi ofera si necesara portie de adrenalina, adica ii dau un ‘Rebase interactive’ si… si… si… ‘java.lang.NullPointerException’! (Cateodata, nu foarte des, dar oricum.)

Pt. Git, IMHO, linia de comanda rulz. Ca si la mercurial. Restul sunt doar wrappere cu GUI, mai mult sau mai putin reusite.
Cum de inca folosesti CVS? Credeam ca a fost abandonat de cand au aparut SCM-urile distributive).

Ar trebui sa clarific ‘de baza’ in legatura cu CVS. Git e o prastie, dar are avantajele lui si isi nimereste tinta pentru lucrul de zi cu zi. Bine, trebuie sa ii cunosti hibele ca sa nu iti dai cu elasticul peste maini. Dar odata ce ai realizat un scor frumos, iei tot batranul aparat foto CVS sa ‘imortalizezi’ rezultatul, ca din obisnuinta stii ca face poze bune. Iar inainte de poza mai verifici totul inca o data, ca nu cumva prastia sa iti fi facut prastie ceva pe acolo.

Iar de disparut: da, CVS este vazut ca fiind desuet, dar pe principiul ca odata cu ‘D’SCM-urile a disparut CVS ar fi trebuit sa dispara si SVN care nu e nici el distribuit. Si totusi Subversion este dezvoltat in continuare si are utilizatorii lui.

Prea multe metafore.
Stai sa inteleg: folosesti git in munca zilnica dar la un release codul se pune in CVS? huh?

Git in munca zilnica, si cand ceva mai mic sau mai mare e gata (nu neaparat ‘release’ in sensul ca merge ceva la clienti) toata bucata de istoric pusa la punct pleaca intr-un GOLD Repository tinut in CVS. Pentru asta am inventat si eu ceva: working copy mixt CVS+Git!

Stiu ca pare ciudat, dar nu e [inca] momentul sa trec cu totul la Git (peste SVN am sarit din lipsa, la vremea potrivita, a unui GUI bun). O data ca are probleme si nu am destula incredere in el. Alta data ca vechiul Repository CVS mai are nevoie de unele aranjamente/ corecturi, dificil de facut, care tin de istoric si pe care nu imi gasesc niciodata timp sa le fac (nu sunt nici pe departe o prioritate sau asa importante, dar imi place ca totul sa fie pus la punct 100%); dupa conversia CVS->GIT nu se mai pot face cum le vreau eu, plus ca as ramane cu Repository-ul CVS - chiar arhivat - nepus la punct.

Edited by sags, 19 August 2015 - 18:37.