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 cal 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í: 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"). 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. 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. 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. 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. 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 cal 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.