Diferencias

Muestra las diferencias entre dos versiones de la página.

--- clase:daw:daw:tema07 [2026/10/28 10:13] – Imágenes del tablero copiadas a clase:daw:daw claude
+++ clase:daw:daw:tema07 [2026/10/28 10:18] (actual) – Quitar la sección «Contenedor con Jenkins»: el concepto ya está en la introducción claude
@@ Línea 8: / Línea 8: @@
   * [[https://geeks.ms/jorge/2019/02/25/integracion-entrega-y-despliegue-continuo-diferencias-y-similitudes/|Integración, entrega y despliegue continuo. Diferencias y similitudes]]
-Es despliegue continuo es desplegar las aplicaciones web lo más pronto posible.
+El despliegue continuo es desplegar las aplicaciones web lo más pronto posible: cada cambio que se sube al repositorio acaba en el servidor sin que nadie tenga que hacerlo a mano.
-Hay varias formas de hacer eso, las 2 que vamos a comentar son:
+Para eso se usa un **servidor de automatización**: un programa que, cuando ocurre algo (un ''push'' a una rama, que alguien pulse un botón, una hora concreta), ejecuta solo una lista de pasos escrita de antemano. Los pasos son los que haríamos nosotros a mano:
-  * [[https://www.jenkins.io/|Jenkins]]
-  * [[https://github.com/features/actions|GitHub Actions]]
+  - Descargar el código del repositorio.
+  - Compilarlo y pasar los tests.
+  - Construir la imagen Docker.
+  - Conectarse al servidor y arrancar la nueva versión.
-===== Contenedor con Jenkins =====
+Si un paso falla, se para ahí y avisa: lo que no compila o no pasa los tests no llega al servidor.
-Jenkins es lo que se llama un "Servidor de automatización".
-{{clase:daw:daw:jenkins_logo.png?200|}}
+Los dos que vamos a ver son:
+  * [[https://www.jenkins.io/|Jenkins]]: un programa que instalamos nosotros en un servidor nuestro (por ejemplo, en un contenedor Docker) y que vigila los repositorios.
+  * [[https://github.com/features/actions|GitHub Actions]]: viene incluido en GitHub. No hay que instalar nada: los pasos se escriben en un fichero dentro del propio repositorio y los ejecutan máquinas de GitHub.
-Hay abundante documentación sobre él , en los siguientes enlaces:
+^ ^ Jenkins ^ GitHub Actions ^
-  * [[https://www.jenkins.io/|Jenkins]]: Página del proyecto.
+| Dónde se ejecuta | En un servidor nuestro | En máquinas de GitHub |
-  * [[https://www.javiergarzas.com/2014/05/jenkins.html|¿Qué es Jenkins? Explicado en menos de 10 min para quienes no lo conocen de nada]]
+| Hay que instalarlo y mantenerlo | ✓ | |
-  * [[https://www.arsys.es/blog/programacion/jenkins-cloud-integracion-continua/|Automatiza las tareas de desarrollo e integración continua con Jenkins]]
+| Dónde se escriben los pasos | En Jenkins | En el repositorio, en ''.github/workflows/'' |
-  * [[https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/jenkins-tutorial/|Jenkins: tutorial para esta herramienta de CI]]
+| Sirve para repositorios fuera de GitHub | ✓ | |
-Aunque Jenkins pueda parecer sencillo o superfluo, usar Jenkins //**es el camino**// para hacer software de calidad.:
+Si el proyecto está en GitHub, usa GitHub Actions.
-{{clase:daw:daw:jenkins-is-the-way.png?100|}} {{clase:daw:daw:the_mandalorian.jpg?100|}}
 ===== GitHub Actions =====
-GitHub Actions que son acciones que se ejecutan cuando hay algún cambio en el repositorio o que incluso se pueden ejecutar como queramos (Al estilo de Jenkins)
+Un **workflow** es un fichero YAML dentro de la carpeta ''.github/workflows/'' del repositorio. GitHub lee esa carpeta en cada ''push'': no hay que darlo de alta en ningún sitio. El fichero tiene tres partes:
+  * ''on'': cuándo se ejecuta. ''push'' con ''branches'' cuando se sube algo a esa rama; ''workflow_dispatch'' añade un botón //Run workflow// en la pestaña //Actions// para lanzarlo a mano.
+  * ''jobs'': los trabajos que hay que hacer. Cada uno se ejecuta en un **runner**, una máquina virtual que GitHub crea para la ocasión y tira al acabar. ''runs-on: ubuntu-latest'' dice que sea un Ubuntu.
+  * ''steps'': los pasos de cada trabajo, en orden. Cada paso tiene un ''name'' y hace una de dos cosas:
+    * ''run'': órdenes de shell, como en una terminal. Con ''|'' se ponen varias líneas.
+    * ''uses'': una acción ya hecha por otros, como ''actions/checkout@v3'', que descarga el código del repositorio en el runner.
+Lo que no debe estar en el repositorio (contraseñas, claves SSH, IPs) se guarda como **secreto** en //Settings → Secrets and variables → Actions// y se usa en el workflow con ''%%${{ secrets.NOMBRE }}%%''. GitHub lo oculta en los logs.
+<note important>El runner arranca **vacío**: no tiene nuestro código hasta que se hace ''actions/checkout'', y no tiene nada instalado aparte de lo que trae Ubuntu, así que lo que haga falta se instala en un paso (como el ''apt-get install'' de abajo).</note>
+<note important>El runner está en Internet, no en el instituto: no ve la red del instituto. Por eso el ejemplo de abajo se conecta primero por VPN y luego entra por SSH al servidor.</note>
-Para ello en el código fuente del proyecto Java , hay que añadir el fichero ''.github/workflows/desplegar.yml'' con el siguiente contenido:
+Para desplegar el proyecto Java, hay que añadir al repositorio el fichero ''.github/workflows/desplegar.yml'' con el siguiente contenido:
 <sxh yml>
@@ Línea 91: / Línea 103: @@
 </sxh>
-Ahora al hacer cualquier cambio en la rama ''master'' se ejecutará nuestro script de despliegue
+Ahora al hacer cualquier cambio en la rama ''master'' se ejecutará nuestro script de despliegue.
+Cada ejecución sale en la pestaña //Actions// del repositorio, con cada paso en verde o en rojo y su log. Si un paso falla, los siguientes no se ejecutan.
 Puedes ver un ejemplo en [[https://github.com/lgonzalezmislata/Facturas/tree/master/.github/workflows]]