h3. Quality Asurrance

Noi am rulat in mare parte site-ul direct din trunk si am avut de multe ori bug-uri mari pe site-ul live. Motivul principal a fost ca sa nu stagnam development-ul prin birocratie excesiva. Este totusi destul de riscant si neprofesional sa rulam direct din trunk.

Noi am rulat in mare parte site-ul direct din trunk si am avut de multe ori bug-uri destul de naspa pe site-ul live. Motivul principal a fost ca sa nu stagnam developmentul prin birocratie excesiva. Este totusi destul de riscant si neprofesional sa rulam direct din trunk.

Putem sa avem un site special de development pe trunk, dar care este marcat explicit pentru testing. Site-ul poate sa sa se updateze singur la ultimul trunk si sa ruleze teste automate folosind un dataset redus (pentru a minimiza efectele unei gauri de securitate). Scripturile necesare nu sunt deloc greu de scris. Ramanem totusi la idea de a rula din svn, nu are sens sa facem o procedura separata de upgrade/deployment.

Putem sa avem un site special de development care ruleaza automat trunk, dar care este marcat explicit pentru testing. Site-ul poate sa sa se updateze singur la ultimul trunk si sa ruleze teste automate folosind un dataset redus (pentru a minimiza efectele unei gauri de securitate). Scripturile necesare nu sunt deloc greu de scris. Ramanem totusi la idea de a rula din svn, nu are sens sa facem o procedura separata de upgrade/deployment.

Noi avem o singura instanta care este in productie la orice moment. Asta inseamna ca nu are sens sa mentinem branch-uri separate stabile sau instabile. Noi nu facem "release-uri" publice in sensul standard si e posibil ca layout-ul standard subversion sa nu fie foarte util. Propun sa ne facem un layout custom:
* branches/more-ajax: Sandbox-uri pentru schimbari majore

* release/infoarena-3.1.7: De aici rulam site-ul live. Facem commit cu multa grija.
* external/smf-2.1.9: Pentru pachete externe care au nevoie de merge; echivalent vendor.

Cand stabilizam copiem ultimul trunk in release/ si testam un pic (o saptamana) pana e stabil. Abia dupa asta migram live pe ultimul release, si facem doar fix-uri pentru bug-uri majore. Ideal ar fi sa nu scriem in release dupa ce migram site-ul live.

Cand stabilizam copiem ultimul trunk in release/ si testam un pic (o saptaman) pana e stabil. Abia dupa asta migram live pe ultimul release, si apoi facem doar fix-uri pentru gauri majore. Ideal nu ar trebui sa scriem in release dupa ce migram site-ul live.

h3. Cum alegem tehnologie

h3. Ce se intampla cu infoarena2 si trac.

Infoarena2 intra in maintenance-only mode; unde nu reparam decat chestii foarte necesare. Facem release 2.1.5 si trecem la layout-ul de repository propus pentru infoarena3. Bagam toate tichetele intr-un milestone de "Infoarena 2.99 blue-sky" si mutam in 2.1.6 doar tichetele pentru care putem asigna un om.

Infoarena2 intra in maintenance-only mode; unde nu reparam decat chestii foarte necesare. Facem release 2.1.5 si trecem la layout-ul propus pentru infoarena3. Bagam toate tichetele intr-un milestone de "Infoarena 2.99 blue-sky" si mutam in 2.1.6 doar tichetele pentru care putem asigna un om.

Pentru infoarena3 facem tichete de investigare si 2 milestone-uri: "3.0" si "3.99 blue-sky" cu aceasi semnificatie. Momentam lucram in branches/infoarena3, facem switch la trunk cand dam release de 3.0. O sa avem si alte branch-uri de research pentru 3.0.

Pentru infoarena3 facem tichete de investigare si 2 milestone-uri: "3.0" si "3.99 blue-sky" cu aceasi semnificatie. Momentam lucram in branches/infoarena3, facem switch la trunk cand dam release de 3.0.

h3. Barebones read-only site