Cuinant el pastís de DevOps

Dev VS Ops

Inici » Actualitat »

Cuinant el pastís de DevOps

El moviment DevOps no té una definició oficial. És més, hi ha gent que li diu “cultura” o “filosofia”, fins i tot no ens posem d’acord a dir que és exactament. En el que si estem d’acord, és en què tot això va del fet que els departaments de desenvolupament i sistemes treballin de forma més alineada, amb l’objectiu comú de la satisfacció de l’usuari.

El moviment DevOps no té una definició oficial. És més, hi ha gent que li diu “cultura” o “filosofia”, fins i tot no ens posem d’acord a dir que és exactament. En el que si estem d’acord, és en què tot això va del fet que els departaments de desenvolupament i sistemes treballin de forma més alineada, amb l’objectiu comú de la satisfacció de l’usuari.

DevOps prové de la filosofia agile de desenvolupament. Aquesta filosofia intenta tenir ràpidament versions funcionals de parts de l’aplicació i així poder respondre a canvis en els requeriments. Si aquesta “agilitat” no arriba fins al moment de posar l’aplicació en desenvolupament, ens topem amb un mur que fa que tot el sistema grinyoli. DevOps intenta fer caure aquesta barrera afegint automatització als processos.

El camí cap a DevOps està fet de petites passes i moltes vegades es presenta com un pastís per capes, que hem d’anar implementant i madurant per tenir una base sòlida per les capes superiors. Vegem-les una mica, de baix a dalt:

DevOps cake

Integració Continua

La integració contínua consisteix a integrar (és a dir, posar en comú) els canvis que es fan al codi per part de tots els membres de l’equip com més aviat millor. La idea és que quan abans s’integri, si fem un canvi que afecta una part del codi que està tocant una altra persona, ho podrem saber ràpidament i fer les correccions de forma més fàcil que si ho detectem dies després.

Aquesta integració normalment el que vol dir és que pugem els nostres canvis a un control de versions centralitzat i que un sistema d’integració continua agafa aquests codis i comprova que tot està correcte. En un primer pas, això pot voler dir simplement que el codi compila. Aquest pas a més ens evita el famós problema “al meu PC funciona”, ja que s’està construint l’aplicació en un sistema diferent del desenvolupador.

Evidentment, tot això implica que el nostre codi el tenim en un sistema de control de versions, cosa que aquest esquema ja es dona per suposada. El control de versions seria la taula on posaríem el pastís, una fase prèvia sense la qual no té sentit tota la resta.

El sistema més utilitzat per fer integració continua és Jenkins, el majordom que podem programar perquè ens faci la feina per nosaltres, però tenim també altres opcions com la pròpia eina que porta gitlab.

Si voleu saber més sobre la integració contínua, el nostre company Sergio va fer un interessant article fa uns mesos, Aplicació de sistemes d’integració continua.

Testos automatitzats

Els testos unitaris són testos ràpids que es poden passar a la màquina de desenvolupament, però podem tenir testos molt més complexos (com ara els d’integració i d’interface d’usuari) que tarden una estona a executar-se. El millor moment per executar-los és quan el sistema d’integració contínua construeix l’aplicació. Podem per exemple aixecar una base de dades amb dades conegudes, posar en marxa l’aplicació i aplicar testos que poden tardar fins i tot minuts. Si alguna cosa va malament, ja rebrem un mail informatiu sense haver-nos d’esperar que s’executin a la nostra màquina.

Executar testos unitaris, d’integració i d’interface ens dóna una molt bona xarxa de seguretat que ens assegura que hi ha bastantes probabilitats que si passen tots, el que hem desenvolupat funcioni correctament.

Si voleu més informació, la nostra companya Flor va fer un interessant article sobre com afegir testos d’interface d’usuari basats en Selenium a un projecte maven. A l’inLab, aquests testos ens els executa Jenkins amb la seva amabilitat característica.

Base de dades àgil

Aquest és un concepte que moltes vegades oblidem quan tractem el tema de DevOps i que en segons quins sistemes és de vital importància. Quan parlem de codi, tenim molt assimilat que s’ha d’utilitzar un sistema de versions, però en canvi la base de dades és un món a part.

Suposem que tenim un canvi al nostre programa que afegeix un camp a la base de dades. Al nostre control de versions tindrem les modificacions del codi perquè hi doni suport i també de les pantalles de visualització, però… i les dades? Si tenim una aplicació antiga, molt probablement no controla la base de dades i haurem de fer a mà els canvis, però haurem d’anar amb compte de tenir una forma de fer els canvis i de tirar-los enrere si hi ha algun problema.

L’única forma de fer això serà que les modificacions a la base de dades doncs també siguin codi: fitxers sql on puguem especificar els canvis associats a un cert commit. És el que es coneix com a migracions: fitxers amb els petits canvis incrementals que fem a l’esquema de la base de dades per “migrar-la” de versió.

En el món Java, l’eina més coneguda per aquestes tasques és Flyway. De totes maneres, no és més que un “executor” que no ens privarà de qualsevol canvi a la base de dades haurà de ser via aquesta eina i mai directament. La disciplina aquí és vital.

Entrega continua

L’entrega contínua és el pas següent a la integració contínua. No només som capaços de construir l’aplicació sinó que un cop passats els testos i els canvis de la base de dades som capaços de passar a aquesta aplicació a entorn de preproducció o fins i tot de producció de forma automàtica.

No hem de confondre l’entrega contínua (continous delivery) amb el desplegament continu (continous deployment). Quan parlem d’entrega, fem referència a deixar preparat el paquet de l’aplicació, però no a passar-lo a producció. En el moment en què el procés és prou madur, un pas més pot ser passar-la de forma automàtica a producció. Això no sempre és possible ni desitjable, ja pot ser que per polítiques diverses no es pugui passar a producció en qualsevol moment, sinó de forma controlada.

De totes maneres, aquest no és el final del nostre camí, sinó que encara que queda un pas més.

Infraestructura com a codi

Un cop tenim automatitzat com passar del nostre codi al servidor de producció encara ens queda un últim pas: poder especificar la configuració del servidor també a partir de codi, de forma tot estigui automatitzat i documentat, passant d’un servidor “pelat” a la nostra aplicació funcional.

Una forma simple de fer això pot ser utilitzar Docker. Amb Docker, podem crear un contenidor amb l’aplicació que inclou informació sobre la configuració del servidor, sense haver d’instal·lar paquets a nivell de sistema.

Docker és tot un món i ens pot facilitar i fins i tot fer-nos replantejar la forma en què despleguem les nostres aplicacions. Jordi Casanovas ens ho va explicar molt bé en un article de fa uns mesos, Docker: a DevOps tool.

Conclusions

Com podeu veure el moviment DevOps és molt ampli. Un món d’eines i d’automatitzacions que portaran de la mà a sistemes i desenvolupament a agilitzar i optimitzar processos i on sempre hi ha lloc per la millora contínua. DevOps és un pastís que es cuina a foc lent.