Pirms kāda laika (nu jau 2 gadiem) mūsu projekta komanda sāka augt no 1.5 programmētājiem līdz 5 (precīzi neatceros). Kods sākotnēji tika versionēts (glabāts) SVN parodijā, ko sauc par Microsoft Source Safe. Ņemot vērā, ka nebūtu godīgi MSS uzskatīt par versionēšanas sistēmu, bet kā sliktu backup tūli vērtu gan. Tad vajadzēja atrast draudzīgu rīku, ar kuru varētu strādāt vairāk kā 1 programmētājs.
Šo problēmu spēja atrisināt divi rīki git un hg. Tātad vajadzēja izvēlēties vienu no abiem. git tai laikā īsti nebija sakarīgas front-end saskarnes, tāpēc ne tik entuziastiskiem programmētājiem varētu nepatikt komandrinda. hg ir ļoti draudzīgs Windows front-ends saukts par TortoiseHg. Ak, jā, mēs visi lietojam Windows, tāpēc Hg iegūst vairāk punktus nekā Git. Papildus, Hg ir diezgan pedantisks, glabājot vēsturi.
Tas var noderēt, lai kontrolētu, kas un ko ir izdarījis.
Produkcijas vides kods glabājas default zarā. Visiem pieteikumiem, kuros jālabo kods, tiek veidots jauns zars no jaunākās revīzijas default zarā. Hg atbalsta named branching, kas ļauj zaram piešķirt nosaukumu. Nosaukumi mūsu gadījumā tiek piešķirti pēc pieprasījuma numura.
Tā kā mums ir vairākas vides - produkcijas un testa, tad vēl tika izveidots .tests zars (ar punktu, lai izvēlnēs būtu pirmais). Piemēram, ja vajag piegādāt dažus pieteikumus testēšanā, tas nozīmē, ka jāveic atbilstošo pieteikumu zaru hg merge ar .tests zaru. Tad, kad visi hg merge ir izveidoti, varam kompilēt un likt uz testa vides. Parasti pēc katra hg merge pārbauda, vai kods kompilējas, ja Nē, tad atceļam hg merge. Pēdējos commit var atcelt ar hg rollback. Prātīgi to darīt tikai tad, ja izmaiņas jau nav aizgājušas uz centrālo glabātuvi, ar kuru visi sinhronizējas.
Runājot par centrālo glabātuvi, mums tāda ir tikai viena. Uz to arī tiek sūtītas visas izmaiņas kodā visos zaros. Testētāji var novilkt izmaiņas no centrālās glabātuves un pārslēgties uz attiecīgā pieteikuma zaru, un nokompilēt, un pārbaudīt, vai viss strādā. Attiecīgi pēc tam nodot testēšanā, atzīmēt, ka pieteikums var doties uz testa vidi - var tikt veikts hg merge ar .tests zaru.
Piegādes uz produkciju var iet divos ceļos.
SVN stilā: .tests zars tiek hg merge iekš default zara - šo variantu mēs neizmantojam, jo ir pārāk ierobežots - mēs varētu piegādāt tikai tad, ja visas izmaiņas .tests zarā ir akceptētas uz produkciju. Tas nozīmē, ka piegādēs būtu lielas ar daudz nopietnām izmaiņām. Visticamāk būtu nepieciešama vairāku testa zaru tagošana, no kuras revīzijas līdz kurai revīzijai piegādāt utt. (SVN laikam savādāk kā šādi nevar).
Otrs variants ir visus pieteikumus, kuri ir notestēti un akceptēti, uz produkciju tiek hg merge ar default zaru - šis variants atļauj piegādāt jebkuras izmaiņas, kas nav funkcionāli saistītas ar citam. Šādam piegājienam ir problēma, ka pastāv lielāka iespēja hg merge konfliktu veidošana jaunu pieteikumu pievienošanai .tests zarā, jo .tests zars var būtu stipri advancējies uz priekšu no default. Atceramies, ka no default zara top visi jaunie pieteikumu zari. Protams to var samazināt visādos veidos, piemēram, kodu strukturējot tā, ka vienā failā ir maz koda rindiņu un ir daudz failu. Laba koda modularitāte arī varētu samazināt funkcionālo atkarību. Lai gan šeit ir problēma, ka nepieciešams veikt testus, lai pārbaudītu, ka jaunās izmaiņas, kas ielikts default zarā tiešām strādā. Šai problēmai pašlaik izsargāšanās metode ir cerība. Un kā pieredze rāda tad tā nav pievīlusi - nav bijušas funkcionalitātes kļūdas slikta merge rezultātā.
Beigās, ja viss ir izdevies un viss kompilējas, tad visas izmaiņas tiek sinhronizētas ar centrālo glabātuvi.
Vēl neizpētīta lieta ir veidot vairāku līmeņu izmaiņu glabāšanu, piemēram, programmētājs savas izmaiņas nesūta uz centrālo, bet gan uz testētāju glabātuvi, un ja viņi ir pārbaudījuši, tad izmaiņas var aizsūtīt uz centrālo glabātu. Šāds modelis varētu būt noderīgs lielām izstrādes komandām, lai kāds (praktikanti) muļķības nesadarītu. Piemēram, nepareizs zaru nosaukums, kods nenoformatēts, vai veidojas hg merge konflikti (testētājs var pārbaudīt vai hg merge neveido konfliktu).