joi, decembrie 13, 2012

DEVOPS


Devops este o miscare care incearca sa lege doua domenii distincte: dezvoltare si operational poate nu neaparat prin intarirea colabrarii intre cele 2 departamente ci prin extinderea atributiior echipei de dezvoltare si in domeniul operational.


Acesta se inscrie in trendul actual in care dezvoltatorii pot sa ii inlociasca aproape total pe toti ceilalti oameni din firma (eu sincer nu as angaja intr-o firma decat dezvoltatori experimentati):

  • managerii de proiect - prin metodologii agile in care echipa este self managed, rolul de managementului de proiect dispare; desigur ramane high management-ul
  • testeri  - prin teste functionale automate se acopera o data pentru totdeauna testarea aplicatiei; daca apare un bug se fixeaza si se face un test automat care sa semnaleze regresia; este nevoie de testeri doar pentru ca acestea sa faca doar teste exploratorii
  • analistii de business - prin teste de acceptanta automate (executable specifications) dezvoltatorii pot sa interactioneze singuri cu clientii sa scrie specificatiile in cod :)
  • operational - oamenii care se ocupa de environmente, infrastructura si mentinerea aplicatii in productie pot fi inlociti cu scripturi automate de build, deploy, instalare de environmnets, etc

Automizarea (Automation - let the computer doing the repetitive stuff, you can do the interesting part) este cuvantul de baza. Automatizarea testelor (unitare, de integrare, functionale), build-ului, deployment-ului (in dev, test, prod), etc. aduce cu sine cateva aspecte foarte interesante:
  • spre deosebire de executarea manuala de catre o persoana a unui numar de pasi, un script automat trebuie facut o data si se executa de nenumarate ori
  • calculatorul nu poate face erori (omul este predispus la greseli)
  • daca apar erori inseamna ca ceva a fost schimbat intre timp si se poate afla din log-uri ce, se fixeaza si data viitoare nu se va mai intampla

Cateva cazuri de automatizare

  • Build (ant, maven, gradle) - procesul prin care se obtine un binar deployabil (sau chiar se deployaza) din surse
  • Continous integration - prin folosirea unui server de integrare se garanteaza ca pe trunk avem o versiune stabila si integrata a aplicatiei gata de a fi deployata
  • Automatic deployment - procesul de deployment este automatizat (cloud: cloudfoundry, amazon beanstalk, virtualization: - vmware)
  • Continous delivery - permite ca prin apasarea unui buton sa obtinem o versiune noua in productie sau pe unul din environmente (cateva minute); exemplu: update de pe SVN, build and make war (compile, execute unit tests, packaging), upload on cloud, deploy, verify with smoke tests, execute automate acceptance (eventual rollback automat)
  • Deployment pipeline (cel mai inalt nivel) -  folosind tool-uri ca Go, Jenkins (plgin in sine sau posibilitatile de a face trigger de job din alt job) se creaza un proces prin care printr-un singur commit in SVN se executa testele unitare, se face build, se deployaza pe un mediu de staging, se executa testele functionale automate; urmeaza ca un operator uman sa face teste exploratorii si oricand sa decida ca un release candidate poate fi pus in productie

Environments reprezinta masini fizice (diverse OS-uri: Windows, Linux), masini virtuale (VMWARE, EC2) sau simple servere de aplicatii (sau mai simpu aplicatii deployate in acelasi server de aplciatii). Edeea de baza este aceea de a migra aplicatia dn mediul de dezvoltare spre cel de productie incercand sa aducem in productie o aplicatie cat mai stabila cu putinta. Cateva tipuri de enironmente (fiecare firma foloseste propria denumire si semantica): dezvolate (DEV - masina fiecarui dezvoltator, DREF, DINT - integrarea dev), testare(TEST, T1, UAT - user acceptance testings, STAGING - pre-production), productie (PRODUCTION). De la stanga la dreapta este trecerea din dezvoltare spre productie trecand prin testare. Test si production trebuie sa fie foarte asemanatoare (spre exemplu clusterizate in acelasi mod, acelasi soft instalat) pentru a nu avea surprize de genul: problemele nu se pot reproduce.

Productia este cel mai important environment. Toate deploy-urile facute in poductie trebuie sa fie stabile (trecute prin environmentele de testare - testate manual sau automat). Trebuie sa existe posibilitatea de rollback automat - binare (folosind upload history), baze de date (folosind LiquBase sau DBDeploy), cozi de mesaje, etc. Back-up la baza de date de fiecare data cand se face deploy. Este de preferat ca acelasi binar (war, ear) sa treaca perin toate environmentele pan ajunge in productie pentru a evita situatii neplacute. Deploy-ul in productie trebuie sa se faca automat la fel ca in toate celelate environmente (folosind WS API, etc), prin apasarea unui buton putand duce in productie orice modificare de cod (o anumita revizie de pe SVN).

Source control (SVN sau distributed:Git, Mercurial) reprezinta locul in care se afla tot: cod + teste, configurari de aplicatie (deploy), scripturi de build, scripturi de baza de date, etc. Teoretic nimic nu trebuie sa stea inafara - este de preferat sa nu se faca nici un pas manual - ar fi de preferat ca un environment sa fie provizionat si configurat la randul lui din scripturi (Puppet, CHEF) pe langa API-ul care il ofera pentru opearatii de deploy (AWS API, VMWARE API, etc). Orice trebuie sa fie repetabil - reproductibil.

Skills

Ca dezvoltator trebuie sa-ti mentii skill-urile de Linux (Windows) shells scripting (eventual AIX sau alte OS-uri).

Sa stii sa configurezi Hudson (Jenkins) sau orice alt CI server - de fapt as spune ca serverul de integrare devine un fel de panou de control a toate. In fapt el ofera suport pentru integrare cu SVN, are integrare cu uneltele de build, etc. Jenkins este pluginabil, cateva plugin-uri interesante peste cele deja instalate care pot ajuta la deployment pipeline: Jenkins Email Extension Plugin, EnvInject Plugin, build-name-setter, Subversion Release Manager plugin, Jenkins Parameterized Trigger plugin

Folosirea si cunoasterea unui ALM (Application Lifecycle Management) spre exemplu:  JIRA+Confluence+Stash+Bamboo -> Atlassian, IBM Rational solution for Collaborative Lifecycle Management -> IBM sau ThoughtWorks Studios (Mingle+Go+Twist) -> ThoughtWorks, ar aduce un plus de claritate in procesul de dezvoltare.

Probleme care pot aparea

  • Branches hell (pentru clienti diferiti sau pentru fixare de release-uri)
    • a se folosi feature-uri activate/dezactivate
    • a se folosi release-uri la o versiune data (a given version from SVN)
  • Dependencies hell (Maven IVY)
    • a se folosi repository de artefacte
  • Accelerarea deployment-ului in productie
    • nightly build (deploy)