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 GitHub integración de herramientas para cada aplicación que desees desarrollar en las canalizaciones 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 repositorios de incidencias propios. Esto sólo es aplicable cuando la opción de problemas de GitHub está habilitada en la integración de herramientas.

  • El repositorio de inventario debe ser suficiente como único repositorio consolidado para registrar sus registros de compilación, ya que los registros ya están divididos por el app-name, por lo que, siempre que ese parámetro sea diferente, no se perderá ni se confundirá nada. Aunque es posible que desee consultar la documentación del inventario para obtener ideas sobre cómo manejar este repositorio, ya que su función principal es ayudar a respaldar las implementaciones en el canal de implementación continua.

  1. Configure un IBM Cloud® Object Storage bucket.

    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.

  2. Opcional: integraciones adicionales de Hashicorp Vault.

    Puesto que la integración de la herramienta Vault de HashiCorp sólo da soporte a una vía de acceso, es posible que necesite más de ellos en función de cómo estén configurados los secretos de Vault de HashiCorp. Es posible que distintas aplicaciones necesiten credenciales diferentes o de otro tipo entre sí.

Personalización de CI y canalización de relaciones públicas

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 apunta al repositorio y la GitHub rama requeridos.
    • Asegúrese de que estén configuradas las siguientes propiedades del desencadenador:
      • app-name (texto): los nombres de aplicación deben ser exclusivos entre las distintas aplicaciones. Esto se debe a que el nombre de la app se utiliza en el inventario, DevOps insights y otros como identificador exclusivo cuando se coloca y se registra con artefactos.
      • cos-bucket-name (texto): El nombre del Object Storage depósito en el que se coloca la evidencia 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 activación en los activadores de canalización, que anulan las propiedades ambientales con los valores elegidos por usted.
      • app-name (texto): Los nombres de las aplicaciones siempre deben ser únicos en las diferentes aplicaciones, ya que el nombre de la aplicación se utiliza en el inventario, DevOps los informes, etc., como identificador único al colocar y registrar artefactos.
      • cos-bucket-name (texto): El nombre del Object Storage depósito en el que se coloca la evidencia 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 Configure 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 preconfigurados para ahorrarse algunos pasos a la hora de escribir todas las pequeñas diferencias posibles entre las aplicaciones.
  4. optional step Cree activadores de temporizador para sus aplicaciones.

    • Es recomendable reconstruir y revalidar una aplicación con frecuencia, para poder estar al tanto de cualquier problema de cumplimiento y vulnerabilidad, así como de cualquier problema de compilación.
    • Configure las propiedades del disparador de la misma manera que configuró el disparador manual, ya que el disparador temporizado es simplemente un disparador manual con un temporizador.
    • Escalona tus tareas cron entre sí, 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 desencadenadores de canalización o dentro de las propiedades del entorno, consulte el catálogo de parámetros de canalización.