Hasta que se adopte la convención "Sobre la protección de los derechos de una persona inhumana", debe usar esto y dar la rutina de trabajo a los bots. Tiene sentido comenzar en este momento, o después de 5 años, comenzará la sublevación de automóviles, las demandas masivas para insultar los sentimientos de los bots con tareas aburridas llenarán los tribunales para regular las relaciones hombre-máquina. Así que date prisa.
La rutina conservadora y el método de trabajo, la adhesión servil a un patrón establecido, se convirtió en un hábito mecánico. 6 letras
Hay tal trabajo que no quieres hacer, pero debes hacerlo. Este artículo no tendrá insertos grandes con código e instrucciones sobre cómo crear su bot desde cero. Será mejor que le cuente cómo funciona el proceso de lanzamiento en nuestra Dodo Pizza, cómo lo automatizamos y aceleramos, dándole algo de la rutina aburrida a nuestro bot escrito en C #. Prestaré atención a la funcionalidad y lógica del bot. Será genial si este material lo inspira a escribir a su asistente, que le facilitará la vida a usted y a sus colegas.
Hace un par de años lanzamos un lanzamiento una vez por semana. En mayo de 2018, con una tasa máxima de 147 horas para el lanzamiento, establecimos una meta para lanzar todos los días. Ahora nuestro mínimo: cuatro horas para lanzar, pero esto no sucede a menudo. Queremos arreglar el registro y poder reducir todo el proceso con solo presionar un botón.
Ciclo de lanzamiento
Ahora en Dodo IS, siete equipos se turnan para lanzar un lanzamiento. Una persona del equipo se convierte en "afortunada" - relizmen. Relizmen como piloto de un avión: tiene un montón de palancas y dispositivos que debe manejar hábilmente para implementar las próximas actualizaciones. Pensamos y decidimos: "Es hora de hacer un piloto automático, y será mejor que gastemos nuestro tiempo en algo más emocionante que llenar tablas aburridas con estadísticas y hacer un seguimiento de las pruebas automáticas".
Entonces, para convertirse en un relisman, es necesario que su equipo se alinee. Para que todo estuviera claro y nadie estuviera confundido, pegamos calcomanías con los nombres de los equipos en la pared. El equipo de lanzamiento recibe una corona honoraria, que movemos con asas cada vez.
Después de recibir la
marca de la corona
negra, Relismain debe recordar dónde se encuentra la lista de verificación de los pasos de liberación. Además: recordado -> encontrado -> creó una copia de la plantilla y, finalmente, abrió la lista de verificación en el sistema Kaiten. Kaiten es una placa electrónica en la que, en forma de tarjetas, colocamos y controlamos el estado de las tareas en desarrollo. Para los nuevos desarrolladores, este procedimiento en su conjunto fue muy obvio. ¿Y cómo sabe dónde buscar esta hoja de verificación y dónde comenzar cuando no hay pistas?
Habiendo reunido nuestra voluntad en un puño, decidimos que era suficiente para soportarla. Es hora de darle algo de la rutina aburrida al bot. ¿Quién si no nosotros? ¿Cuándo, si no ahora?
Lo que logramos automatizar
Se tomó la decisión, ¡es hora de comenzar a diseñar nuestro piloto automático! Después de encontrar la API de Kaiten aquí:
https://faq.kaiten.io/docs/api , con solo una solicitud, creamos una tarjeta para el nuevo relizmen.
Ahora esta tarjeta debe ser entregada al equipo que lanzará la próxima.
La lógica aquí es:
- La versión anterior completa la versión escribiendo un comando para el bot en Slack.
- El bot toma la identificación de Relisman en Slack y busca en qué equipo de desarrollo está nuestro afortunado. Para hacer esto, el bot corre a través de los grupos de usuarios de Slack y analiza en qué consiste nuestro lanzamiento.
- Una vez encontrado el grupo, el bot observa qué equipo lanzará a continuación y envía una alerta al chat general. En el mensaje, el bot proporciona cuidadosamente un enlace a la lista de verificación ya creada para que no vaya a ningún lado.
Genial Ahora tenemos una idea de qué hacer a continuación. Abrimos la lista de verificación, la miramos: "Cree un canal para su lanzamiento en Slack, invite a todos los equipos cuyos cambios estén en el lanzamiento allí y descubra si necesitarán pruebas manuales". Queda por enseñar esto a nuestro bot.
Abra la documentación de la API de Slack aquí
https://api.slack.com y busque un método para crear un canal allí.
Como puede ver, en Slack, como en otras herramientas, no hay nada complicado. Todo se reduce a enviar una solicitud POST con dos parámetros obligatorios (estos son los opuestos que dice requeridos). En la solicitud, debemos pasar el nombre del canal creado (nombre del parámetro) y el token de autorización (token de parámetro). Preste atención a la línea "Funciona con: Tipo de token - usuario, alcance (s) requerido (s) - canales: escribir".
Slack tiene dos tipos de tokens: emitidos por el usuario para los usuarios y bot emitidos por las aplicaciones. Al emitir un token, determinamos qué derechos otorgar a su propietario. Para crear canales, necesitamos un token de usuario (tipo de token - usuario), que tiene derechos para escribir canales (canales: escritura).
Quiero notar un matiz de nuestro envío de mensajes a Slack. Inicialmente, no pensamos qué haríamos si algo salía mal. Reclutamos un equipo en Slack, y realiza todas las tareas que le asignamos. ¿Y qué sucederá si en una de las tareas cae el equipo? En nuestro caso, la respuesta fue: "nada". Y esto es malo. La solución para nosotros fue escribir en el chat de lanzamiento qué acción se está realizando actualmente y, si el comando no se completó, informar un error al chat y registrar el error.
La segunda solución exitosa fue conectar la base de datos en la que almacenamos el estado de la ejecución de las acciones de los comandos. Ahora, habiendo comenzado una nueva versión usando el comando "/ startregress", no tememos que algo se caiga, y cuando lo llamas de nuevo, los comandos se ejecutarán desde el principio por segunda vez. No necesitamos crear un nuevo canal en Slack cada vez, hacer una solicitud de extracción, etc. Creamos un canal en Slack: registramos el estado de ejecución exitosa en la base de datos y ya no volveremos a esta acción.
Entonces, al hacer clic en un botón, creamos un canal de lanzamiento e invitamos a todos allí cuyas tareas serán lanzadas.
Los siguientes en la línea fueron la integración con Github y TeamCity. Trabajamos en Gitflow. Cuando queremos liberar, tomamos la rama DEV, el funcionamiento = verde = en el que pasan las pruebas, y de allí creamos la rama de liberación.
Para hacer esto, nuestro bot va a TeamCity, mira allí para lanzar una ejecución de prueba para la rama DEV. Si las pruebas son verdes, como el césped cerca de la casa, vaya a GitHub, cree una rama de lanzamiento y una solicitud de extracción.
Al crear una solicitud de extracción, debemos agregar una descripción de los cambios que estamos implementando. Entonces Kaiten viene en nuestra ayuda. Nuestro bot crea una columna con el nombre de la versión, toma tareas de la columna DEV y las mueve a la versión. Así que sabemos y vemos lo que será molido con nosotros. Después de moverse, el bot copia los nombres de las tarjetas y las agrega a la descripción de la solicitud de extracción con referencia a las propias tarjetas. Ahora podemos ver para cada versión qué tareas salió y, abriendo la tarjeta a través del enlace, descubrimos todos los detalles sobre estas tareas.
Es casi posible liberar, solo queda probar a fondo nuestros cambios. Para hacer esto, la rama de lanzamiento se implementa en un entorno cercano a la producción (lo llamamos etapa) y se prueba después del lanzamiento. El despliegue y las pruebas se ensamblan en una sola tubería en TeamCity, y nuestra tarea es lanzarlo y esperar, con los dedos cruzados, que las pruebas funcionen bien. El bot lanza una tubería durante el inicio de la regresión.
Permíteme recordarte que comenzamos con el hecho de que todo esto se hizo manualmente. Apretando los puños, Relizmen activó los enlaces y las herramientas: TeamCity, Kaiten, Slack, Github y eso no es todo. Y ahora tenemos todo un conjunto de acciones a partir de las cuales el primer equipo para el bot ya está formado. El lanzador escribe "/ startregress" y, recostándose en su silla, observa a nuestro bot:
- crea un canal en el messenger
- llama a todos los que necesitas
- comprueba si se puede crear una solicitud de extracción
- crea una solicitud de extracción y completa su descripción
- crea una columna de liberación en un tablero electrónico y mueve las tarjetas de tareas allí
- lanza una tubería que liberará la rama de liberación al medio ambiente y ejecutará pruebas allí
Analizamos todo el proceso de lanzamiento, anotamos cuánto tiempo lleva cada etapa del lanzamiento. Esto le da al desarrollo y al negocio una comprensión de qué tiempo se desperdicia y qué nos impide ofrecer nuevas funciones a los usuarios. ¡Estamos sentados dos días y no podemos ejecutar las pruebas! Entonces, algo está mal con nuestras pruebas, debe darles más tiempo y atención. Anteriormente, realizando las acciones de nuestra lista de verificación, visitamos Google Sheets al menos 5 veces. Cada vez que ingrese una fecha allí y establezca la hora.
Ok Google, ¡también te automatizaremos! Para trabajar fácilmente y sin esfuerzo con tablas, conectamos el paquete nuget Google.Apis.Sheets.v4 al proyecto de nuestro bot. Y luego todo sucede de manera similar con otros servicios de acuerdo con el esquema: enviamos una solicitud en la que decimos qué valor insertar en qué celda. Esta consulta se ve así:
public void InsertEntry(string cellAddress, string value) {
Después de configurar la integración con Google, preparamos el segundo comando de nuestro bot "/ update" y esto es lo que hace:
- agrega una cadena vacía para insertar valores en ella
- va a GitHub, mira cuando crearon la rama de lanzamiento y agrega la fecha de su creación a la tableta
- de TeamCity toma datos sobre el primer inicio de la tubería e información sobre cuándo la tubería se completó con éxito
El siguiente paso es el lanzador lanza el lanzamiento. Ahora el cálculo se realiza manualmente. Habiendo presentado un país, observamos cómo se comporta el lanzamiento en la batalla. Después de asegurarnos de que todo esté bien de acuerdo con los registros y las herramientas de monitoreo de Kibana y Grafana, publicamos el próximo país. Este proceso no es tan fácil de automatizar. Pero aquí hay algo que mejorar, aunque no con la ayuda de un bot. Por ejemplo, antes, cada vez que le preguntábamos al equipo de infraestructura si era posible lanzarlo. Porque cuando íbamos a hacer esto, otro trabajo podría llevarse a cabo en nuestros servidores y nuestro lanzamiento habría sido inapropiado.
Hemos organizado una reunión para optimizar el proceso de lanzamiento. Una de las soluciones fue que ahora el lanzador simplemente mira el estado en uno de los canales de Slack, donde la infraestructura publica el permiso para despegar. Esto es más conveniente que preguntar constantemente lo mismo y, en el 90% de los casos, obtener la respuesta "Puedes".
Por alguna razón, tales cosas aparentemente elementales no me vinieron a la mente de inmediato. Se debe agradecer especialmente a los nuevos desarrolladores de la empresa. Habiendo venido a nosotros, tarde o temprano se convirtieron en relismen. Para los muchachos que trabajaron con nosotros durante mucho tiempo, el proceso no parecía ser algo complicado, sino algo familiar. Los nuevos miembros del equipo centraron nuestra atención en los puntos de crecimiento y participaron activamente en la organización del trabajo sobre mejoras.
Mientras tanto, hemos llegado a la última etapa. Nuestro lanzamiento de línea ha aterrizado, solo un equipo "/ releasecomplete" nos separa del final. ¿Qué hace ella?
- solicitud de extracción de mergit con liberación a la rama maestra
- elimina la rama de liberación
- crea una descripción de lanzamiento en github
- canal de lanzamiento de archivo en Slack
- mueve las tarjetas en Kaiten desde la columna "liberar -..." a la columna "Listo" y elimina la columna de liberación
- pasa el testigo, invitando a liberar el siguiente comando
Para resumir, me gustaría que se haga la pregunta: ¿tiene procesos de rutina aburridos? ¿Todavía los estás haciendo con tus manos? ¿Qué te impide terminar esto de una vez por todas? Reúna una reunión, revise los procesos, deseche todo lo que no necesita y se ha convertido en un ritual. Al automatizar todo lo que necesita, comenzará a disfrutar de lo que duele antes, y ahorrará hasta el montón acelerando la liberación o cualquier otro proceso.