branch-uri de test pentru cfengine
Zilele astea am reusit sa pun in aplicare pe un setup de cfengine o idee veche de-a mea: branchuri de productie/test/devel care sa poata fi schimbate foarte usor.
Prima parte e relativ simpla: fac niste branchuri la tree-ul de cfengine de productie (era deja in version control, nu?) si fac cate un checkout paralel. Pe policyserverul meu cfservd serveste fisiere din /srv/cfengine, asa ca am facut checkouturi in /srv/cfengine/PROD si /srv/cfengine/TEST.
Dupa aceea, am declarat atat in update.conf cat si in cfagent.conf in sectiunea control o variabila branch = ( PROD ) si inca una gen master_policy_root = ( /srv/cfengine/$(branch) ) si m-am asigurat ca in toate sectiunile copy care se refera la copierea de pe policyserver folosesc cai sursa de forma $(master_policy_root)/inputs samd.
Pauza de tigara si verificat ca merge totul (atentie si la acl-urile din cfservd.conf de pe policy master).
Pasul 2 aduce diferenta intre cele 2 branchuri: inlocuiesc linia cu declaratia lui branch cu urmatoarele (exemplu pentru PROD):
#defaults to the PROD branch unless called with -D branch_test branch_test:: branch = ( TEST ) !branch_test:: branch = ( PROD )
In branchul de test scriu branch_prod in loc de branch_test si inversez PROD cu TEST (relativ evident). Daca sunt mai mult de doua branchuri se adauga cate o declaratie pentru fiecare alt branch in care se doreste sa se poata trece din cel curent.
Ce se intampla acum? Pai am exact configuratia metastabila pe care mi-o doream: implicit un agent ramane pe branchul pe care l-a copiat ultima oara, cu exceptia cazului cand primeste manual clasa branch_test (cu -D fie din linie de comanda, fie cu cfrun). Un singur apel de forma cfrun server042 -- -D branch_test asigura ca server042 va folosi configuratia din /srv/cfengine/TEST pana la loc comanda. Astfel pot avea imediat mediu controlat de test pentru niste modificari not-quite-ready (sau poate cel care editeaza n-are drept de commit in branchul de productie). Acum sa inventez o procedura de edit-test-rollback-commit-merge-release care sa fie relativ usor de urmarit de catre un sysadmin junior, si sa vad daca o fac cu git sau raman cu svn (sunt avantaje si dezavantaje).
Inainte sa inchei, vreau sa notez ca in cazul simplu, cu o singura versiune de test, TEST poate fi checkout din trunk si PROD de pe un tag de release care se avanseaza manual.