Guía para crear aprobadores manuales en AWS Pipeline
Crea aprobadores manuales para AWS Pipeline
Por Josué Armando Vázquez, Infrastructure DevOps en Financial Solutions
Cuando realizamos pases productivos, tenemos ciertas limitaciones con respecto a políticas específicas de acceso al repositorio y rama productiva, utilizando las mejores prácticas de Gitflow, podemos lanzar o revisar código al momento de realizar un pull_request , merge o push.
¿Cómo podríamos rectificar que estás acciones son correctas y que no se realizarán más despliegues de los debidos?
En Financial Solutions, tenemos un candado adicional a la hora de desplegar, a esto se le llaman aprobadores manuales; en el momento en que algún pipeline productivo detecta que existe una nueva versión de compilación, esta lanza una notificación a nuestro equipo de QA y a nuestro equipo de Infraestructura, los cuales tienen la obligación de aprobar o rechazar el pase dependiendo el caso.
Nuestros pipelines productivos constan de tres etapas:
Source: en esta etapa se identifica que existe un nuevo compilado e inicia las etapas siguientes.
Approvals: en esta etapa se lanzan las notificaciones a los equipos correspondientes para que estos a su vez puedan aprobar el despliegue de la nueva versión.
Deploy: en esta etapa final se realiza un backup del compilado anterior (en caso de front y back) y posteriormente se realiza el despliegue de la nueva versión.
En este artículo te guiaremos paso a paso para ayudarte a crear estos aprobadores en tus canalizaciones productivas.
Antes que nada, debemos crear nuestros grupos de distribución para las notificaciones:
En el panel de control, seleccionamos la opción de temas.
En la cintilla superior seleccionamos el botón Create New Topic (Crear un nuevo tema), en Topic Name (Nombre del tema), escribe un nombre para el tema. Para esta guía utilizaremos los nombres de aprobacion_qa o bien aprobacion_infra.
De igual forma, utilizaremos un tipo de sns estándar ya que no se requiere de un alto rendimiento y requerimos un protocolo de suscripción para correo electrónico.
Una vez creado nuestro tema, para el envío de correos, necesitamos suscribir a las personas que estarán encargadas de aprobar o rechazar los pases, para esto seleccionaremos en el menú inferior la pestaña de Create subscription (crear suscripción).
A continuación, se elegirá por default el tema que creamos; en el combo de los protocolos, seleccionamos la opción de email y añadimos el correo al que deseamos se le notifique en la opción de endpoint.
Una vez creada la suscripción, nos aparecerá el contacto en estado “pendiente por confirmar”, SNS mandará un correo de confirmación a la cuenta que fue suscrita y esta deberá confirmar para poder recibir notificaciones.
El correo que le llegará a las personas suscritas debe ser muy parecido al siguiente:
Una vez confirmado el correo, cambiará de estatus la suscripción en el tema a Confirmed (confirmado), como se muestra a continuación:
Una vez creado nuestro tema de SNS, estamos listos para agregar a nuestra canalización los aprobadores.
Seleccionamos la canalización a la cual vamos agregar las aprobaciones manuales. Una vez elegida, seleccionamos la opción de editar.
Nos mostrará este apartado en pantalla, para agregar etapas a nuestra canalización:
Al dar clic en agregar etapa, lo primero que nos pedirá será el nombre:
Una vez agregada la etapa, al dar clic en “agregar grupo de acción”, nos desplegará varias opciones. A nosotros nos interesa agregar un aprobador manual.
Al seleccionarlo, cambiará el menú de inmediato para ingresar las opciones de los aprobadores:
Los cuatro campos que muestra los marca como opcionales, ya que se puede configurar la aprobación, sin necesidad de mandar notificación automática o mandar parámetros adicionales en esas notificaciones.
Dependiendo de las necesidades que se tengan o las obligaciones a cumplir antes de algún pase, se utilizan los campos adicionales que nos proporciona Amazon.
A nosotros nos interesa poder notificar a los equipos de trabajo de manera automática, por lo tanto, en el campo SNS topic ARN, seleccionaremos el tema de notificaciones que creamos anteriormente.
Entonces quedaría de la siguiente forma:
Una vez seleccionado nuestro grupo de notificaciones, aceptaremos la edición; primero de la acción y después de la etapa. Una vez aceptados los cambios es necesario guardar las modificaciones del pipeline.
Una vez guardados y aceptados los cambios, nos mostrará nuestra nueva etapa, en estatus “Didn’t Run “y la leyenda “No executions yet”, esto es porque esa etapa no se ha ejecutado aún.
Esta se ejecutará la próxima vez que se lance nuestra canalización de manera automática o bien se pueden probar las notificaciones lanzando la canalización de manera manual, para esto dentro de nuestro pipeline con la aprobación, seleccionamos el botón release change .
Nuestra etapa se mostrará en color azul, en modo de espera por la aprobación.
En este momento la notificación ya fue enviada a los correos que se dieron de alta previamente y queda en espera de la aprobación necesaria.
Si la quisiéramos ver a detalle nos muestra el nombre del pipeline donde se solicita la aprobación, en qué etapa se encuentra, región y la acción que lo requiere, ya que podemos tener varios aprobadores y en la notificación mencionará cual acción es la que le corresponde. Adicionalmente, nos pone una liga directa hacia el pipeline que debemos aprobar.
Una vez que tengamos este correo, se requiere que quienes estén asignados para aprobar o rechazar un pipeline tengan un usuario para entrar a la consola, con los debidos permisos, para poder aprobar solo la acción que le corresponde.
Para esto podemos crear grupos de iam, a los cuales asignarle la política correspondiente.
Crearemos el grupo sin ninguna política, ya que la asignaremos de manera personalizada y única. Una vez creado, seleccionaremos nuestro grupo de aprobaciones y en la pestaña de permisos agregaremos una política en línea.
En formato JSON, en la política que se muestra debajo, solo debe ser cambiado el nombre del pipeline, la etapa y acción requerida, para negar el permiso de aprobar alguna acción que no le corresponda.
Supongamos que se tienen dos acciones requeridas en las aprobaciones, por un lado, se encuentra la aprobación perteneciente a infraestructura y la aprobación para el equipo de calidad.
Si en la política que estamos creando solo debemos restringir a infraestructura, para que solo pueda modificar lo que te toca, es necesario especificar en el segundo fragmento de la política, que se le prohíbe la manipulación de alguna otra aprobación que no le corresponda (la línea a modificar se muestra subrayada en amarillo).
De esta forma se limita para que solo pueda aprobar su acción correspondiente y no pueda manipular la aprobación del equipo de QA.
La política para el equipo de calidad deberá ser igual, restringiendo en este fragmento la acción que no deberá manipular.
Una vez declaradas las políticas para cada grupo podrá rechazar o aprobar sus acciones correspondientes. Los cuales dependiendo del caso mostrarían approved o rejected . La pantalla de aprobación se muestra de la siguiente manera:
Las dos primeras leyendas, se refieren a comentarios adicionales que se hayan agregado desde la configuración del aprobador, así mismo alguna url que se deba revisar previa a la aceptación de la acción y de esta forma nos permite agregar comentarios adicionales.
A continuación, se mostrará como luciría en caso de ser aprobado o rechazado:
Si se hizo la aprobación, le damos clic en detalles y nos desplegará la siguiente información:
Aquí se muestra el detalle de la aprobación, comentarios e inclusive nos muestra el usuario que realizó la acción:
Si se ha rechazado, mostrará el siguiente estatus
Y de igual forma, nos mostrará el detalle del estatus:
Una vez teniendo aprobadores en nuestra canalización, para que este pueda continuar con las etapas siguientes, debe aprobarse, si se tienen dos aprobadores, ambos deben aceptar el que continúe la canalización, de lo contrario no se ejecutarán las etapas siguientes y pipeline mostrará su estatus como rechazado.
Es de suma importancia considerar tener en nuestras canalizaciones este tipo de aprobadores, ya que solo de esta manera podemos asegurar que no se realicen cambios sin autorización, despliegues no probados o versiones no correspondientes.
¡Cuéntame si te funcionó y comenta qué otros tutoriales te gustarían leer!
This site uses cookies to help us to improve your experience each time you visit it. By continuing to browse it, * you're accepting its use. You can disable them by accessing your browser settings.
Functional
Siempre activo
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferencias
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Estadísticas
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.