Tutorial de lliurament continu: crear una canonada de lliurament continu mitjançant Jenkins

Lliurament continu:

El lliurament continu és un procés en què els canvis de codi es construeixen automàticament, es proven i es preparen per a la publicació a la producció.Espero que hagueu gaudit del meu Aquí parlaré dels temes següents:

• Què és el lliurament continu?
• Tipus de proves de programari
• Diferència entre integració contínua, lliurament i desplegament
• Quina és la necessitat d'un lliurament continu?
• Pràctic amb Jenkins i Tomcat

Anem a entendre ràpidament com funciona l’enviament continu.

Què és el lliurament continu?

És un procés on es crea programari de manera que es pugui llançar a la producció en qualsevol moment.Penseu en el diagrama següent:

què és .format a python

Deixeu-me explicar el diagrama anterior:

• Els scripts de compilació automatitzats detectaran canvis en la gestió del codi font (SCM) com Git.
• Un cop detectat el canvi, el codi font es desplegaria a un servidor de compilació dedicat per assegurar-se que la compilació no falla i que totes les classes de proves i proves d'integració funcionen bé.
• A continuació, l'aplicació de compilació es desplega als servidors de prova (servidors de preproducció) per a la prova d'acceptació d'usuaris (UAT).
• Finalment, l'aplicació es desplega manualment als servidors de producció per a la seva versió.

Abans de continuar, només serà just que us expliqui els diferents tipus de proves.

Tipus de proves de programari:

A grans trets, hi ha dos tipus de proves:

• Proves de Blackbox: És una tècnica de prova que ignora el mecanisme intern del sistema i se centra en la sortida generada contra qualsevol entrada i execució del sistema. També s’anomena prova funcional. S'utilitza bàsicament per validar el programari.
• Proves de caixa blanca: és una tècnica de prova que té en compte el mecanisme intern d’un sistema. També s’anomena proves estructurals i proves de caixes de vidre. S'utilitza bàsicament per verificar el programari.

Proves de caixes blanques:

Hi ha dos tipus de proves que pertanyen a aquesta categoria.

• Proves unitàries: És la prova d'una unitat individual o d'un grup d'unitats relacionades. El programador sol fer-ho per comprovar que la unitat que ha implementat produeix una sortida esperada contra una entrada determinada.
• Proves d'integració: És un tipus de proves en què es troba un grup de componentscombinat per produir la sortida. A més, la interacció entre programari i maquinari es prova si els components de programari i maquinari tenen alguna relació. Pot caure tant en proves de caixa blanca com en proves de caixa negra.

Proves de Blackbox:

Hi ha diverses proves que pertanyen a aquesta categoria. Em centraré enuns quants, que és important que conegueu, per entendre aquest bloc:

• Proves funcionals / d'acceptació: Assegura que funciona la funcionalitat especificada requerida als requisits del sistema. Es fa per assegurar-se que el producte lliurat compleix els requisits i funciona tal com esperava el client
• Proves del sistema: Assegura que posant el programari en diferents entorns (per exemple, sistemes operatius) encara funcioni.
• Proves d’estrès: Avalua el comportament del sistema en condicions desfavorables.
• Prova beta: Ho fan els usuaris finals, un equip aliè al desenvolupament o que publiquen públicament una versió prèvia completa del producte coneguda com abetaversió. L’objectiu de les proves beta és cobrir errors inesperats.

Ara és el moment correcte per explicar la diferència entre la integració contínua, el lliurament i el desplegament.

Diferències entre la integració contínua, el lliurament i el desplegament:

El contingut visual arriba al cervell d’una persona d’una manera més ràpida i entenedora que la informació textual. Començaré, doncs, amb un diagrama que explica clarament la diferència:

A la integració contínua, cada lliurament de codi es crea i es prova, però no es pot publicar. Vull dir que l’aplicació de compilació no es desplega automàticament als servidors de prova per validar-la mitjançant diferents tipus de proves de Blackbox, com ara: proves d’acceptació d’usuaris (UAT).

A Continuous Delivery, l’aplicació es desplega contínuament als servidors de prova per a UAT. O bé, podeu dir que l'aplicació està llesta per llançar-se a la producció en qualsevol moment. Per tant, és evident que és necessària una integració contínua per a un lliurament continu.

El desplegament continu és el següent pas més enllà del lliurament continu, on no només creeu un paquet desplegable, sinó que el realitzeu de manera automàtica.

Permeteu-me resumir les diferències mitjançant una taula:

En termes senzills, la integració contínua forma part tant del lliurament continu com del desplegament continu. I el desplegament continu és com el lliurament continu, tret que les versions es produeixen automàticament.

Obteniu informació sobre com es poden crear canonades CI / CD mitjançant Jenkins On Cloud

Però la pregunta és si la integració contínua és suficient.

Per què necessitem un lliurament continu?

Entenguem-ho amb un exemple.

Imagineu-vos que hi ha 80 desenvolupadors treballant en un gran projecte. Utilitzen canonades d’integració contínua per tal de facilitar les construccions automatitzades. Sabem que la compilació també inclou les proves unitàries. Un dia van decidir desplegar la versió més recent que havia passat les proves unitàries en un entorn de proves.

Aquest ha de ser un enfocament de desplegament llarg però controlat que han dut a terme els seus especialistes en entorns. Tot i això, el sistema no semblava funcionar.

Quina pot ser la causa evident del fracàs?

Bé, la primera raó per la qual la majoria de la gent pensarà és que hi ha algun problema amb la configuració. Com la majoria de la gent, fins i tot ells ho pensaven.Van passar molt de temps intentant trobar allò que no funcionava amb la configuració de l’entorn, però no van trobar el problema.

Un desenvolupador perceptiu va adoptar un enfocament intel·ligent:

Aleshores, un dels desenvolupadors principals va provar l'aplicació a la seva màquina de desenvolupament. Tampoc no va funcionar allà.

Va recular les versions anteriors i anteriors fins que va trobar que el sistema havia deixat de funcionar tres setmanes abans. Un petit i fosc error havia evitat que el sistema s'iniciés correctament. Tot i que el projecte va tenir una bona cobertura de proves unitàries.Malgrat això, 80 desenvolupadors, que solen fer les proves en lloc de l'aplicació en si, no van veure el problema durant tres setmanes.

Plantejament del problema:

Sense executar proves d’acceptació en un entorn similar a la producció, no saben res sobre si l’aplicació compleix les especificacions del client, ni si es pot desplegar i sobreviure al món real. Si volen comentaris puntuals sobre aquests temes, han d’ampliar el ventall del seu procés d’integració contínua.

Permeteu-me resumir les lliçons apreses examinant els problemes anteriors:

• Les proves d’unitat només comproven la perspectiva d’un desenvolupador sobre la solució d’un problema. Només tenen una capacitat limitada per demostrar que l'aplicació fa el que se suposa des del punt de vista dels usuaris. No n’hi ha prouidentificar els problemes funcionals reals.
• El desplegament de l’aplicació a l’entorn de prova és un procés complex i intensiu manualment que és força propens a errors.Això significava que cada intent de desplegament era un experiment nou: un procés manual i propens als errors.

Solució: canonada de lliurament continu (prova d’acceptació automàtica):

Van prendre la integració contínua (lliurament continu) al següent pas i van introduir un parell de proves d’acceptació automàtiques senzilles que van demostrar que l’aplicació funcionava i podia realitzar la seva funció més fonamental.La majoria de les proves que s’executen durant l’etapa de prova d’acceptació són proves d’acceptació funcionals.

Bàsicament, van crear una canalització de lliurament continu per assegurar-se que l’aplicació es desplega perfectament a l’entorn de producció, assegurant-se que l’aplicació funciona bé quan es desplega al servidor de prova, que és una rèplica del servidor de producció.

Prou de la teoria, ara us mostraré com crear una canonada de lliurament continu amb Jenkins.

Conducte de lliurament continu mitjançant Jenkins:

Aquí utilitzaré Jenkins per crear una canonada de lliurament continu, que inclourà les tasques següents:

Passos relacionats amb la demostració:

• Obtenció del codi de GitHub
• Compilació del codi font
• Proves d'unitat i generació d'informes de proves de JUnit
• Embalatge de l'aplicació en un fitxer WAR i desplegament al servidor Tomcat

Requisits previs:

• Màquina CentOS 7
• Jenkins 2.121.1
• Docker
• Tomcat 7

Pas 1: compilació del codi font:

Comencem creant primer un projecte Freestyle a Jenkins. Tingueu en compte la captura de pantalla següent:

Posa un nom al teu projecte i selecciona Freestyle Project:

Quan desplaceu-vos cap avall, trobareu una opció per afegir un dipòsit de codi font, seleccionar git i afegir l'URL del dipòsit; en aquest repositori hi ha una multa pom.xml que utilitzarem per construir el nostre projecte. Tingueu en compte la captura de pantalla següent:

qtp vs seleni que és millor

Ara afegirem un Trigger de compilació. Escolliu l’opció poll SCM, bàsicament, configurarem Jenkins per interrogar el dipòsit GitHub cada 5 minuts per obtenir canvis al codi. Tingueu en compte la captura de pantalla següent:

Abans de continuar, permeteu-me fer-vos una petita introducció al cicle de construcció de Maven.

Cadascun dels cicles de vida de construcció està definit per una llista diferent de fases de construcció, en què una fase de construcció representa una etapa del cicle de vida.

A continuació es mostra la llista de fases de construcció:

• validar: validar el projecte és correcte i hi ha tota la informació necessària disponible
• compila: compila el codi font del projecte
• test: proveu el codi font compilat utilitzant un marc de prova unitari adequat. Aquestes proves no haurien de requerir que el codi estigui empaquetat o desplegat
• package: agafeu el codi compilat i empaqueteu-lo en el seu format distribuïble, com ara un JAR.
• verificar: executeu qualsevol comprovació dels resultats de les proves d’integració per garantir que es compleixen els criteris de qualitat
• install: instal·leu el paquet al dipòsit local per utilitzar-lo com a dependència en altres projectes localment
• desplegament: fet a l'entorn de compilació, copia el paquet final al dipòsit remot per compartir-lo amb altres desenvolupadors i projectes.

Puc executar l'ordre següent per compilar el codi font, provar unitats i fins i tot empaquetar l'aplicació en un fitxer de guerra:

paquet mvn net

També podeu dividir el vostre treball de construcció en diversos passos de construcció. Això fa que sigui més fàcil organitzar les construccions en etapes netes i separades.

Començarem doncs, compilant el codi font. A la pestanya de construcció, feu clic a Invoca objectius principals de nivell superior i escriviu l'ordre següent:

compilar

Tingueu en compte la captura de pantalla següent:

Això traurà el codi font del dipòsit de GitHub i també el compilarà (fase de compilació de Maven).

Feu clic a Desa i executeu el projecte.

Ara feu clic a la sortida de la consola per veure el resultat.

Pas 2: proves d'unitats:

Ara crearem un projecte Freestyle més per a les proves d’unitats.

Afegiu el mateix URL del dipòsit a la pestanya de gestió del codi font, com vam fer a la feina anterior.

Ara, a la pestanya 'Buid Trigger', feu clic a la 'compilació després de la creació d'altres projectes'. Allà, escriviu el nom del projecte anterior on compilem el codi font i podeu seleccionar qualsevol de les opcions següents:

• Activar només si la compilació és estable
• Es desencadena fins i tot si la compilació és inestable
• Es desencadena fins i tot si la compilació falla

Crec que les opcions anteriors s’expliquen per si mateixes, per tant, seleccioneu-ne una. Tingueu en compte la captura de pantalla següent:

A la pestanya Crea, feu clic a Invoca objectius principals de nivell superior i utilitzeu l'ordre següent:

prova

Jenkins també us ajuda a mostrar els resultats de les proves i les tendències dels resultats de la prova.

L'estàndard de facto per als informes de proves al món Java és un format XML utilitzat per JUnit. Aquest format també l’utilitzen moltes altres eines de prova de Java, com TestNG, Spock i Easyb. Jenkins entén aquest format, de manera que si la vostra compilació produeix resultats de proves JUnit XML, Jenkins pot generar informes gràfics i estadístiques sobre els resultats de les proves al llarg del temps i també us permetrà veure els detalls de qualsevol error de prova. Jenkins també fa un seguiment del temps que triguen a executar-se les proves, tant a nivell global com per prova. Això pot ser útil si cal rastrejar problemes de rendiment.

Per tant, el següent que hem de fer és aconseguir que Jenkins controli les nostres proves unitàries.

Aneu a la secció Accions posteriors a la creació i marqueu la casella de selecció 'Publica l'informe de resultats de la prova JUnit'. Quan Maven executa proves unitàries en un projecte, genera automàticament els informes de proves XML en un directori anomenat surefire-reports. Per tant, introduïu '** / target / surefire-reports / *. Xml' al camp 'Prova d'informes XML'. Els dos asteriscs al començament del camí ('**') són una pràctica recomanada per fer la configuració una mica més robusta: permeten a Jenkins trobar el directori de destinació, independentment de la forma en què hàgim configurat Jenkins per comprovar el codi font.

** / target / surefire-reports / *. xml

Torneu a desar-lo i feu clic a Crea ara.

Ara, l'informe JUnit està escrit a / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behaviour.

Al tauler de Jenkinstambé podeu notar els resultats de les proves:

Pas 3 Creació d'un fitxer WAR i desplegament al servidor Tomcat:

Ara, el següent pas és empaquetar la nostra aplicació en un fitxer WAR i desplegar-la al servidor Tomcat per a la prova d’acceptació d’usuaris.

Creeu un projecte d'estil lliure més i afegiu l'URL del dipòsit de codi font.

A continuació, a la pestanya activador de compilació, seleccioneu construir quan es construeixin altres projectes, tingueu en compte la captura de pantalla següent:

Bàsicament, després del treball de prova, la fase de desplegament s'iniciarà automàticament.

A la pestanya de compilació, seleccioneu l'script de shell. Escriviu l'ordre següent per empaquetar l'aplicació en un fitxer WAR:

paquet mvn

El següent pas és desplegar aquest fitxer WAR al Tomcatservidor. A la pestanya 'Accions posteriors a la construcció', seleccioneu desplegar war / ear en un contenidor. Aquí, doneu el camí al fitxer de guerra i el camí del context. Tingueu en compte la captura de pantalla següent:

Seleccioneu les credencials Tomcat i observeu la captura de pantalla anterior. A més, heu d’indicar l’URL del servidor Tomcat.

Per afegir credencials a Jenkins, feu clic a l'opció de credencials del tauler de Jenkins.

Feu clic a Sistema i seleccioneu credencials globals.

ordenar matriu en c ++

A continuació, trobareu una opció per afegir les credencials. Feu-hi clic i afegiu credencials.

Afegiu les credencials Tomcat, tingueu en compte la captura de pantalla següent.

Feu clic a D'acord.

Ara, a la configuració del projecte, afegiu les credencials del tomcat que heu inserit al pas anterior.

Feu clic a Desa i seleccioneu Crea ara.

Aneu al vostre URL de tomcat, amb el camí de context, en el meu cas és http: // localhost: 8081. Ara afegiu el camí contextual al final, tingueu en compte la captura de pantalla següent:

Enllaç - http: // localhost: 8081 / gof

Espero que hagueu entès el significat del camí contextual.

Ara creeu una vista de canonades, tingueu en compte la captura de pantalla següent:

Feu clic a la icona del signe més per crear una vista nova.

Configureu la canonada de la manera que vulgueu, tingueu en compte la següent captura de pantalla:

No vaig canviar res a part de seleccionar la feina inicial. Per tant, la meva canonada començarà des de la compilació. Segons la forma en què he configurat altres treballs, després de realitzar les proves de compilació i el desplegament.

Finalment, podeu provar la canonada fent clic a RUN. Després de cada cinc minuts, si hi ha un canvi en el codi font, s'executarà tota la canonada.

Per tant, podem desplegar contínuament la nostra aplicació al servidor de prova per a la prova d’acceptació d’usuaris (UAT).

Espero que us hagi agradat llegir aquest post sobre Lliurament continu. Si teniu cap dubte, no dubteu a posar-los a la secció de comentaris que hi ha a continuació i, al més aviat, us respondré amb una resposta.

Per construir canonades de CI / CD, cal dominar una àmplia varietat d’habilitats Domineu ara les habilitats necessàries de DevOps