Visión general de Classic Delivery Pipeline
DevOps Insights Llegará al final de su vida útil y dejará de estar disponible el 31 de agosto de 2026. Continuous Delivery dejará de estar disponible en las siguientes regiones el 12 de febrero de 2027: au-syd, ca-tor, us-east. Code Risk Analyzer también dejará de estar disponible en todas las regiones a partir de esa fecha. Si en una región no se hace un uso activo de estas funciones, es posible que dichas funciones se retiren antes de lo previsto en esa región y dejen de aceptar nuevas instancias. Más información
IBM Cloud® Continuous Delivery incluye Classic Delivery Pipeline para crear, probar y desplegar de manera repetitiva con una mínima intervención humana. En un conducto, las secuencias de etapas recuperan la entrada y los trabajos de ejecución, como compilaciones, pruebas y despliegues.
Puede trabajar con los canales de entrega Classic y Tekton utilizando el navegador o utilizando el IBM Cloud Comandos CLI Developer Tools(ibmcloud dev). También puede trabajar con los canales
de entrega de Tekton utilizando la API y HTTP los SDK de Tekton, o bien utilizando el proveedor IBM Cloud Terraform.
Para obtener más información sobre los flujos de entrega de Tekton, consulta Trabajar con flujos de Tekton.
Los permisos para ver, modificar o ejecutar un conducto se basan en el control de accesos de la cadena de herramientas que es propietaria del conducto. Para obtener más información sobre el control de acceso para cadenas de herramientas, consulte Gestión del acceso a cadenas de herramientas en grupos de recursos.
Puede especificar los scripts para que se ejecute en muchos de los tipos de trabajo que proporciona el conducto, lo que le proporciona un control directo sobre lo que ejecuta el trabajo. Estos scripts se ejecutan en una imagen de Docker que contiene un número de herramientas de desarrollo estándar, incluidas las herramientas necesarias para interactuar con los tiempos de ejecución de IBM Cloud. Para obtener más información sobre lo que contiene el Docker estándar, consulte Recursos preinstalados. Si el trabajo requiere herramientas de desarrollo que no están disponibles en la imagen estándar o si necesita diferentes versiones de estas herramientas, puede utilizar una imagen personalizada. Para obtener más información sobre las imágenes personalizadas, consulte Trabajar con imágenes de Docker personalizadas.
Cuando el conducto ejecuta scripts, las propiedades que describen el contexto en el que se ejecuta el trabajo se pasan al script utilizando variables de entorno. Por ejemplo, el URL del repo que es la entrada a la etapa, el nombre de la etapa y el trabajo que se está ejecutando, los parámetros especificados por el tipo de trabajo, etc. Para ver una lista de las variables de entorno disponibles, consulte Recursos preinstalados.
Puede definir propiedades tanto en el nivel de conducto como en el nivel de etapa. Las propiedades de conducto se comparten en todas las etapas y trabajos de un conducto. Las propiedades de la etapa son exclusivas de una determinada etapa y se comparten en todos los trabajos de dicha etapa. Para obtener más información sobre las propiedades, consulte Propiedades de entorno (variables de entorno).
Etapas
Las etapas organizan la entrada y los trabajos a medida que se compila, se despliega y se prueba el código. Las etapas aceptan la entrada de repositorios de control de origen (repositorios SCM) o compilan trabajos en otras etapas. Para repositorios SCM, la entrada es el contenido de una sucursal en concreto del repositorio; para los trabajos de compilación, la entrada son los artefactos producidos por el trabajo. Al crear la primera etapa, el separador INPUT contiene los valores predeterminados.
Cuando se ejecuta una etapa, la entrada de la etapa se pasa a cada uno de los trabajos de la etapa. A cada trabajo se le proporciona un contenedor limpio en el que ejecutarse. Como resultado, los trabajos de una etapa no se pueden pasar artefactos
entre sí. Para pasar artefactos dentro de trabajos, separe los trabajos en dos etapas y utilice la salida del trabajo en la primera etapa como entrada a la segunda etapa. Se puede pasar cualquier trabajo de compilación como entrada para cualquier
otro trabajo en otra etapa. De forma predeterminada, la salida se crea en la carpeta ./. Si no desea una salida de un trabajo de compilación, configure una carpeta como salida y no envíe ninguna salida a dicha carpeta.
De forma similar a cómo puede definir las propiedades del conducto, también puede definir las propiedades de la etapa para su uso en todos los trabajos de una etapa determinada. Por ejemplo, podría definir una propiedad TEST_URL que pasa un URL a los trabajos de prueba y despliegue en una etapa. El trabajo de despliegue se despliega en dicho URL y el trabajo de prueba realiza una prueba de la app en ejecución en el URL. Las propiedades de etapa también se pasan a
scripts de trabajo utilizando variables de entorno. Si se define la misma propiedad tanto en el nivel de conducto como en el nivel de etapa, se utiliza el valor de la propiedad de la etapa.
De forma predeterminada en una etapa, las compilaciones y los despliegues se ejecutan automáticamente cada vez que se entreguen cambios a un repositorio SCM del proyecto. Las etapas y los trabajos se ejecutan en serie; permiten el control de flujo para el trabajo. Por ejemplo, puede situar una etapa de prueba antes de una etapa de despliegue. Si las pruebas de la etapa de pruebas fallan, la etapa de despliegue no se ejecuta.
Delivery Pipeline utiliza trabajadores públicos y privados para ejecutar los trabajos en una etapa. De forma predeterminada, los trabajos de conducto se ejecutan utilizando trabajadores públicos en una infraestructura compartida pública gestionada por IBM.
En determinados casos de ejemplo, es posible que Delivery Pipeline requiera acceso a recursos internos o locales. En estas situaciones, puede conectarse e integrar un trabajador privado de Delivery Pipeline para que se ejecute en su propia infraestructura de Kubernetes.
Puede que desee un control más estricto de una etapa específica. Si no desea que se ejecute una etapa cada vez que se produzca un cambio en su entrada, puede inhabilitar la prestación. En el separador ENTRADA, en la sección Desencadenante de etapa, pulse Ejecutar trabajos sólo cuando esta etapa se ejecute manualmente.
{: caption="
Hay más opciones de desencadenante de etapas disponibles para las etapas que utilizan el tipo de entrada del repositorio Git. Por ejemplo, puede optar por ejecutar trabajos automáticamente para sucesos de Git en la rama elegida. Cuando elija este tipo de desencadenante, debe seleccionar uno o más de los tipos de sucesos siguientes:
- Cuando se envía una confirmación se desencadena cuando se realiza un envío a la rama de repositorio seleccionada.
- Cuando se abre o actualiza una solicitud de extracción/fusión se desencadena cuando se abre o se edita una solicitud de extracción o una fusión.
- Cuando se cierra una solicitud de extracción/fusión se desencadena cuando se cierra una solicitud de extracción o fusión, incluso sin una confirmación asociada.
{: caption="
Si marca el recuadro de selección Cuando se abre o se actualiza una solicitud de extracción/fusión, el estado del conducto se devuelve al repositorio Git. Cuando una solicitud de extracción o fusión desencadena el conducto, se muestra en la página una comprobación de estado en línea. Se muestra una comprobación de estado para cada una de las etapas que se ejecutan en el conducto y se proporcionan enlaces a los registros y al historial para cada etapa. A medida que se ejecuta la comprobación de estado, se actualiza de pendiente a satisfactoria o fallida. Si el conducto contiene varias etapas, cada etapa notifica su estado en la lista de comprobación.
Este feedback de estado también recibe soporte de la herramienta GitLab Community Edition alojada por IBM para solicitudes de fusión.
También puede restringir la fusión según los resultados de las comprobaciones de estado utilizando reglas de protección de rama de Git. Después de crear una regla de protección de rama, se bloquea toda fusión hasta que todas las comprobaciones de estado necesarias sean correctas.
Solicitudes de extracción de Bitbucket Cloud
Actualmente, Bitbucket Cloud no da soporte a las referencias de repositorio para las solicitudes de extracción, un elemento necesario para el servicio Continuous Delivery. Esta característica permite enviar las solicitudes de extracción al
repositorio al que desea acceder utilizando las referencias en el formato siguiente: refs/pull/123/…
Puedes descargar y revisar localmente una solicitud de incorporación de cambios utilizando el repositorio de código fuente URL. Sin embargo, si el repositorio de origen es un repositorio bifurcado privado, el servicio Continuous Delivery no tiene el acceso necesario para gestionar solicitudes de extracción. Para solucionar esta limitación, debe proporcionar explícitamente el acceso necesario al repositorio bifurcado en el script de conducto.
En el siguiente script de conducto bash de ejemplo, hay dos usuarios utilizando Bitbucket Cloud y cada uno tiene una bifurcación privada del repositorio principal (bitbucket.org/userA/repo-forked-A y bitbucket.org/userB/repo-forked-B). El script se configura para extraer la solicitud de extracción cuando un suceso abierto o de actualización de una solicitud de extracción de uno de los dos repositorios bifurcados desencadena un trabajo de compilación.
case "$BITBUCKET_PR_SOURCE_HOST" in #BITBUCKET_PR_SOURCE_HOST is an environment exported by pipeline if job is triggered by a bitbucket pull request
*userA*) #userA should be replaced to anything to identify a forked repo's url
url="https://$username:$password@$BITBUCKET_PR_SOURCE_HOST" #you need to provide username and password for repo-forked-A
;;
*userB/repo-forked-B*) #userB/repo-forked-B should be replaced to anything to identify a forked repo's url
url="https://$username1:password1@$BITBUCKET_PR_SOURCE_HOST" #you need to provide username1 and password1 for repo-forked-B
;;
esac
git fetch $url $BITBUCKET_PR_SOURCE_BRANCH #BITBUCKET_PR_SOURCE_BRANCH is an environment exported by pipeline if job is triggered by a bitbucket pull request
git checkout FETCH_HEAD
Etapa de compilación
En la etapa de compilación se especifica un Tipo de compilador para indicar cómo compilar los artefactos.
Muchos de los campos disponibles en trabajos de compilación son comunes en varios tipos de compilador.
Están disponibles los siguientes tipos de compilador:
| Tipo de compilador | Descripción | Tipos de trabajo soportados |
|---|---|---|
| Sencillo | Archiva la entrada de la etapa actual sin modificación para su uso en etapas futuras. Normalmente, este tipo de compilador solo es útil cuando la entrada de la etapa procede de un repositorio SCM. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de Docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión de imagen más reciente. |
| Hormiga | Utiliza archivos Ant de Apache para gestionar el trabajo de compilación. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de Docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Script de compilación: se ejecuta en un nuevo shell de Ubuntu siempre que se ejecuta el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: especifica el Directorio en el que se ejecuta el script. Directorio de archivado de compilación: especifica el directorio que contiene la salida del trabajo que se archivará para que la utilice una etapa posterior. Habilitar informe de prueba: marque este recuadro de selección para especificar que el trabajo de compilación ejecuta pruebas que producen archivos de resultados en formato JUnit XML. Se visualiza un informe basado en los archivos de resultados en el separador Pruebas de la página Resultados del trabajo. Si falla alguna prueba, el trabajo se marcará como fallido. Habilitar informe de cobertura de código: marque este recuadro de selección para mostrar más campos que se pueden utilizar para el informe de cobertura de código. Puede especificar el ejecutor de cobertura (como JaCoCo, y Cobertura), la ubicación del archivo de resultados de cobertura y el directorio de resultados de cobertura, en relación con el directorio de trabajo. |
| Registro de contenedor | Crea imágenes de Docker y las sube a IBM Cloud Container Registry. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de Docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Clave de API: la clave de API de IBM Cloud que se debe utilizar para proporcionar permisos a los recursos de la cuenta. Espacio de nombres de Container Registry: espacio de nombres en el que se quiere almacenar la imagen compilada. Nombre de la imagen de Docker: nombre de la imagen que el trabajo compila y carga en IBM Cloud Container Registry. Script de compilación: se ejecuta en un nuevo shell de Ubuntu siempre que se ejecuta el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: especifica el Directorio en el que se ejecuta el script. Directorio de archivado de compilación: especifica el directorio que contiene la salida del trabajo que se archivará para que la utilice una etapa posterior. Habilitar informe de prueba: marque este recuadro de selección para especificar que el trabajo de compilación ejecuta pruebas que producen archivos de resultados en formato JUnit XML. Se visualiza un informe basado en los archivos de resultados en el separador Pruebas de la página Resultados del trabajo. Si falla alguna prueba, el trabajo se marcará como fallido. Habilitar informe de cobertura de código: marque este recuadro de selección para mostrar más campos que se pueden utilizar para el informe de cobertura de código. Puede especificar el ejecutor de cobertura (como JaCoCo, y Cobertura), la ubicación del archivo de resultados de cobertura y el directorio de resultados de cobertura, en relación con el directorio de trabajo. |
| Imagen de Docker personalizada | Se crean utilizando tu imagen personalizada de Docker, con un control minucioso sobre las versiones de Node, Java™ u otras herramientas. | Nombre de imagen de Docker: el nombre de la imagen que este trabajo crea y carga en IBM Cloud Container Registry.
Script de compilación: se ejecuta en un nuevo shell de Ubuntu siempre que se ejecuta el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de archivado de compilación: especifica el directorio que contiene la salida del trabajo que se archivará para que la utilice una etapa posterior. Habilitar informe de prueba: marque este recuadro de selección para especificar que el trabajo de compilación ejecuta pruebas que producen archivos de resultados en formato JUnit XML. Se visualiza un informe basado en los archivos de resultados en el separador Pruebas de la página Resultados del trabajo. Si falla alguna prueba, el trabajo se marcará como fallido. Habilitar informe de cobertura de código: marque este recuadro de selección para mostrar más campos que se pueden utilizar para el informe de cobertura de código. Puede especificar el ejecutor de cobertura (como JaCoCo, y Cobertura), la ubicación del archivo de resultados de cobertura y el directorio de resultados de cobertura, en relación con el directorio de trabajo. |
| Gradle | Compila utilizando Gradle. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Script de compilación: se ejecuta en un nuevo shell de Ubuntu siempre que se ejecuta el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: especifica el Directorio en el que se ejecuta el script. Directorio de archivado de compilación: especifica el directorio que contiene la salida del trabajo que se archivará para que la utilice una etapa posterior. Habilitar informe de prueba: marque este recuadro de selección para especificar que el trabajo de compilación ejecuta pruebas que producen archivos de resultados en formato JUnit XML. Se visualiza un informe basado en los archivos de resultados en el separador Pruebas de la página Resultados del trabajo. Si falla alguna prueba, el trabajo se marcará como fallido. Habilitar informe de cobertura de código: marque este recuadro de selección para mostrar más campos que se pueden utilizar para el informe de cobertura de código. Puede especificar el ejecutor de cobertura (como JaCoCo, y Cobertura), la ubicación del archivo de resultados de cobertura y el directorio de resultados de cobertura, en relación con el directorio de trabajo. |
| Grunt | Compila utilizando Grunt. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de Docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Script de compilación: se ejecuta en un nuevo shell de Ubuntu siempre que se ejecuta el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: especifica el Directorio en el que se ejecuta el script. Directorio de archivado de compilación: especifica el directorio que contiene la salida del trabajo que se archivará para que la utilice una etapa posterior. Habilitar informe de prueba: marque este recuadro de selección para especificar que el trabajo de compilación ejecuta pruebas que producen archivos de resultados en formato JUnit XML. Se visualiza un informe basado en los archivos de resultados en el separador Pruebas de la página Resultados del trabajo. Si falla alguna prueba, el trabajo se marcará como fallido. Habilitar informe de cobertura de código: marque este recuadro de selección para mostrar más campos que se pueden utilizar para el informe de cobertura de código. Puede especificar el ejecutor de cobertura (como JaCoCo, y Cobertura), la ubicación del archivo de resultados de cobertura y el directorio de resultados de cobertura, en relación con el directorio de trabajo. |
| Maven | Compila utilizando Apache Maven. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Script de compilación: se ejecuta en un nuevo shell de Ubuntu siempre que se ejecuta el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: especifica el Directorio en el que se ejecuta el script. Directorio de archivado de compilación: especifica el directorio que contiene la salida del trabajo que se archivará para que la utilice una etapa posterior. Habilitar informe de prueba: marque este recuadro de selección para especificar que el trabajo de compilación ejecuta pruebas que producen archivos de resultados en formato JUnit XML. Se visualiza un informe basado en los archivos de resultados en el separador Pruebas de la página Resultados del trabajo. Si falla alguna prueba, el trabajo se marcará como fallido. Habilitar informe de cobertura de código: marque este recuadro de selección para mostrar más campos que se pueden utilizar para el informe de cobertura de código. Puede especificar el ejecutor de cobertura (como JaCoCo, y Cobertura), la ubicación del archivo de resultados de cobertura y el directorio de resultados de cobertura, en relación con el directorio de trabajo. |
| npm | Instala dependencias con el gestor de paquetes de Node. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Script de compilación: se ejecuta en un nuevo shell de Ubuntu siempre que se ejecuta el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: especifica el Directorio en el que se ejecuta el script. Directorio de archivado de compilación: especifica el directorio que contiene la salida del trabajo que se archivará para que la utilice una etapa posterior. Habilitar informe de prueba: marque este recuadro de selección para especificar que el trabajo de compilación ejecuta pruebas que producen archivos de resultados en formato JUnit XML. Se visualiza un informe basado en los archivos de resultados en el separador Pruebas de la página Resultados del trabajo. Si falla alguna prueba, el trabajo se marcará como fallido. Habilitar informe de cobertura de código: marque este recuadro de selección para mostrar más campos que se pueden utilizar para el informe de cobertura de código. Puede especificar el ejecutor de cobertura (como JaCoCo, y Cobertura), la ubicación del archivo de resultados de cobertura y el directorio de resultados de cobertura, en relación con el directorio de trabajo. |
| Script de shell | Ejecuta un script de shell de UNIX, como Bash. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Script de compilación: se ejecuta en un nuevo shell de Ubuntu siempre que se ejecuta el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: especifica el Directorio en el que se ejecuta el script. Directorio de archivado de compilación: especifica el directorio que contiene la salida del trabajo que se archivará para que la utilice una etapa posterior. Habilitar informe de prueba: marque este recuadro de selección para especificar que el trabajo de compilación ejecuta pruebas que producen archivos de resultados en formato JUnit XML. Se visualiza un informe basado en los archivos de resultados en el separador Pruebas de la página Resultados del trabajo. Si falla alguna prueba, el trabajo se marcará como fallido. Habilitar informe de cobertura de código: marque este recuadro de selección para mostrar más campos que se pueden utilizar para el informe de cobertura de código. Puede especificar el ejecutor de cobertura (como JaCoCo, y Cobertura), la ubicación del archivo de resultados de cobertura y el directorio de resultados de cobertura, en relación con el directorio de trabajo. |
| Gradle (Artifactory, Nexus o SonarQube) | Crea y despliega utilizando Gradle con un repositorio de Nexus o Artifactory. Gradle también se integra con SonarQube. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Instancia de integración de herramientas de repositorio: nombre de la instancia de integración de herramientas de repositorio que se va a utilizar con este trabajo de compilación. Tipo de integración de herramientas de repositorio: tipo de integración de herramientas de la que obtener información de Gradle. Instancia de integración de SonarQube: The nombre de la instancia de integración de SonarQube que se va a utilizar con este trabajo de compilación. Mandato de compilación: mandato de compilación que se va a ejecutar siempre que se ejecute el trabajo. En el campo Script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: especifica el Directorio en el que se ejecuta el script. Directorio de archivado de compilación: especifica el directorio que contiene la salida del trabajo que se archivará para que la utilice una etapa posterior. |
| Maven (Artifactory, Nexus o SonarQube) | Crea y despliega utilizando Maven con un repositorio de Nexus o Artifactory. Maven también se integra con SonarQube. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Instancia de integración de herramientas de repositorio: nombre de la instancia de integración de herramientas de repositorio que se va a utilizar con este trabajo de compilación. Tipo de integración de herramientas de repositorio: tipo de integración de herramientas de la que obtener información de Gradle. Instancia de integración de SonarQube: nombre de la instancia de integración de SonarQube que se va a utilizar con este trabajo de compilación. Mandato de compilación: el mandato de compilación que se va a ejecutar cuando se ejecuta el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: especifica el Directorio en el que se ejecuta el script. Directorio de archivado de compilación: especifica el directorio que contiene la salida del trabajo que se archivará para que la utilice una etapa posterior. |
| npm (Artifactory o Nexus) | Se crea utilizando npm con un repositorio de Nexus o Artifactory. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Instancia de integración de herramientas de repositorio: nombre de la instancia de integración de herramientas de repositorio que se va a utilizar con este trabajo de compilación. Tipo de integración de herramientas de repositorio: tipo de integración de herramientas de la que obtener información de Gradle. Instancia de integración de SonarQube: The nombre de la instancia de integración de SonarQube que se va a utilizar con este trabajo de compilación. Mandato de compilación: mandato de compilación que se va a ejecutar siempre que se ejecute el trabajo. En el campo Script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Incrementar versión del módulo de instantáneas: da soporte a la entrega continua incrementando la versión del módulo localmente en función del contenido del archivo Directorio de trabajo: especifica el Directorio en el que se ejecuta el script. Directorio de archivado de compilación: especifica el directorio que contiene la salida del trabajo que se archivará para que la utilice una etapa posterior. |
Fase de despliegue
En la fase de despliegue se especifica la entrada de una etapa de compilación. En los trabajos de la etapa de despliegue se especifica un Tipo de desplegador. Están disponibles los siguientes tipos de desplegador:
| Tipo de desplegador | Descripción | Tipos de trabajo soportados |
|---|---|---|
| Imagen de Docker personalizada | Se implementa utilizando su imagen personalizada de Docker con un control minucioso sobre las versiones de Node, Java™ u otras herramientas. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de Docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Clave de API: la clave de API de IBM Cloud que se debe utilizar para proporcionar permisos a los recursos de la cuenta. Docker nombre de la imagen: El nombre de la imagen que esta tarea compila y sube a IBM Cloud Container Registry. Desplegar script: mandato de despliegue que se debe ejecutar siempre que se ejecute el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. |
| Kubernetes | Despliega aplicaciones en clústeres Kubernetes, como los que se encuentran en IBM Cloud Container Service. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de Docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Clave de API: la clave de API de IBM Cloud que se debe utilizar para proporcionar permisos a los recursos de la cuenta. Nombre de clúster: nombre del clúster de Kubernetes; la plataforma en la que se despliegan los componentes de Kubernetes. Desplegar script: mandato de despliegue que se debe ejecutar siempre que se ejecute el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. |
Etapa de prueba
La etapa de prueba especifica la configuración de la prueba. Los trabajos de la etapa de prueba especifican un Tipo de probador. Están disponibles los siguientes tipos de probador:
| Tipo de probador | Descripción | Tipos de trabajo soportados |
|---|---|---|
| Sencillo | Inicia un mandato de shell para ejecutar las pruebas automatizadas, con un informe de prueba opcional. | Versión de imagen del conducto: no se utiliza.
Script de prueba: el mandato de prueba que se ejecutará siempre que se ejecute el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: directorio en el que se ejecuta el script de prueba. Habilitar informe de prueba: no se utiliza. Habilitar informe de cobertura de código: no se utiliza. |
| Imagen de Docker personalizada | Realiza pruebas utilizando tu imagen personalizada de Docker con un control minucioso sobre las versiones de Node, Java™ u otras herramientas. | Nombre de imagen de Docker: el nombre de la imagen de Docker con el que se va a ejecutar el trabajo. Para asegurarse de que los trabajos se ejecutan en un contexto limpio, ejecútelos en contenedores de Docker.
Script de prueba: el mandato de prueba que se ejecutará siempre que se ejecute el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: directorio en el que se ejecuta el script de prueba. Habilitar informe de prueba: no se utiliza. Habilitar informe de cobertura de código: no se utiliza. |
| Vulnerability Advisor | Ejecuta una comprobación de conformidad y vulnerabilidad en la imagen especificada y muestra los resultados. Si se encuentra algún problema, esta etapa falla. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de Docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Clave de API: la clave de API de IBM Cloud que se debe utilizar para proporcionar permisos a los recursos de la cuenta. Espacio de nombres de Container Registry: espacio de nombres en el que se almacena la imagen compilada. Nombre de imagen de Docker: nombre de la imagen de Docker con la que se va a ejecutar el trabajo. Para asegurarse de que los trabajos se ejecutan en un contexto limpio, ejecútelos en contenedores de Docker. Etiqueta de la imagen de Docker: una etiqueta para la imagen de Docker que se muestra en IBM Cloud Container Registry. Script de prueba: el mandato de prueba que se ejecutará siempre que se ejecute el trabajo. En el campo de script, escriba el script o los scripts de referencia que se almacenan en el control de origen del proyecto. Directorio de trabajo: directorio en el que se ejecuta el script de prueba. Habilitar informe de prueba: no se utiliza. Habilitar informe de cobertura de código: no se utiliza. |
| Sauce Labs | Realiza pruebas de JavaScript,, Node o Java™ utilizando Sauce Labs. | Versión de imagen del conducto: se ejecuta en un contenedor utilizando una imagen de Docker incorporada que proporcionar varios mandatos incorporados. Para adoptar nuevas versiones de estos mandatos, utilice una versión
de imagen más reciente.
Instancia de servicio: seleccione una instancia de configuración o cree una. |
Tipos de trabajo en desuso
Varios tipos de tareas, como la tarea de compilación IBM Globalization Pipeline, la tarea de prueba Space Shell y la tarea de prueba de puerta DevOps Insights, han quedado obsoletas. De todos modos, si bien dichos trabajos han quedado en desuso, todavía podría cargarlos en la interfaz de usuario, con un indicador de que el tipo de trabajo está en desuso. El trabajo también podría revertirse a otro tipo de trabajo que todavía estuviese admitido, pero con una notificación de advertencia.
Si necesita utilizar la configuración de un tipo de trabajo en desuso, utilice uno de los métodos siguientes para acceder a la configuración de la interconexión.
- Utilice IBM Cloud Devtool:
ic dev pipeline-get 7325f511-492a-4c35-a388-5e499e65d6bb -output JSON
-
Utilice la API de Delivery Pipeline:
curl --location --request GET 'https://devops-api.us-south.devops.cloud.ibm.com/v1/pipeline/pipelines/7325f511-492a-4c35-a388-5e499e65d6bb/stages' \ --header 'Authorization: Bearer <IAM Bearer token> -
En el separador Red de la interfaz de usuario de Delivery Pipeline, filtre por el ID de interconexión para localizar la interconexión que contiene los datos del tipo de trabajo en desuso.
Claves de API
Algunos de los trabajos estándar de Pipeline utilizan claves de API de IBM Cloud para acceder a servicios, como la implementación en Kubernetes. El servicio IBM Cloud Identity and Access Management (IAM) proporciona dos tipos de claves de API:
- Claves de API de usuario: Estas claves de API proporcionan acceso completo a todos los servicios y recursos a los que el usuario tiene acceso.
- Claves de API de servicio: Puede configurar las claves de API de servicio para proporcionar acceso específico a diversos servicios y recursos.
Algunos servicios no pueden utilizar claves de API de ID de servicio. En estos casos, la interfaz de usuario de conducto le solicita que especifique una clave de API de usuario.
Puesto que los trabajos de conducto ejecutan scripts creados por el usuario que pueden utilizar las claves de API de servicio de forma arbitraria, el conducto no puede determinar el conjunto de restricciones que se aplican a una clave determinada. En estos casos, si solicita que el conducto cree una clave de API, se crea una clave de API de usuario. Para mantener un nivel elevado de seguridad, utilice una clave de API de servicio con acceso que esté restringida únicamente a los servicios y recursos que necesite en el script. En esta instancia, debe crear la clave de API usted mismo. Para obtener más información sobre la creación de una clave de API, consulte Claves de API de IBM Cloud.
Trabajos
Un trabajo es una unidad de ejecución dentro de una etapa. Una etapa puede contener varios trabajos, y los trabajos de una etapa se ejecutan secuencialmente. De forma predeterminada, si falla un trabajo, no se ejecutarán los trabajos posteriores de la etapa.
Los trabajos se ejecutan en directorios de trabajo discretos dentro de los contenedores Docker creados para cada ejecución de conducto. Antes de que se ejecute un trabajo, su directorio de trabajo se rellena con la entrada definida en el nivel de etapa. Por ejemplo, es posible que tenga una etapa que contenga un trabajo de prueba y un trabajo de despliegue. Si instala dependencias en un trabajo, no estarán disponibles en el otro trabajo. Sin embargo, si convierte en disponibles las dependencias en la entrada de la etapa, estarán disponibles para ambos trabajos.
Excepto para los trabajos de compilación simples, al configurar un trabajo, puede incluir scripts shell UNIX que incluyan mandatos de compilación, prueba o despliegue. Dado que los trabajos se ejecutan en contenedores ad hoc, las acciones de un trabajo no pueden afectar a los entornos de ejecución de otros trabajos, incluso aunque estos trabajos formen parte de la misma etapa.
En https://github.com/open-toolchain/commons se pueden encontrar ejemplos de scripts de compilación e implementación.
Además, los trabajos de conducto sólo pueden ejecutar los siguientes mandatos como sudo:
/usr/sbin/service/usr/bin/apt-get/usr/bin/apt-key/usr/bin/dpkg/usr/bin/add-apt-repository/opt/IBM/node-v0.10.40-linux-x64/npm/opt/IBM/node-v0.12.7-linux-x64/npm/opt/IBM/node-v4.2.2-linux-x64/npm/usr/bin/Xvfb/usr/bin/pip
Una vez que se ejecute un trabajo, el contenedor creado para él se descartará. Los resultados de una ejecución de trabajo pueden continuar, pero el entorno en el que se ha ejecutado no.
Los trabajos se pueden ejecutar durante un máximo de 60 minutos. Cuando los trabajos superan dicho límite, fallarán. Si un trabajo está superando el límite, divídalo en varios trabajos. Por ejemplo, si un trabajo lleva a cabo tres tareas, puede dividirlo en tres trabajos: uno para cada tarea.
Para obtener más información sobre cómo añadir un trabajo a una etapa, consulte Adición de un trabajo a una etapa.
Trabajos de compilación
Los trabajos de compilación compilan el proyecto en preparación para el despliegue. Generan artefactos que se pueden enviar a un directorio de archivado de compilación, aunque de forma predeterminada, los artefactos se colocan en el directorio raíz del proyecto.
Los trabajos que toman entrada de trabajos de compilación deben hacer referencia a los artefactos de compilación en la misma estructura en la que se crearon. Por ejemplo, si un trabajo de compilación archiva artefactos de compilación en un
directorio de output, un script de despliegue podría hacer referencia al directorio de output en lugar de al directorio raíz del proyecto para desplegar el proyecto compilado. Puede especificar el directorio en
el que archivar escribiendo el nombre del directorio en el campo Directorio de archivado de compilación. Si deja el campo en blanco, se archiva en el directorio raíz.
Si utiliza el tipo de constructor Simple, el código no se compilará ni creará; se empaquetará y quedará disponible para futuras etapas.
Trabajos de despliegue
Los trabajos de despliegue cargan el proyecto a IBM Cloud como una app y son accesibles desde un URL. Una vez que se despliegue un proyecto, puede encontrar la app desplegada en el panel de control de IBM Cloud.
Los trabajos de despliegue pueden desplegar nuevas apps o actualizar apps existentes. Incluso si primero ha desplegado una app utilizando otro método, puede actualizar la app utilizando un trabajo de despliegue. Para actualizar una app, en el trabajo de despliegue, utilice el nombre de dicha app.
Puede desplegar en una o más regiones y servicios. Por ejemplo, puede configurar Delivery Pipeline para que utilice uno o varios servicios, realice pruebas en una región y despliegue a producción en varias regiones.
Trabajos de prueba
Si desea solicitar que se cumplan las condiciones, incluya trabajos de prueba antes o después de los trabajos de compilación y despliegue. Puede personalizar trabajos de prueba para que sean tan simples o tan complejos como se necesite. Por ejemplo, puede emitir un mandato cURL y esperar una respuesta determinada. También puede ejecutar una suite de pruebas de unidad o ejecutar pruebas funcionales con servicios de prueba de terceros, como por ejemplo Sauce Labs.
Si sus pruebas generan archivos de resultados en formato XML JUnit, se mostrará un informe basado en los archivos de resultados en el separador Pruebas de cada página de resultados de prueba. Si falla una prueba, el trabajo también fallará.
Propiedades de entorno (Variables de entorno)
Un conjunto de propiedades de entorno predefinidas proporcionan acceso a información sobre el entorno de ejecución del trabajo. Para obtener una lista completa de propiedades de entorno predefinidas, consulte Recursos y propiedades de entorno.
También puede definir sus propias propiedades de entorno. Por ejemplo, puede definir una propiedad API_KEY que pase una clave de API que se utiliza para que todos los scripts del conducto accedan a los recursos de IBM Cloud.
Puede añadir los siguientes tipos de propiedades:
- Texto: Una clave de propiedad con un valor de línea única.
- Área de texto: Una clave de propiedad con un valor de varias líneas. También hay disponible una versión base64 de cada valor de propiedad de área de texto. Puede acceder a esta versión utilizando el nombre de clave de propiedad
con el sufijo
_base641. Puede descodificar la versión base64 de una propiedad de área de texto escribiendoecho "$(echo $multi_base64 | base64 -d)", dondemulties el nombre de clave de propiedad que ha definido ymulti_base64es la propiedad adicional que se proporciona. La imagen base del conducto contiene soporte incorporado para gestionar la codificación multilínea de forma transparente. Sin embargo, si utiliza una imagen personalizada debe añadir la propiedad de sufijo_base64para evitar problemas, como por ejemplo, que el valor se trunque por un final de línea. - Seguro: Una clave de propiedad con un valor de línea única que esté protegido con cifrado AES-128. El valor se visualiza como asteriscos.
- Propiedades: Un archivo del repositorio del proyecto. Este archivo puede contener varias propiedades. Cada propiedad debe estar en su propia línea. Para separar los pares de clave-valor, utilice el signo igual (=). Especifique
los valores de serie entre comillas. Por ejemplo,
MY_STRING="SOME STRING VALUE".
Puede examinar las propiedades del entorno para un trabajo de conducto ejecutando el mandato env en el script del trabajo.
Propiedades de conducto
Para definir las propiedades del conducto, desde el menú de desbordamiento de la página Conducto, seleccione Configurar conducto.
{: caption="
En el separador ENVIRONMENT PROPERTIES en la página de configuración Conducto, establezca las propiedades del entorno a nivel de conducto.
{: caption="
Propiedades de la etapa
Para definir las propiedades de la etapa, abra la página de configuración Etapa y pulse el separador ENVIRONMENT PROPERTIES.
{: caption="
Puede definir una propiedad de etapa utilizando un valor inicial (o un valor en blanco) y sobrescribiendo luego ese valor en un trabajo exportando una variable de entorno. Al alterar temporalmente el valor inicial, los trabajos posteriores
de la etapa pueden ver el nuevo valor. Por ejemplo, puede incluir el siguiente mandato para establecer la propiedad $API_KEY y ponerla a disposición de otro trabajo de la etapa: export API_KEY=<insert API key here>
Propiedades calculadas
Puede calcular los valores de propiedad de entorno que se comparten entre etapas creado un archivo build.properties mientras se ejecuta la etapa y, a continuación, hacer que la etapa siguiente ejecute el archivo. Por ejemplo,
el trabajo de compilación podría incluir el mandato siguiente en el script de compilación:
echo "IMAGE_NAME=${FULL_REPOSITORY_NAME}" >> $ARCHIVE_DIR/build.properties
Todos los trabajos empiezan ejecutando el archivo build.properties, si existe.
Creación y uso de artefactos
Los trabajos de compilación captan automáticamente el contenido en la carpeta actual donde se ejecuta el script de usuario. Si no necesita todo el contenido del repositorio git todo para el despliegue posterior, es preferible que configure un directorio de salida explícito y se copien o se creen los artefactos relevantes allí. Los scripts de trabajos se ejecutan en el resultado de la compilación (directorio de salida).
En los trabajos de despliegue que se despliegan en el IBM Cloud Kubernetes Service es necesario especificar la clave de API de Plataforma de un usuario en donde se ejecutan los trabajos de autorización, un Dockerfile y, opcionalmente, un diagrama de Helm.
El script del trabajo se ejecuta después de que el trabajo inicie sesión en el entorno de destino utilizando la clave de API de la Plataforma que se le ha asignado (por lo tanto, puede ejecutar mandatos cf push o kubectl en el script).
Un conducto de ejemplo
Un conducto de ejemplo puede contener tres etapas:
- Una etapa de compilación que compila y ejecuta procesos de compilación en una app.
- Una etapa de prueba que despliega una instancia de la app y, a continuación, ejecuta pruebas en esta.
- Una etapa de producción que despliega una instancia de producción de la app probada.
Este conducto se muestra en el siguiente diagrama conceptual:
Las etapas toman su entrada de repositorios y trabajos de compilación, y los trabajos de una etapa se ejecutan de forma secuencial e independiente entre sí. En el conducto de ejemplo, las etapas se ejecutan secuencialmente, aunque las etapas de Prueba y de Producción tomen la salida de la etapa de Compilación como su entrada.