Source control - in viata de zi cu zi

Pai ai putea folosi un alt repo Git ca GOLD Repository. Oricum, interesant sistemul.
Lucrezi ca freelancer?

Am o intrebare pt. cei ce lucreaza ca freelanceri: Cum folositi source control-ul pt. proiectele ce folosesc o platforma dezvoltata de terte parti? De ex. Wordpress, DotNetNuke, dasBlog si ce s-a mai inventat in ultimii ani...
O mare parte din configurarile initiale se fac fie in db fie in fisiere de config. Cum se face tracking la aceste modificari? Sau nu se face? Nu merita (clienti mici)?
Folositi un env. de test si apoi deploy?
Cum actualizati code base-ul la un release nou al platformei folosite?

shiva, pe 19 august 2015 - 12:44, a scris:

De acord. Unele operatii mai merg si-n IDE, dar CLI e de baza.

Sunt freelancer (începător), nu am lucrat până acum în echipă, am folosit și încă folosesc git.

M-am jucat cu un script basic de deployment pe server dupa ce făceam push și mi s-a părut super tare, recomand

Intrebare despre patching in SVN:

1. I do checkout\update so I have version X locally and I start doing changes.
2. I do a patch, which for SVN it means I want to create a difference between version X and my local changes.
3. Then I do revert of all my changes, so now I have X locally again.
4. At some point later (I do commits, updates, merges) I have  X + N version locally and I want to apply that patch I did some time ago.
SVN looks at the patch and it knows is a patch based on version X.
I wonder if SVN will be OK with this, will SVN merge correctly the patch with whatever changes I have at that point?

Editat de fuel, 11 septembrie 2015 - 10:33.

CVS, SVN, de cativa ani aproape exclusiv GIT.
Uneori HG, cand injur (cred ca e cam la fel de bun ca GIT, dar nu-l cunosc la fel de bine).
N-as mai trece inapoi la CVS/SVN nici mort...

GIT: aproape exclusiv linie de comanda. Doar ceva diff-uri din cand in cand prin IDE, dar la diffuri mai serioase tot linia de comanda e sfanta.
Folosim GIT extensiv, atat pentru proiecte cat si pentru inregistrarea automata a modificarilor configurilor de productie, sau pentru primit mailuri (via hooks) cand se schimba ceva ce ne intereseaza in mod special.

Ca si mod de lucru pe surse, master-ul e branchul stabil, testat, gata de pus in productie. La release facem branchuri de release pe care ulterior le patchuim, dar niciodata nu se mergeuiesc inapoi in master.
Orice feature, fix, refactor se face si testeaza pe branchuri separate care nu ajung in repo-ul principal, ci doar le sharuim intre noi pentru review si testare. In repoul principal este doar master-ul si branchurile din productie.

GIT e oarecum dificil de invatat, dar scula mai versatila care sa te lase se faci tot ce stie el... eu nu stiu sa se existe...
De la stage si stash, prin rebase pana la rescriere completa a history-ului, cu eliminarea fiserelor nedorite - apropo de DLLurile alea prinse aiurea in history, cum zicea Mosotti mai sus.

sapho, pe 11 septembrie 2015 - 21:16, a scris:

Acel "de release" suna mai degraba a RC-uri, caci daca sunt releasuri, sunt bune de pus in productie. Noi le punem taguri (face jenkins la deployment, automat).

Bineinteles ca le punem in productie. Voiam sa subliniez ca patchurile le facem pe branchurile alea (evident, codul fixat este integrat si in master), dar branchurile nu se mai mergeuiesc inapoi in master ci raman abandonate la un moment dat cand facem alt release.

Nu folosim jenkins pentru build, folosim ivy + ant. Tagurile le punem manual. E mai putin important ce folosesti pentru build atata timp cat poti da oricand o comanda care iti face un nou kit de deploy exact ca ala pus in productie anu trecut.

sapho, pe 12 septembrie 2015 - 09:00, a scris:

Atunci branchurile alea nu-s pentru release-uri, ci pentru RC-uri.

Nu prea inteleg ce vrei sa zici...
Daca atunci cand fac branchul 1 pun si tag 1.0 si il pun in productie, mai e RC sau nu?

How a bug in Visual Studio 2015 exposed my source code on GitHub and cost me $6,500 in a few hours

Ce ma intreb eu: de ce ar introduce cineva o parola generala de administrare (sau cum s-o numi in cazul Amazon) in cod? Daca acel cod acceseaza serviciul X, pai ii dai cel mult parola pentru serviciul X, nu cea cu care poti crea alte servicii.

sapho, pe 12 septembrie 2015 - 09:32, a scris:

Vorbim despre workflow, deci vorbim despre "maximul de schimbari care se pot face", iar maximul e infinit - deoarece poti aplica oricate patchuri.

branch de release ar fi daca modificarile posibile ar fi 0. Tu insa patchuiesti acel branch, deci e branch de RC.

Chiar daca ai un caz fericit de RC fara bube, deci nu patchuiesti nimic ci il treci direct in master asa cum e, tipul acela de branchuri tot poate fi teoretic modificat (caci asa l-ai definit), de aceea e branch de RC.

De aceea am zis ca nu vad rostul branchurilor de release, pentru ca un release e fix, read-only, nu mai schimbi nimic la el. Pentru un release tag-urile se preteaza cel mai bine.

Noi nu avem branch de RC de exemplu, ci integram develop in mod regulat in feature branch si testam pana-i sar capacele. Cand testele sunt verzi, e integrat in develop, care iar e testat inainte de deployment.

develop e integrat in master automat daca deploymentul s-a facut cu succes (deci testele au trecut, care includ si teste de regresii de performanta ale unor instante docker pentru staging).

De fapt, ai putea spune ca develop e branch de RC, doar ca e un branch mereu stabil, hotfixurile care intra aici sunt in general din partea celor de la grafica/UI, pentru ca nu vrem sa-i complicam cu un workflow prea complex.

Editat de OriginalCopy, 12 septembrie 2015 - 10:15.

Pai nu dezvoltam pe branchurile de release, sau RC, whatever. Developmentul se face exclusiv pe feature/fix branchuri. Care apoi se integreaza in master. Daca avem o problema in productie, facem un dev branch, fixam, testam, punem pe master. Commitul respeciv se pune si pe branchul de release afectat si rezulta un patch nou. Nu punem chestii pe un branch de release daca nu sunt si in master.
Flowul asta ajuta in ideea ca nu vrei sa faci release (din diverse motive) la un feature care e deja pus pe master intre timp, de la release pana la patch.

Voi cum faceti daca tre sa puneti musai un hotfix, puneti tot ce s-a dezvoltat intre timp? Daca bagati ceva instabilitate majora cu noile fetureuri, cum faceti rollback? Faci rollback, automat scoti hotfixu pentru alta problema...

Editat de sapho, 12 septembrie 2015 - 10:31.

A, ok, incep sa inteleg workflowul despre care vorbesti.

sapho, pe 12 septembrie 2015 - 10:26, a scris:

Idem.

sapho, pe 12 septembrie 2015 - 10:26, a scris:

Nu inteleg ce problema rezolvati cu aceste "release branches". Development must be moving forward, deci la un moment dat release branchurile astea vor fi atat de in urma fata de master, incat nu vor mai conta.

Sau dezvoltati si vindeti diferite versiuni ale aceluiasi software catre diferiti clienti cu nevoie diferite la preturi diferite?

sapho, pe 12 septembrie 2015 - 10:26, a scris:

Da, e un singur produs unic, ceea ce ne intereseaza e sa functioneze totul integrat. Instabilitate majora nu introducem pentru ca totul e testat la sange inainte de a ateriza in develop. Integrarea se face regulat, develop e importat regulat in feature branch.

Avem un produs la care stabilitatea/calitatea e mai importanta decat adaugarea de chestii noi.
Ruleaza mai multe versiuni si instante in acelasi timp.
Releasuri facem destul de des, o data pe luna, uneori mai rar.
Trecerea la un nou release se face treptat si ia timp, asta ar fi unul din motivele pentru care evitam sa facem release la orice feature nou cand tot ce avem nevoie este de fapt un patch.

OriginalCopy, pe 12 septembrie 2015 - 10:45, a scris:

Asta depinde, nu toate produsele sunt la fel incat sa zici ca daca nu are latest stuff nu mai conteaza.

OriginalCopy, pe 12 septembrie 2015 - 10:45, a scris:

Nu-mi zi ca nu ati avut nici o problema majora la un release oarecare, ca nu te cred

sapho, pe 12 septembrie 2015 - 10:58, a scris:

Idem, mai putin partea cu patchul. Daca e o problema undeva, e un nou ticket, deci un nou branch, deci ciclul se reia.

sapho, pe 12 septembrie 2015 - 10:58, a scris:

Marea majoritate a problemelor au fost de cosmetica, iar dintre cele putine care n-au fost de cosmetica, problemele s-au lasat ocolite in software-ul insusi, pana cand am avut o corectare.

In arhitectura insasi sunt multe anticorruption layers, iar cate un feature e de obicei intr-un singur package, sau cateva anume, nu peste tot, deci daca ar fi o urgenta, am da revert la acele directoare.

Dar nu s-a ajuns la astfel de cazuri extreme, deoarece suntem foarte ofensivi la testare inca din feature branch - buguri majore nu ajung in develop in primul rand, in master nici atat.

OriginalCopy, pe 12 septembrie 2015 - 11:09, a scris:

Solutii sunt, si probabil ca asta e adecvata pentru proiectul vostru.
Dar cand tre sa faci rollback in 30s (in productie, nu in repoul tau) la o versiune sigura si stabila, asta nu e una dintre ele.