Comportamiento predeterminado (sin reimplementación forzada)

Cuando no force-redeploy está configurado o está configurado en false, la canalización solo se implementa cuando se detectan nuevos cambios en el repositorio de inventario del entorno de destino.

1. El proceso de CD se inicia y etiqueta la confirmación actual con el ID de ejecución del proceso.

2. El canal lee el contenido de la rama de entorno correspondiente desde esa etiqueta.

3. El proceso calcula el delta de despliegue entre la confirmación actual y la confirmación asociada a la etiqueta <target-environment>_latest.

4. El pipeline evalúa el delta:

   • Si el delta está vacío, el proceso se detiene y no se realiza ninguna implementación.
   • Si el delta contiene cambios, el proceso continúa.

5. El canal implementa los cambios identificados en el delta.

6. Tras una implementación satisfactoria, el canal adjunta la <target-environment>_latest etiqueta a la nueva confirmación.

Comportamiento forzado (con reasignación forzada)

Cuando force-redeploy se establece en true, el proceso omite la validación delta y vuelve a implementar el inventario completo, independientemente de los cambios detectados. Este enfoque garantiza que el estado completo de la aplicación se vuelva a aplicar al destino de implementación.

1. El proceso de CD se inicia y etiqueta la confirmación actual con el ID de ejecución del proceso.
2. El canal lee el contenido de la rama de entorno correspondiente desde esa etiqueta.
3. El canal calcula la diferencia de implementación, que normalmente está vacía en este escenario.
4. La force-redeploy=true configuración hace que la canalización omita la comprobación delta y continúe.
5. El canal vuelve a implementar todo el estado de la aplicación desde la rama.
6. Tras una reimplementación satisfactoria, el canal adjunta la <target-environment>_latest etiqueta al compromiso que acaba de implementar.

Descripción general del canal de reversión

Esta canalización le permite volver a una configuración anterior que se sabe que funciona correctamente seleccionando un ID de solicitud de cambio ServiceNow específico (por ejemplo, CHG-12345).

Este ID de solicitud de cambio sirve como marcador único para una implementación satisfactoria y es un dato necesario para el proceso de reversión.

Puede encontrar el ID de solicitud de cambio de una implementación anterior de dos maneras:

• ServiceNow: Localice la solicitud de cambio para la implementación que desea restaurar.
• Repositorio de inventario: dado que el estado del inventario se gestiona en el control de código fuente, cada implementación se identifica de forma única mediante una confirmación. Puedes encontrar la confirmación a la que deseas revertir e identificar la CHG-*** etiqueta asociada a esa confirmación.

El proceso de reversión contiene las siguientes etapas:

• prod-rollback-start
• prod-setup
• prod-rollback-change-request
• prod-deployment
• prod-acceptance-tests
• prod-rollback-finish

La ejecución del proceso utiliza información de la rollback-change-request-id propiedad environment para crear una nueva solicitud de cambio.

Para mantener el cumplimiento, la canalización vuelve a abrir los problemas vinculados a la implementación anterior. Estos problemas se adjuntan a la nueva solicitud de cambio y sus fechas de vencimiento originales permanecen sin cambios. Una reversión exitosa mueve la _latest etiqueta en el inventario a la confirmación anterior.

Crear una canalización de reversión

Utilice cd-rollback-listener para activar una reversión a la última versión válida conocida.

1. Ve a tu canal de CD.
2. Añada un disparador manual o duplique el disparador manual del CD.
3. Edita el disparador y configura el oyente en cd-rollback-listener.
4. Seleccione Guardar.
5. Cree un desencadenador independiente para cada combinación de región y entorno de destino requerida.

Activar una canalización de reversión

Una ejecución de canalización de reversión utiliza las siguientes propiedades de entorno:

La canalización finaliza a menos que se cumplan los siguientes criterios:

• rollback-change-request-id Debe ser el ID de una implementación concluida para la misma región y el mismo entorno de destino.
• La implementación asociada con no rollback-change-request-id debe ser anterior al número de implementaciones especificado por rollback-limit.

La propiedad de PIPELINE_NAME entorno Tekton determina si una ejecución es una implementación o una reversión.

• cd-rollback-pipeline: Valor predeterminado para una reversión.
• cd-pipeline: Valor predeterminado para una implementación.

Puede utilizar esta propiedad para personalizar la lógica de ramificación.

Descripción general de la reversión mediante GitOps

Utilice el canal de implementación continua para implementar una versión anterior del inventario en el entorno de destino mediante Git operaciones que revierten los cambios a un específico commit-id.

Dado que está revirtiendo las confirmaciones en el repositorio de inventario directamente, en lugar de activar el proceso de reversión con un ID de solicitud ServiceNow de cambio, este proceso no reabre automáticamente los problemas de cumplimiento anteriores ni gestiona sus fechas de vencimiento.

Cuando se activa, el proceso de CD completa los siguientes pasos para la reimplementación:

• El pipeline se inicia y etiqueta la confirmación actual (la confirmación revertida) con el ID de ejecución del pipeline.
• El canal lee el contenido de la rama de entorno correspondiente desde esa etiqueta.
• El proceso calcula el delta de despliegue entre la confirmación actual y la confirmación asociada a la etiqueta <target-environment>_latest.
• Tras una implementación satisfactoria, la <target-environment>_latest etiqueta se traslada a la nueva confirmación (revertida).

Crear una solicitud de extracción de promoción de reversión

1. Identifique la commit-id de la versión de implementación en el inventario a la que desea volver.
2. Revertir el estado del repositorio a esa confirmación.
3. Crea una solicitud de extracción para promover el estado revertido.

El siguiente ejemplo muestra este escenario utilizando git comandos.

1. Enumera las confirmaciones y las etiquetas para encontrar el ID de confirmación del último estado válido conocido (por ejemplo, refs/tags/8)

   # /c/usr/devsecops/compliance-inventory (master)
   $ git show-ref --tags
   ...
   83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8 refs/tags/8
   ...
   1914a125e76aa97c497f4bd2c2f455b58cf079b8 refs/tags/prod_latest
   

2. Enumera todas las confirmaciones entre el estado actual (refs/tags/prod_latest) y el estado objetivo (refs/tags/8).

   # /c/usr/devsecops/compliance-inventory (master)
   $ git rev-list --no-merges HEAD...83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8
   67cc8babdff3e09c1f0e632f897798c1b5424f38
   6fab5ce3d60590cd858206424ecfd7d3a8c9ceb4
   ...
   

3. Revertir el estado del inventario al commit de destino (refs/tags/8).

   # /c/usr/devsecops/compliance-inventory (master)
   $ git revert -n $(git rev-list --no-merges HEAD...83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8)
   

4. Confirma el nuevo estado.

   # /c/usr/devsecops/compliance-inventory (master|REVERTING)
   $ git commit -m "revert master to 83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8"
   [master af82538] revert master to 83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8
   

5. Envía la actualización a la rama maestra.

   # /c/usr/devsecops/compliance-inventory (master)
   $ git push --set-upstream origin master
   ...
   To [https://us-south.git.cloud.ibm.com/jaunin.b/compliance-inventory.git](https://us-south.git.cloud.ibm.com/jaunin.b/compliance-inventory.git)
     67cc8ba..af82538  master -> master
   ...
   

Activar el proceso de implementación continua

1. Crea una solicitud de extracción para los cambios de promoción de reversión.

2. Revise y fusione el pull request.

3. Activa la ejecución manual del proceso de CD en tu cadena de herramientas de CD.

Descripción general de la reversión en línea

Este modo revierte la implementación actual dentro del contexto de la misma ejecución del canal. Es necesario cuando se produce un error o fallo durante la fase de implementación o la prueba de aceptación, lo que provoca que el intento de implementación se marque como fallido.

Una reversión en línea se ejecuta automáticamente si la propiedad rollback-enabled del entorno está establecida en 1 y se produce un fallo en la fase de prueba de implementación o aceptación.

Si se activa una reversión, el proceso de CD ejecuta el segmento definido para rollback en su .pipeline-config.yaml archivo. Si un rollback segmento no está definido en el archivo, se ejecuta una implementación predeterminada y se le solicita que proporcione un script de reversión.

Ejemplo de script de reversión en .pipeline-config.yaml:

rollback:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.74
  script: |
    #!/usr/bin/env bash
    if [[ "$PIPELINE_DEBUG" == 1 ]]; then
      trap env EXIT
      env
      set -x
    fi
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/deploy_setup.sh
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/rollback.sh

Propiedades establecidas durante la reversión en línea

• rollback-status: Indica el estado del paso de reversión. Valores posibles: [notRun, success, failure]
• rollback-exit-code: El código de salida del paso de reversión. Este valor está vacío si la reversión no se ha ejecutado.
• default-rollback-executed: Establecer en true si se ejecutó la implementación predeterminada (que solicita un script). Este valor está vacío por defecto.
• pipeline-execution-status: Indica el estado general de la ejecución del proceso. Valores posibles: [successful_deployment, failed_deployment_failed_rollback, failed_deployment_successful_rollback]