Configuración de varias app en una cadena de herramientas de integración continua

Cuando ejecute ofertas de servicio a través de Integración continua (CI), considere la posibilidad de consolidar todos los microservicios o componentes de sus ofertas en una única cadena de herramientas común, en lugar de gestionar varias cadenas de herramientas para cada repositorio.

Configurar el conducto de AC y el conducto de solicitud de extracción(PR) para que funcionen para varios repositorios de aplicaciones es sencillo. Utilice los pasos y cambios siguientes para habilitar varias aplicaciones.

Personalización de la cadena de herramientas

Personalice la cadena de herramientas añadiendo la cadena de herramientas a varias apps y aumentando su funcionalidad. Estos son los pasos a seguir:

  1. Añade una integración de la herramienta GitHub para cada aplicación que quieras desarrollar en los flujos de trabajo de la cadena de herramientas.

  2. Añada más integraciones de GitHub para cualquier problemaadicional, inventario y repositorios de pruebas que se puedan configurar para determinadas aplicaciones.

    • Consulte las páginas de la documentación y las prácticas recomendadas para averiguar si necesita estos repositorios adicionales para las aplicaciones.

    • Un subsistema es un grupo de servicios relacionados que dependen unos de otros y se desarrollan e implementan conjuntamente.

      • Los servicios dentro de un mismo subsistema deben compartir un repositorio de inventario y un almacén de pruebas comunes. Cada subsistema debe mantener una relación 1:1 entre su repositorio de inventario y su almacén de pruebas. No se admiten búsquedas de pruebas en varios armarios, ya que amplían el espacio de búsqueda y aumentan el riesgo de que se produzcan conflictos de datos.
      • También puedes agrupar varios subsistemas para utilizar el mismo inventario y armario compartidos.
      • Ejemplo: Agrupar servicios relacionados (como auth y user-profile) en un solo subsistema. Este modelo admite la gestión de microservicios escalables en Continuous Delivery entornos.
    • Los repositorios de aplicaciones también pueden servir como su propio repositorio de incidencias. Esto sólo es aplicable cuando la opción de problemas de GitHub está habilitada en la integración de herramientas.

    • El repositorio Inventory debe ser suficiente como único repositorio consolidado para registrar tus registros de compilación, ya que estos ya están divididos por el parámetro app-name, por lo que, siempre que dicho parámetro sea diferente, no se perderá ni se confundirá nada. Aunque quizá te interese consultar la documentación del inventario para obtener ideas sobre cómo gestionar este repositorio, ya que su función principal es facilitar las implementaciones en el proceso de implementación continua.

  3. Configurar un bucket de IBM Cloud® Object Storage.

    IBM Cloud Object Storage es el método preferido del archivo de pruebas para los artefactos de pruebas de interconexión y es necesario para la conformidad de auditoría. Utilice el mismo grupo Object Storage para cada aplicación que incorpore a la cadena de herramientas de AC. Además, reutilice el mismo grupo Object Storage cuando esté integrando la cadena de herramientas de AC con la cadena de herramientas de CD o CC.

  4. Opcional: integraciones adicionales de Hashicorp Vault.

    Dado que la integración de la herramienta HashiCorp Vault solo admite una ruta, es posible que necesites más, dependiendo de cómo estén configurados tus secretos de HashiCorp Vault. Es posible que distintas aplicaciones necesiten credenciales diferentes o de otro tipo entre sí.

Personalización del proceso de CI y PR

Personalice su conducto de AC y PR configurándolos utilizando los pasos siguientes:

  1. Cree un desencadenante de Git para cada aplicación.

    • Copie los desencadenantes existentes para guardar algún tedium al crear desencadenantes.
    • Asegúrate de que cada uno de los desencadenantes apunte al repositorio y a la rama de GitHub correspondientes.
    • Asegúrate de que estén configuradas las siguientes propiedades del disparador:
      • app-name (texto): los nombres de aplicación deben ser exclusivos entre las distintas aplicaciones. Esto se debe a que el nombre de la aplicación se utiliza en el inventario y en otros contextos como identificador único cuando se incluye y se registra junto con los artefactos.
      • cos-bucket-name (texto): El nombre del depósito Object Storage en el que se almacenan los datos de las aplicaciones.
  2. Cambios de propiedad de entorno para cada aplicación.

    • Esta es una lista de las posibles propiedades de entorno que deben cambiarse a un valor diferente para cada una de las aplicaciones. Esto se puede lograr utilizando las propiedades de los desencadenantes del pipeline, lo que anula las propiedades del entorno con los valores que tú elijas.
      • app-name (texto): Los nombres de las aplicaciones deben ser siempre únicos en las diferentes aplicaciones, ya que se utilizan en el inventario, entre otros lugares, como identificador único a la hora de colocar y registrar artefactos.
      • cos-bucket-name (texto): El nombre del depósito Object Storage en el que se almacenan los datos de las aplicaciones.
      • repository (texto): este parámetro controla qué repositorio de aplicación se clona en la interconexión y sirve como destino para las interconexiones de integración continua y de solicitud de extracción para las distintas tareas de conformidad y seguridad.
      • Opcional: evidence-repo (texto): URL del repositorio que sirve como almacén de pruebas para la aplicación.
      • Opcional: incident-repo (texto): URL del repositorio que sirve como repositorio de incidencias para la aplicación.
      • Opcional: inventory-repo (texto): URL del repositorio que sirve como repositorio de inventario para la aplicación.
  3. optional step Configurar activadores manuales para cada una de las aplicaciones.

    • Técnicamente, solo se necesita un disparador manual, ya que sus propiedades se pueden editar en el momento de la llamada, pero puede resultar útil para los equipos disponer de disparadores manuales predefinidos, lo que les ahorraría algunos pasos a la hora de escribir todas las pequeñas diferencias posibles entre las aplicaciones.
  4. optional step Crea activadores de temporizador para tus aplicaciones.

    • Es recomendable recompilar y revalidar con frecuencia una aplicación, para poder estar al tanto de cualquier problema de cumplimiento normativo y de vulnerabilidad, así como de cualquier problema de compilación.
    • Configura las propiedades del disparador del mismo modo que configuraste el disparador manual, ya que el disparador temporizado no es más que un disparador manual con un temporizador.
    • Distribuye tus tareas cron de forma escalonada; de lo contrario, podrías sobrecargar el clúster de trabajadores y tus tareas podrían sufrir un aumento en los tiempos de compilación o retrasos entre etapas.

Para obtener información sobre las demás propiedades que se pueden configurar en los desencadenantes del pipeline o dentro de las propiedades del entorno, consulta el catálogo de parámetros del pipeline.