Consideraciones sobre cadenas de herramientas y conductos

La mayoría de las aplicaciones están hechas de varios microservicios con diferentes repositorios de origen. Normalmente, se utiliza una única cadena de herramientas para alojar microservicios que se agrupan lógicamente. En general, utilice una cadena de herramientas y un conducto, o el menor número posible de conductos, pero varios desencadenantes. Dentro de cada interconexión, puede duplicar y configurar tantos desencadenantes como necesite, hasta 1024 desencadenantes por interconexión. Esta estrategia ayuda a aplicar procesos comunes, scripts y archivos de configuración. Para obtener más información, consulte configuración de varias aplicaciones en una cadena de herramientas de AC.

Este enfoque presenta las siguientes ventajas:

• El uso de menos interconexiones evita la duplicación y disminuye los errores. Las actualizaciones también son más fáciles de mantener, por ejemplo, cuando se añade, edita o suprime una propiedad o un secreto de entorno.
• La incorporación de un servicio es más rápida con este enfoque. Añada una integración de Git para el microservicio, duplique el Git y los desencadenantes manuales y modifíquelos según sea necesario. A continuación, asegúrese de que el archivo .pipeline-config.yaml y los scripts estén implementados para el microservicio.

Este enfoque tiene los siguientes inconvenientes:

• Una edición puede afectar a cada equipo que utiliza el mismo conducto.
• El acceso de usuario se gestiona utilizando Identity and Access Management(IAM) y se establece en el nivel de cadena de herramientas, no en el nivel de conducto. Por lo tanto, si utiliza una única cadena de herramientas para varios servicios, cada miembro del equipo puede ver las interconexiones de otros equipos. En función del acceso del usuario en IAM, es posible que puedan editar, suprimir o desencadenar una interconexión.

Consideraciones sobre la facturación

El servicio Continuous Delivery determina la facturación en función del número de usuarios autorizados por instancia de CD y de cuántos grupos de recursos utilice para sus cadenas de herramientas. Los usuarios que tienen acceso a los repositorios también se consideran usuarios autorizados. Para obtener más información, consulte Usuarios autorizados. Para reducir costes, debería organizar todas sus cadenas de herramientas en el mismo grupo de recursos o configurar la facturación consolidada de Continuous Delivery dentro de una jerarquía de cuentas de empresa. Para más información, consulte Facturación consolidada.

DevSecOps consideraciones sobre repositorios

Si está creando una aplicación que se compone de múltiples microservicios, la mayoríaDevSecOps Los repositorios, excepto el repositorio de pruebas, se pueden compartir entre los microservicios.

Para más información, ver cómoDevSecOps oleoductos utilizan repositorios.

Consideraciones sobre IBM Cloud Object Storage

Si utiliza un repositorio de inventario compartido, también puede utilizar una instancia compartida de IBM Cloud® Object Storage. Complete los pasossiguientes:

1. Cree una instancia de de IBM Cloud Object Storage para utilizarla en cadenas de herramientas y pipelines.
2. Configure interconexiones y desencadenantes, si procede, para utilizar el grupo IBM Cloud Object Storage estableciendo la propiedad de entorno cos-bucket-name.

Todos los microservicios de las mismas canalizaciones de CI, CD y CC comparten un cubo Object Storage, independientemente del entorno de implantación. El cubo Object Storage funciona de forma similar al depósito de pruebas, pero sin los problemas de rendimiento que pueden producirse con un depósito de pruebas importante. Dado que los problemas de rendimiento no se producen con un cubo importante de Object Storage, no es necesario podar las pruebas de los cubos de Object Storage.

Despliegue en varios entornos

El despliegue en varios entornos de destino con la interconexión de CD se puede lograr de varias formas.

Cada targeted environment debe tener una rama correspondiente en el repositorio de inventario, donde los cambios se promocionan de un source a una rama de target.

Los siguientes diseños opcionales pueden ajustarse a su arquitectura:

• Utilice un desencadenante manual por entorno de destino. Duplique un desencadenante y, a continuación, edite las propiedades de entorno para que se ajusten al nuevo entorno.
• Utilice un repositorio de configuración Git con una carpeta por entorno de destino, donde los valores de configuración específicos se almacenan en archivos.

Identificar qué script se ejecuta

Para identificar qué script se ejecuta para una etapa, abra la ejecución del conducto (preferiblemente un conducto de AC). Expanda una tarea y, a continuación, pulse run-stage para abrir los registros. El principio de los registros de run-stage proporciona información sobre los scripts que se han utilizado en la etapa, incluido en qué repositorio se encuentra el script. En los registros, puede desplazarse para encontrar más detalles sobre los scripts que se han ejecutado. Por ejemplo, la tarea code-compliance-checks puede tener la siguiente información en el registro de run-stage, que incluye propiedades de entorno para la etapa:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

En ese ejemplo, el script que se ejecuta es /opt/commons/compliance-checks/run.sh, que se encuentra en la biblioteca commons. Utilice esta biblioteca de commons como origen para copiar código que se puede personalizar para casos periféricos específicos. En el ejemplo, compliance-checks/run.sh se encuentra en la biblioteca compliance-commons.

Alteración temporal de scripts predeterminados

Para alterar temporalmente los scripts predeterminados, realice los pasos siguientes:

1. En el registro de etapa, copie el fragmento de código que identifica un script predeterminado:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

1. Pegue el fragmento de código en el archivo .pipeline-config.yaml.
2. Añada el código personalizado antes o después de llamar al script. Este fragmento invoca el script de comprobaciones de cumplimiento predeterminado
3. Edite, suprima o añada propiedades según sea necesario.

El ejemplo siguiente muestra el script actualizado en el archivo .pipeline-config.yaml:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh
    # run some custom script here
    ./scripts/my-custom-script1.sh

    "/opt/commons/compliance-checks/run.sh"

    # then some additional work
    ./scripts/my-custom-script2.sh

Para obtener más información, consulte scripts personalizados.