Header Ads Widget

Ticker

6/recent/ticker-posts

Tres mejores prácticas para lograr el lanzamiento cuando esté listo

 

Tres mejores prácticas para lograr el lanzamiento cuando esté listo

Hablemos de lanzar software . Tómese un minuto, cierre los ojos y evoque lo siguiente en su cabeza: ha estado trabajando en una nueva función / aplicación asesina durante algunas semanas, y ahora es el momento de lanzarla.

¿Que estás sintiendo? ¿Emoción, esperando ampliar su oferta? Alivio, ¿ahora que ha terminado con una gran cantidad de trabajo? ¿Orgullo en usted y en el trabajo de su equipo? ¡Increíble! Pero estas nervioso ¿Está nervioso por haber roto una función clave que causará problemas a sus usuarios? ¿Qué pasa con la ansiedad de que estás empujando algo tan grande que no tienes idea de si funcionará o no en primer lugar? ¿Teme haber pasado semanas en una función que nadie usará?

No se desespere, no está solo. Los desarrolladores de todo el mundo también sienten estas cosas y, hasta cierto punto, son saludables. El nerviosismo, la ansiedad y el miedo nos mantienen alerta. Garantizan la diligencia y el rigor en la especificación, ejecución y pruebas. Dicho esto, estos sentimientos también pueden conducir a malos comportamientos que nos roban la productividad y a nuestros usuarios de las funciones que necesitan para tener éxito.

Todos hemos estado allí. Todos hemos creado construcciones para tratar de aliviar estos sentimientos: lanzamientos semanales, quincenales, mensuales e incluso trimestrales programados. Se reservan grandes bloques de tiempo para realizar pruebas para garantizar que todo funcione según las especificaciones. Cambie las ventanas de la noche a la mañana para no afectar a los usuarios en caso de que algo salga mal. Estas estrategias no son malas en sí mismas, pero observe sus objetivos. El objetivo de cada una de las estrategias anteriores es condensar la responsabilidad de lanzar software en una caja ordenada, de la que nos ocuparemos en el tiempo que hemos reservado para hacerlo. Sin embargo, esto hace una suposición bastante audaz: que lanzar software es algo que hay que temer. Insertar código es difícil y causa problemas, por lo que buscamos minimizar la frecuencia de hacerlo porque eso es más fácil para nosotros.

El propósito de esta publicación es desafiar esa suposición. La respuesta a este problema no es minimizar el número de lanzamientos, sino maximizarlos. Empuje más código . Empuje el código tan pronto como esté listo. No espere ventanas de lanzamiento arbitrarias: ese es el software que su comunidad necesita, que usted tiene, que no les está dando. No se retuerza las manos con ansiedad por una liberación que puede tener consecuencias inesperadas: nunca las atrapará a todas, y definitivamente nunca arreglará las que tiene si no deja que la gente encuentre ellos.

En su lugar, publique el software en partes pequeñas y específicas para que pueda administrar sus áreas de impacto. Asegúrese de que el código que ha escrito se pruebe automáticamente según sus estándares, de modo que no tenga que pensar en regresiones. La liberación debe ser simple, de modo que cuando rompa algo (y lo hará, así que acéptelo también) pueda liberar fácilmente la solución. Finalmente, asegúrese de saber cuándo ha roto algo a través del monitoreo . Los humanos que miran los archivos de registro no escalan, pero las alertas automáticas sí.

Seguir estas tácticas hará que la liberación no sea un evento con una ansiedad mínima. ¿Preparado para comenzar? Bueno. Hablemos de las tres mejores prácticas que lo llevarán a donde necesita ir.

1: Integración continua

La Integración Continua , o CI , es la práctica de integrar continuamente código comprometido en
un repositorio compartido. Ese repositorio compartido se crea, prueba y analiza a través de las herramientas que el equipo considere apropiadas. Esto está lejos de ser un concepto nuevo, pero es la piedra angular de cualquier proceso de lanzamiento exitoso cuando esté listo.

El primer paso es seleccionar una herramienta de CI. Afortunadamente, hay una gran cantidad de herramientas para elegir. Las soluciones autohospedadas (necesitará un servidor y para mantenerlo usted mismo) incluyen Jenkins y TeamCity. Las soluciones basadas en la web (por lo general, tendrá que pagarle a alguien por estas) incluyen Travis, SolanoCI y CircleCI. A muchos desarrolladores les gusta Jenkins: es completamente FOSS, tiene una comunidad de desarrolladores masiva para complementos y extensiones, y acaba de lanzar una versión 2.0 bastante dulce que aborda muchas preocupaciones de los usuarios.

Para obtener más herramientas de CI y comparaciones, consulte nuestra publicación sobre potentes herramientas de integración continua

Una vez que tenga su herramienta, deberá averiguar cómo usarla. Los pasos básicos para CI son compilar (si está utilizando un lenguaje compilado o algún tipo de plataforma de minimización / ofuscación / optimización) y probar . La prueba, en este caso, es variable. Las pruebas más básicas que debe ejecutar son las pruebas unitarias .

Sin embargo, no tiene por qué detenerse allí. ¿Tiene pruebas de integración para asegurarse de que sus API estén cumpliendo sus contratos? Podrías ejecutarlos aquí si son lo suficientemente rápidos. ¿Tiene pruebas funcionales para asegurarse de que los flujos de usuarios funcionan? Enciéndelos. ¿Qué tal las pruebas de rendimiento o capacidad para garantizar que sus cambios se ajusten a sus números de tiempo de respuesta y tiempo de actividad? Ahora podría ser un buen momento.

Por supuesto, ejecutar todas estas pruebas lleva tiempo. Y dado que no estamos hablando de Entrega continua aquí (presionando a todos y cada uno a comprometerse con la producción tan pronto como esté hecho), ejecutar esta batería de pruebas en listas de cambios intermedias probablemente sea más general de lo que vale. Eso no significa que no deba ejecutar estas pruebas, sino que debe ser estratégico al momento de ejecutarlas. Más sobre eso más tarde.

Por último, considere utilizar su plataforma de CI para automatizar las herramientas de calidad del código . Estos incluyen herramientas de análisis estático como linters o detectores de ciclo de complejidad, herramientas de calidad de prueba como informes de cobertura de código o simplemente información directa como contadores de línea de código. Información como esta rara vez conduce a mejoras directas en el rendimiento de su software, pero son invaluables para la legibilidad del código, el mantenimiento del código y la velocidad de desarrollo.

2: Haga la implementación sin cerebro

Ahora que tiene la integración continua en funcionamiento, es hora de tomar ese código y publicarlo en vivo. La primera vez que inicia, esto es simple: SSH al servidor, Git pull, tal vez reinicie Apache… ¡voilá! Nuevo código en vivo en el sitio web. Tiempo de fiesta.

A medida que su producto continúa creciendo, debe hacer más cosas, como crear plantillas de bigote, generar documentación de API , actualizar bibliotecas de cliente , minimizar su JS / CSS, actualizar crons, resolver conflictos de dependencia y más. Esto convierte rápidamente el proceso de implementación de un comando que tomó minutos en un asunto intimidante que puede llevar horas si se realiza manualmente. Además, es mucho para que una persona lo recuerde, por lo que muchas empresas asignan la responsabilidad de lanzar software a un equipo en particular como Quality u Ops.

Este escenario tiene varios inconvenientes importantes. Por un lado, la implementación manual lleva mucho tiempo. En segundo lugar, confiar esta responsabilidad a un solo equipo tiene consecuencias peligrosas. Si solo unas pocas personas pueden implementar el código, debe esperar a que una de ellas esté disponible para su lanzamiento. Una fuerza un poco menos obvia pero igualmente dañina en juego en este sistema es que el desarrollador no es responsable en última instancia de asegurarse de que sus cambios se activen. La transferencia en este proceso hace que no quede claro quién es responsable de ayudar a abordar los problemas que pueden surgir tras la liberación. Si el desarrollador que escribió el código estaba lanzando el código, entonces estaría en mejores condiciones de determinar qué va mal en el lanzamiento y cómo solucionarlo.

Entonces, ahora que hemos pintado la imagen, la solución se vuelve bastante clara: hacer que la implementación sea absurda . Hágalo rápido también, pero sobre todo hágalo tan fácil que cualquiera pueda hacerlo. ¿Cómo? Como esto:

Paso uno: escriba un script de implementación.

Este script debería poder tomar una compilación / artefacto / etiqueta / algún identificador de qué código publicar como entrada y realizar una implementación completa de ese código en sus servidores de producción. Debería encargarse de llevar la compilación a los servidores, instalarla en los directorios correctos, actualizar las bibliotecas cliente necesarias y reiniciar los servicios necesarios para realizar una implementación completa de su software. Una vez que haya ejecutado este script, puede iniciarlo desde su entorno de integración continua del que hablamos anteriormente. Los desarrolladores pueden simplemente ejecutar este script desde su herramienta de integración continua cuando quieran implementarlo, y lo manejará por ellos. Una vez que lo haya escrito, haga todo lo posible para hacerlo rápido. Las computadoras son buenas para tareas repetitivas: haga que su guión sea rápido y liberará a su gente para que se concentre en las cosas en las que son buenos.

Entonces, no es un mal comienzo. Sin embargo, todavía hay mucho que recordar: ¿Dónde vive el guión? ¿Qué argumentos se necesitan? Si hay varios pasos, y generalmente los hay, ¿en qué orden los ejecuto? Entra chatops.

Paso dos: use ChatOps.

Chatops es un término nuevo para un concepto antiguo: usar un cliente de chat para administrar cosas como implementación, ejecuciones de prueba y tareas generales relacionadas con las operaciones. El término fue acuñado por GitHub, quien también lanzó un pequeño y maravilloso bot llamado Hubot , habilitador de Chatops. Hubot es, en esencia, un bot simple: escucha tus chats y realiza acciones en función de lo que dices. Lo bueno de Hubot es que viene con una pila de scripts de integración para herramientas como Jenkins, que le permiten a Hubot ejecutar trabajos activados por usted desde su cliente de chat.

Estás empezando a verlo, ¿verdad? En lugar de tener que encontrar su servidor de CI, recuerde el nombre del trabajo de implementación (y cómo ejecutarlo), simplemente puede hacer que Hubot lo haga por usted. Le dará el inicio al trabajo de implementación y le dirá cuándo está terminado. Pero eso no es todo: es completamente de código abierto y es muy fácil escribir scripts para ampliar su funcionalidad. Esto hace posible crear cosas como sistemas de cola para entornos de prueba de preproducción, scripts para actualizar las bases de datos locales con los últimos cambios de producción o rastrear quién va a almorzar y dónde, oye, tú también debes divertirte.

Estos dos pasos crean un sistema que permite a cualquiera implementar código en el sitio web de producción. Eso es poderoso: le permite crear una cultura de autonomía CON responsabilidad: ahora puede presionar el código a las 2 a.m. de un domingo (pero será mejor que esté allí para solucionarlo si algo sale mal). Esto impulsa el compromiso de su equipo y escala a medida que su equipo y su organización crecen, dos cosas que un proceso de implementación tradicional no logra.

¿Listo para comenzar con ChatOps? Vea nuestra lista de más de 12 marcos para construir bots de ChatOps

3: Monitoreo

Ahora estamos llegando a algo: tenemos un entorno de CI que está probando e informando sobre cada compilación, y también tenemos un script de implementación y ChatOps en ejecución, manejando nuestras implementaciones por nosotros. ¡Lindo! Sin embargo, hay una cosa que aún no hemos mencionado: ¿cómo saber cuándo algo salió mal? Seguimiento .

Es necesario monitorear sus sistemas y configurar alertas cuando se implementa una aplicación de tamaño significativo. Al igual que las tareas mencionadas anteriormente, las computadoras monitorean mejor que los humanos: no duermen, comen ni se aburren. También son muy buenos para recopilar y almacenar datos.

Existen muchas soluciones de monitoreo excelentes: para el monitoreo de infraestructura / aplicaciones Datadog , New Relic y Nagios son algunas opciones. Cada uno de estos viene con un conjunto de integraciones incorporadas para monitorear la infraestructura y los servicios comunes: Apache, NGINX, HAProxy. Etc. También existen herramientas para monitorear y analizar registros ( Logstash , fluentd ), rastrear el tráfico y conversión de usuarios ( Google Analytics , Mixpanel ) y para construir inteligencia comercial ( Looker , Tableau ). Enfocaremos esta publicación usando el monitoreo de infraestructura como ejemplo, pero las mismas técnicas se aplican a otros sistemas de monitoreo.

Entonces, ya está por delante del juego: tiene nuevos datos sobre lo que está sucediendo debajo del capó. La siguiente pregunta obvia es: ¿qué haces con él?

Identificación de KPI para el monitoreo de infraestructura

El primer paso para muchas personas es comenzar a configurar alertas sobre todo: tasas de error de HAProxy, carga de CPU del servidor y tiempos de IOWait para el almacenamiento. Esto no es lo peor, ya que lo obliga a mirar toda su infraestructura, pero no tiene dirección: sin una idea específica de lo que está buscando, tendrá dificultades para separar la señal del ruido.

En lugar de sumergirme directamente en el manejo de alertas y el seguimiento de incidentes, recomiendo identificar primero sus KPI para su infraestructura. Para las API en particular, algunos KPI comunes son los siguientes:

  • Volumen de solicitudes : ¿Cuánto tráfico estamos recibiendo? ¿Cómo se relaciona eso con nuestro promedio? ¿Está creciendo nuestro uso?
  • Tarifas 2xx / 3xx / 4xx / 5xx : ¿Estamos brindando a nuestros clientes una buena experiencia? ¿Estamos viendo muchos 400/500? Si es así, debemos determinar por qué y resolverlo.
  • Carga del servidor : ¿Cómo escalamos? ¿Cuántos clientes más podemos manejar antes de que necesitemos ampliar nuestra capacidad de alojamiento?
  • Tasa de registro de errores : ¿Cuál es nuestra tasa de errores (syslog, registro de aplicaciones, etc.)? ¿Está elevado según la norma? Si es así, ¿liberamos algo roto? ¿O las cosas no se están comportando como esperan nuestros usuarios?

Una vez que seleccione sus KPI, deberá dejar tiempo para identificar sus rangos normales . Por ejemplo, podría esperar 400 conexiones simultáneas en un momento dado, o una tasa de 99% 200/300 y una tasa de 1% 400/500. Una vez que haya identificado estas normas y un rango aceptable alrededor de ellas, puede configurar alertas para cuando se excedan. Esto puede ser tan simple como un umbral (estamos por encima del 2% de tasa 400/500 = alerta) para configuraciones más complicadas (estamos viendo un volumen de solicitudes mayor de lo normal de la dirección IP X durante los últimos 10 minutos - es este DDoS?). Esto le permitirá identificar y reaccionar rápidamente ante situaciones anormales en lugar de tener que esperar a que sus clientes le digan que hay un problema.

Una vez que haya identificado sus KPI, el siguiente paso es mostrarlos de la manera más prominente posible. ¿Trabajo en una oficina? Coloque un televisor en la pared y muestre sus KPI en tiempo real para que todos los vean. ¿Trabajando desde casa? Mantenga una pestaña abierta y revísela con frecuencia. ¿Utiliza una aplicación de chat como Slack? Habilite una integración para publicar sus KPI directamente en los canales de interés. Descubrirá que cuanto más muestre estos números y hable de su importancia, más usted y su equipo se centrarán en mejorarlos.

Armado con alertas automáticas, un desarrollador puede diagnosticar, depurar, corregir y liberar rápidamente. Dado que estamos probando y lanzando automáticamente con tanta frecuencia, nuestra huella de cambio es pequeña y fácil de arreglar.

Publicar cuando esté listo se trata realmente de la propiedad del desarrollador

Todo esto se suma a uno de los impulsores más importantes de la participación de los desarrolladores: la propiedad . Ahora que los desarrolladores pueden codificar, probar, lanzar y monitorear el software en producción sin la ayuda de equipos externos, el mundo es su ostra. ¿Quieres llevar algo a producción un sábado por la noche? ¡Ve a por ello! ¿Necesita salir a las 3 a. M. Porque acaba de cerrar un agujero de seguridad? Nadie te detiene.

Sin embargo, es importante señalar que la descentralización de la propiedad aumenta la responsabilidad individual Los desarrolladores con el poder de realizar cambios también deben estar presentes para corregirlos, lo que significa que si algo se rompió durante la implementación de 3AM, debe repararlo antes de cerrar la sesión. Moderar el poder de la propiedad con la responsabilidad y las técnicas discutidas anteriormente creará un equipo que se mueve rápido, libera con confianza y se siente valorado debido a la inversión realizada en sus herramientas.

Ahí lo tiene: tres técnicas que su equipo puede usar para adoptar la mentalidad de lanzamiento cuando esté listo. Ciertamente, esta no es la única forma de lograr la liberación cuando esté lista, pero son técnicas probadas que se han utilizado con éxito. ¿Tiene preguntas o sugerencias sobre la filosofía de lanzamiento cuando esté listo? ¡Comenta abajo!

Publicar un comentario

0 Comentarios