Integració contínua

La Integració Contínua o Continuous Integration (CI) és una pràctica de desenvolupament de programari on els membres d'un equip integren sovint el seu treball (per exemple, diàriament), donant lloc a múltiples integracions. La integració consisteix en la compilació i execució de les proves de tot el projecte. A cada integració es verifica per generació automatitzada (incloent proves) per detectar errors d'integració al més ràpidament possible.

En l'enginyeria de programari, integració contínua significa l'aplicació contínua dels processos de control de qualitat, en les petites unitats d'esforç, aplicades sovint.

El model d'integració contínua va ser proposat per Martin Fowler l'any 2000.

L'enfocament tradicional

Tradicionalment, en un projecte de programari de grans dimensions, cada equip desenvolupa la part de l'aplicatiu al seu càrrec (normalment durant mesos) i finalment, les parts s'ajunten (o s'integren) per obtenir el producte resultant. Sovint, ningú sap realment el temps que es requereix per completar aquesta integració. La integració en un projecte de desenvolupament del programari sol ser un procés llarg i impredictible.

El concepte d'Integració Contínua

El model d'integració contínua proposa canviar aquesta visió del projecte. Qualsevol desenvolupament individual suposa un treball aïllat que immediatament s'integra en el projecte compartit. D'aquesta manera, qualsevol error d'integració és detectat ràpidament i es pot corregir. Aquest contrast no és el resultat d'una eina costosa i complexa. La seva essència rau en la simple pràctica de tots en l'equip integrar sovint, generalment al dia, contra un repositori de codi font controlat.

Operativa

L'operativa de treball en un entorn d'integració contínua pot resumir-se així:

1. El desenvolupador realitza una còpia de la font integrada actual (o Mainline) en la seva màquina de desenvolupament local. L'entorn ha de disposar d'un Sistema de Control de Codi Font (o Source Code Management System) per realitzar aquest primer pas. El SCMS conté tot el codi font d'un projecte en el seu repositori. L'estat actual del sistema es coneix com a Mainline. En qualsevol moment qualsevol desenvolupador pot crear una còpia controlada del Mainline en la seva pròpia màquina; aquesta acció es diu "check out". La còpia en la màquina del desenvolupador s'anomena una còpia de treball (o " working copy").
2. El desenvolupador realitza les tasques assignades sobre la còpia de treball. S'altera el codi font i s'afegeixen o modifiquen les proves automatitzades per testejar la modificació. Integració contínua suposa un alt grau de les proves que es realitzen automàticament en el programari: Self-testing code.
3. Generació automàtica del nou entorn en la màquina de desenvolupament. Acabada la tasca es realitza una generació automatitzada en la màquina de desenvolupament. És a dir, el codi font de la còpia de treball es compila i vincula en un executable, sobre ella s'executen les proves automatitzades de test. Si tot és correcte, la còpia de treball es considera correcta i pot integrar-se amb el repositori.
4. Pre-integració. Altres persones poden haver integrat canvis en el Mainline, així que, primer s'actualitza aquesta còpia de treball amb els canvis ocorreguts i es reconstrueix. Si la integració supera la compilació i les proves, ja està a punt per formar part del nou Mainline al dipòsit. En cas contrari, ha de solucionar el problema fins obtener una còpia de treball que es sincronitzi correctament amb la Mainline.
5. Integració en la Mainline. Un cop realitzada la construcció adequadament d'una còpia de treball sincronitzada, finalment els canvis es bolquen en la Mainline i, per tant, al dipòsit.
6. Construcció a la màquina d'integració amb el codi Mainline. En aquest punt, es construeix de nou, però aquesta vegada en una màquina d'integració i la base del codi de la Mainline. Només després de superar la compilació i les proves es donen per integrats els canvis.

L'acumulació d'integracions es pot executar manualment, o es pot fer de forma automàtica per programari com Cruise. Usualment s'adverteix el xoc entre dos desenvolupadors quan el segon desenvolupador integra la seva còpia de treball; l'acumulació d'integracions falla. L'error es detecta ràpidament. En aquest punt, la tasca més important és arreglar l'entorn, i obtenir una acumulació que funcioni correctament de nou. En un entorn d'integració contínua, mai has de tenir per molt temps una estada acumulació d'integracions fallida, un bon equip realitza moltes construccions correctes construeix al dia. Les construccions males ocorren de tant en tant i es fixen ràpidament. El resultat és una peça de programari estable que funciona correctament i conté pocs errors. Encara que tothom es desenvolupa fora, comparteix aquesta base estable i el producte resultant mai s'allunya massa d'una Mainline correcta. En conseqüència, es perd menys temps tractant de trobar errors, ja que apareixen ràpidament.

Pràctiques clau que conformen CI eficaç

Mantenir un repositori de codi únic.

Els projectes de programari impliquen una gran quantitat d'arxius que necessiten ser encaixats per construir un producte. Fer un seguiment de tots ells és un gran esforç, sobretot quan hi ha diversos equips o persones involucrades. Per això, en els últims anys han aparegut eines que ajuden en la gestió del codi font (o Source Code Management tools) i són una part integral de la majoria dels projectes de desenvolupament. Realitzen la gestió de la configuració, el control de les versions i / o dipòsits. Com a norma general, és important assegurar-se d'utilitzar un sistema de gestió de codi font decent. El Cost no siga un problema donat que hi ha eines de codi obert (opensource).

• Subversió

Subversion és l'elecció actualment més utilitzada per al repositori de codi obert. (Substitueix a l'eina opensource CVS que segueix sent àmpliament utilitzada, i que és molt millor que res, encara Subversion és l'elecció moderna.). Entre les alternatives comercials, Perforce és l'única eina per la que val la pena pagar. Adquirit el sistema de gestió de codi font, és important que tots els desenvolupadors coneguin on anar a buscar el codi font i com treballar amb el repositori. (Canvi de cultura / metodologia de treball) Tot el que ha de contenir un recull han d'estar en el repositori (incloent: guions de prova, arxius de propietat, sistema operatiu, entorn de desenvolupament de Java, l'esquema de base de dades, les dades, scripts i biblioteques de tercers). Ha de poder construir completament el sistema. És útil també incloure en la construcció del sistema de control de codi font, altres coses amb les quals la gent acostuma a treballar. Les Configuracions IDE són excel·lents per crear manera és fàcil l'entorn de treball de la gent. Una de les característiques dels sistemes de control de versions és que permeten crear diverses branques, per manejar diferents corrents de desenvolupament. Es tracta d'un característica útil, més encara essencial, - però sovint s'usa en excés i genera problemes. El consell és que es mantingui l'ús de les branques al mínim. En particular, quan tenen un recorregut llarg. (Les branques raonables són correccions d'errors de versions anteriors i / o experiments temporals.) En general, el model CI suposa evitar mantenir versions del producte no integrades.

Automatitzar la compilació

Convertir el codi font en un sistema executable sovint és procés complicat que implica compilació, moure arxius, carregar esquemes en les bases de dades, etc. No obstant això, la majoria de les tasques es poden automatitzar. És més, l'automatització és recomanable atès que executar ordres estranys i omplir pantalles de diàleg és una pèrdua de temps i una font d'errors. Els entorns automatitzats de compilacions són una característica comuna dels sistemes. El món Unix els té des de fa dècades, la comunitat Java desenvolupar Ant, la comunitat .NET té Nant i ara compta amb MSBuild. És important que la construcció és fàcil, construir i posar en marxa el sistema amb un sol comandament. Un error comú és no incloure-ho tot en la construcció automatitzada. La construcció ha incloure-ho tot! La regla d'or: si algú porta una màquina verge, es pren el codi font del repositori, i amb l'execució d'un sol comandament (scripts), s'obté un sistema productiu en la nova màquina. La construcció de scripts sovint és particular d'una plataforma o comunitat. Encara que la majoria de projectes Java utilitzen Ant, altres usen Ruby (el sistema Rake Ruby és una eina molt agradable script de compilació). Una bona eina de construcció analitza el que necessita ser canviat, com a part del procés. La forma més comuna és comprovar les dates de la font i els arxius objecte i només compilar si la data d'origen és posterior. Les dependències solen complicar, per exemple, si un arxiu canvia, sobretot aquells que depengui d'ell també ha de ser reconstruït. Els compiladors solen manejar aquest tipus de coses. Un script de construcció ha de permetre construir alternatives per a diferents casos. La majoria d'IDEs tenen algun tipus de procés de gestió de construcció. No obstant això, aquests arxius són sempre propietat de l'IDE i, sovint fràgil. A més necessiten l'IDE per treballar. Està bé per als usuaris d'IDE establir els seus propis arxius de projecte i els utilitzen per al desenvolupament individual. No obstant això, és essencial comptar amb una construcció principal que es pot utilitzar en un servidor i executable des d'altres scripts.

Self-Testing (o autodiagnòstic)

Tradicionalment una construcció significa compilar i enllaçar tot el material addicional que es requereix per aconseguir un programa a executar. Un programa pot executar-se, però això no significa que sigui correcte. Els llenguatges moderns de tipus estàtic poden caçar molts errors, però molts altres se'ls escapen. Una manera més ràpida i eficaç de detectar els errors és incloure proves automatitzades en el procés de construcció. El testeig no és perfecte, però detectar un munt d'errors - prou com per ser útil. En particular, l'augment de la Programació Extrema (XP) i Desenvolupament Basat en Proves o Test-Driven Development(TDD) han popularitzat l'autodiagnòstic (self- testing) i han fet veure el valor de la tècnica. TDD i XP posen l'accent en escriure les proves abans de desenvolupar el codi. El codi d'autodiagnòstic necessita un conjunt de proves automatitzades que permeti comprovar la major part del codi. Les proves s'han de poder llançar amb una ordre simple i ser auto- comprovatives. El resultat de l'execució del conjunt de proves ha d'indicar si les proves van fallar. La decisió del testeig ha de causar la fallada de la construcció. En els últims anys l'auge de TDD ha popularitzat la família d'eines de codi obert xUnit que són ideals per a aquest tipus de proves. Aquestes eines fan que sigui molt fàcil configurar totalment un entorn autodiagnòstic. Altres eines que se centren a fer més proves d'extrem a extrem són FIT, Selenium, Sahi, Watir, FitNesse. Per descomptat no poden existir proves per a tot. Les proves no demostren l'absència d'errors. De totes maneres, proves imperfectes executades sovint són molt millors que proves perfectes que mai es realitzen.

Tothom es compromet tots els dies amb la Mainline

La integració és principalment comunicació. La integració permet que els desenvolupadors comparteixin els canvis realitzats. L'únic requisit previ és que tot desenvolupador ha de comprometre amb la Mainline, és a dir, amb construir correctament el codi. Això, per descomptat, inclou a passar les proves de generació. Com amb qualsevol cicle, el desenvolupador primer actualitza la seva còpia de treball en la seva màquina local perquè coincideixi amb la Mainline. Si els seus canvis passen la construcció, llavors és lliure d'actualitzar (commit) la Mainline. En repetir aquest procés sovint, els desenvolupadors descobreixen ràpidament els conflictes entre desenvolupadors. La clau per solucionar problemes amb rapidesa és trobar ràpidament, quan encara són fàcils de resoldre. Com a regla general, cada desenvolupador s'integri amb el repositori de tots els dies. A la pràctica, és útil que es faci amb més freqüència. Els Commits freqüents animar que els desenvolupadors trenquin el seu treball en trossos petits (d'un parell d'hores). Això ajuda a rastrejar el progrés i proporciona un sentit de progrés. Sovint inicialment les persones senten que no poden fer alguna cosa significativa en tan sols unes hores, però la tutoria i la pràctica ajuden a aprendre.

Cada Commit ha de construir la Mainline en una màquina d'Integració.

Usant commits diaris, un equip obté construccions provades sovint. És a dir, manté una Mainline saludable. A la pràctica, però, les coses encara poden anar malament. Una de les raons és la disciplina : no fer el procés complet abans del commit. Una altra font de problemes sol ser les diferències en els entorns, especialment entre les màquines dels desenvolupadors. En conseqüència, la construcció es realitza sobre una màquina d'integració abans de realitzar sobre el dipòsit. El corol·lari és que ningú se'n va a casa fins que el Mainline s'ha construït incorporant tots els afegits del dia. Hi ha dues formes d'assegurar la coherència del Mainline :

• utilitzar una construcció manual o
• un servidor d'integració continua.

L'enfocament de construcció manual és més senzill de descriure. Essencialment és similar a la construcció local que realitza el desenvolupador abans del commit al repositori. A la màquina d'integració, el desenvolupador comprova l'últim Mainline (que inclou els commit realitzats per altres desenvolupadors des que ell va fer la seva còpia de treball i el seu últim commit) i dona inici a la construcció d'integració. Un servidor d'integració contínua actua com a pantalla per al repositori. Cada vegada que un commit al repositori acaba el servidor comprova automàticament les fonts a la màquina d'integració, comença una compilació, i notifica al confirmador del resultat de l'acumulació. El confirmador no es fa fins que arribi la notificació - en general un correu electrònic. Moltes organitzacions fan regularment construccions de forma planificada, per exemple, com cada nit. Això no és el mateix que una acumulació contínua i no és suficient per a la integració contínua. El punt d'integració contínua és trobar problemes tan aviat com sigui possible. Els errors d'una construcció nocturan triguen a ser detectats. Una part fonamental de la construcció contínua és que si falla la construcció de la Mainline, s'arregli immediatament. Quan els equips estan introduint CI, sovint aquesta és una de les coses més difícils de resoldre. Al principi, un equip ha de lluitar per consolidar l'hàbit regular de treball de la Mainline (especialment si es treballa amb codi ja existent). La paciència i l'aplicació constant són el truc.

Agilitzar la construcció

L'objectiu d'integració contínua és proporcionar una ràpida retroalimentació. Una construcció que dura més d'una hora és poc raonable. Per a la majoria dels projectes, però, la directriu XP de construir en deu minuts és perfectament raonable. Val la pena posar concentrar en l'esforç per reduir el temps de construcció, per assegurar que es segueix el model i s'estalvia gran quantitat de temps. Les construccions llargues són descoratjadores. A l'empresa, el coll d'ampolla habitual són les proves - en especial les proves que involucren serveis externs, com una base de dades. Les canonada de desplegament (o canonada de construcció o de construcció per etapes) consisteix a llançar diverses construccions en seqüència. El commit a la Mainline llança la primera construcció. La commit build és la construcció que es necessita quan algú vol fer commit a la màquina; s'ha de realitzar ràpid i com a resultat pot perdre eficiència en la detecció d'errors. El truc és equilibrar la detecció d'errors amb la velocitat per obtenir un Mainline prou estable. Un exemple senzill és una canonada de desplegament en dues etapes. La primera etapa seria fer les proves de compilació i d'execució que són les proves unitàries més localitzades amb la base de dades totalment apagat. Aquestes proves poden córrer molt ràpid, mantenint dins de la directriu de deu minuts. Però qualsevol error que impliquen interaccions de major escala, en particular els relacionats amb la base de dades real, no s'inclouen. La segona etapa de construcció s'executa un conjunt diferent de les proves que assoten la base de dades real i que impliquen un comportament més d'extrem a extrem. Aquesta suite pot trigar un parell d'hores per córrer. En aquest escenari la gent fa servir la primera etapa com commit build (construcció commit) i l'utilitzen com el seu cicle principal de CI. La segona etapa de construcció es fa quan es pot, prenent com a punt de partida l'última commit build sobre la qual es van executar les proves. Si falla aquesta construcció secundària, llavors s'ha "d'aturar tot" per qualitat, i l'equip solucionar els errors el més ràpid possible. El principi bàsic d'aquest exemple d'una canonada de dues etapes, es pot ampliar a qualsevol nombre d'etapes posteriors. La construeix després de la commit build també es pot fer en paral·lel, de manera que es pot millorar la capacitat de resposta en tenir dues màquines on s'executen les proves. Mitjançant l'ús construeix secundària paral·leles es pot introduir tota mena de proves més automatitzades, incloent les proves de rendiment, en el procés de construcció regular.

Prova en un clon de l'entorn de producció

L'objectiu de les proves és eliminar, en condicions controlades, qualsevol problema que el sistema pogués tenir en la producció. En aquest context, l'entorn és important. Si les proves es realitzen en un entorn diferent, totes les diferències es tradueixen en riscos. Com a resultat, configurar un entorn de proves imitació exacta possible a l'entorn productiu: mateix programari de base de dades, amb les mateixes versions, mateixa versió de sistema operatiu, totes les biblioteques que es troben a l'entorn de producció (encara que el sistema no utilitza realment), les mateixes adreces IP i ports, el mateix maquinari, etc. Alguns entorns de producció poden ser prohibitives de duplicar, malgrat aquests límits, l'objectiu ha de continuar sent duplicar l'entorn de producció en el possible, i acceptar els riscos que suposa les diferències entre l'entorn de proves i el de producció.

Que sigui fàcil per a qualsevol persona per a obtenir les últimes Executable

És molt difícil especificar el que desitja per endavant i de forma correcta, a la gent li resulta molt més fàcil veure alguna cosa encara que no estigui del tot bé i dir com hauria de ser. Els processos de desenvolupament àgils s'aprofiten d'aquesta conducta humana. Qualsevol que estigui involucrat amb un projecte de programari ha de poder aconseguir la versió executable i ser capaç d'utilitzar per a demostracions, proves exploratòries, o simplement per veure els canvis de la setmana. Quan se segueix un procés amb iteracions ben definides, és típicament prudent incloure també el final de la iteració. Les demos, en particular, necessiten un programari amb característiques familiars, de manera que, en general val la pena sacrificar l'últim per una cosa que se sap com operar.

Visibilitat: tothom pot veure el que està passant

Integració contínua té a veure amb la comunicació, de manera que pot mirar tothom pot veure fàcilment l'estat del sistema i els canvis que s'han fet a ell. Si es fa servir un procés CI manual, aquesta visibilitat segueix sent essencial. El monitor de la màquina de construcció física mostra l'estat de la construcció de la Mainline. Les pàgines web de servidors de CI poden mostra més informació, és clar. Cruise ofereix una indicació no només del que és la construcció, però el que els canvis que han fet. Cruise ofereix un historial de canvis, el que els membres de l'equip per obtenir un bon sentit de l'activitat recent en el projecte. La informació no només consisteix en pantalles de l'ordinador. Un calendari anual a la paret on tots els dies el grup QA posa un adhesiu verd si s'ha construït una versió estable o vermella, en cas contrari, ja compleix amb l'objectiu d'informar.

Automatitzar la implementació

La integració contínua necessita múltiples entorns: un per executar cometre proves, un o més per executar les proves secundàries. Com s'estan movent executables entre aquests entorns diverses vegades al dia, ha automatitzar. Per tant, és important comptar amb scripts que permetin desplegar l'aplicació amb facilitat en qualsevol entorn. Si s'implementa en producció una capacitat automatitzada extra que ha de considerar és el rollback automàtic. Les coses dolentes succeeixen de tant en tant, i és bo ser capaç de tornar ràpidament a l'últim estat correcte conegut. Ser capaç de revertir automàticament també redueix molt la tensió del desplegament, animant a la gent per desplegar amb més freqüència. (The Ruby on Rails comunitat va desenvolupar una eina anomenada Capistrano que és un bon exemple d'una eina que fa aquest tipus de coses.) Una variant particularment interessant d'això per a les aplicacions web és la idea de desplegar una versió de prova per a un subconjunt d'usuaris. Posteriorment, l'equip veu com s'utilitza la build de prova abans de decidir si s'ha d'implementar definitivament. Això li permet provar noves característiques i les interfícies d'usuari abans de comprometre a una decisió final. La implementació automatitzada, juntament amb una bona disciplina CI, és essencial per fer aquest treball.

Beneficis de la Integració Contínua

El major i més ampli en benefici de la integració contínua és reduir el risc. El problema de la integració ajornada és la dificultat d'estimar la seva durada, i pitjor encara, visualitzar el punt de progrés del procés. En altres paraules, la integració suposa un punt cec en una de les parts més tenses d'un projecte. La integració contínua resol el problema. En tot moment, es coneix on es troba, què funciona, què no i quins són els errors més significatius del sistema. Els errors del programari - aspectes desagradables que destrueixen la confiança, fan enfadar als usuaris, fer malbé les horaris i malmeten la reputació - s'identifiquen abans i es redueixen dramàticament. Les integracions contínues no es desfà dels errors, però sí que els troba i elimina abans. Els canvis estan frescos en la seva memòria i per tant, els errors són més és fàcils de trobar. A més permet utilitzar la depuració diff que compara la versió actual del sistema a una anterior que no contenia l'error. Els errors solen ser acumulatius. Com més errors que tens, més difícil és eliminar cada un. Els errors interaccionen entre ells, de manera que un error és, en realitat el resultat de múltiples errors - fent-los més difícil d'identificar. També hi ha un aspecte psicològic: enfrontada a molts errors, la gent es desmotiva (síndrome de les finestres trencades). Com a resultat, els projectes amb integració contínua tenen menys errors espectaculars, tant en producció com durant el procés de desenvolupament. No obstant això hi ha una relació directa entre la qualitat del joc de proves i el benefici descrit, un bon conjunt de proves, encara que difícil de definir, marca la diferència. També és important destacar que, en general, requereix un temps arribar al nivell baix d'errors. Significa treballar constantment a millorar les proves. En entorns d'integració contínua, s'elimina un dels majors obstacles per al desplegament freqüent. El desplegament freqüent és valuosa per als usuaris, ja que permet definir noves característiques més ràpidament, donar més ràpida retroalimentació sobre aquestes característiques, i en general tenir usuaris més col·laboratius en el cicle de desenvolupament. És a dir, el desplegament freqüent ajuda a trencar barreres entre els clients i el desenvolupament - que són el major obstacle per a l'èxit en el desenvolupament de programari.

Presentació d'integració contínua

Quan un projecte es planteja provar la Integració Contínua, per on començar? No hi ha una recepta fixa aquí - molt depèn de la naturalesa de la seva instal·lació i equip. Però aquí hi ha algunes lliçons apreses que funcionen. Un dels primers passos és obtenir la construcció automatitzat. Obtingui tot el que necessita en relació al control de codi font de manera que es pugui construir tot el sistema amb un sol comandament. És essencial perquè funcionin la resta de coses i, per a molts projectes no és una tasca menor. Inicialment pot simplement fer un recull nocturna automatitzada. Donar a conèixer algunes proves automatitzades en la seva construcció. Intenta identificar les principals àrees on les coses van malament i obtenir proves automatitzades per exposar les fallades. Particularment en un projecte existent on és difícil aconseguir un bon conjunt de proves que funcionin amb rapidesa - es necessita temps per construir les proves. Intenta accelerar la construcció de commit. La integració contínua amb una construcció d'unes poques hores és millor que res, però arribar a aquest nombre màgic deu minuts és molt millor. Això normalment requereix una cirurgia bastant seriosa a la base de codi per trencar les dependències en les parts lentes del sistema. Si va a iniciar un nou projecte, començar amb la integració contínua des del principi. Mantingueu un ull en els temps de construcció i de prendre mesures tan aviat com comenci a anar més lent que la regla de deu minuts. Per sobre de tot aconseguir una mica d'ajuda. Trobi a algú que ha fet d'integració contínua abans que l'ajudi. Igual que qualsevol nova tècnica que és difícil introduir quan no sap a què s'assembla el resultat final s'assembla. Aconseguir un mentor pot costar diners, però també té un cost el temps perdut i la productivitat.

Referències

• Artículo de Martin Fowler
• Pragmatic Automation: Libro Arxivat 2008-07-04 a Wayback Machine. o Web Arxivat 2009-01-07 a Wayback Machine.
• Continuous Integration Tools Directory