Breaking

Post Top Ad

Your Ad Spot

viernes, 6 de septiembre de 2019

Mejora del entorno de trabajo para desarrolladores: solo en 3 etapas


... e incidentalmente estableciendo DevOps.
Mirando hacia atrás en tres años de mejora y optimización del entorno de trabajo para desarrolladores en nuestra empresa, hemos aprendido mucho. Desde entonces, muchas cosas han cambiado nuestra mentalidad. Lo que pasó hasta ahora.
Etapa 1: Análisis del estado real

🤕 Los dolores

¿Está trabajando en el sector de desarrollo de software como desarrollador de aplicaciones  sin importar qué tecnología o un gerente de proyectos de TI?
Claro que ha escuchado algunas de las siguientes oraciones de su cliente o su gerente.
"Necesitamos la última versión de la aplicación lo antes posible para probarla".
"La versión entregada tiene semanas de antigüedad. ¿Podemos actualizarla lo antes posible?" "
“ El enlace de descarga de la aplicación está muerto. "
“ ¿Qué versión necesita ser construida? ¿Qué versión necesitamos entregar? "
No se puede instalar la aplicación, el certificado no es válido".
“¿ Alguien con tiempo libre para cargar una nueva compilación? "
Tómese un breve descanso y sienta sus emociones personales que provocan esas declaraciones.
¿Es puro dolor? Si no, puedes dejar de leer aquí.

🌁 La visión

¿Qué viene a la mente de un Desarrollador al confrontarse con esas declaraciones regularmente?
El deseo excepcional de simplemente automatizar los dolores. A los entusiastas de la tecnología nos gusta automatizar todo en todas partes porque es parte de nuestra actitud simplificar nuestras tareas diarias, ¿por qué no solucionar esos dolores automatizando los procesos subyacentes?
En un mundo perfecto me despertaba por la mañana. Obtenga mi café, comience a desarrollar la nueva función, corrija algunos errores de la versión probada de ayer, tome otro café ... y termine mi día simplemente viendo cómo la aplicación se construye y entrega automáticamente, lista para probar. Todos reciben notificaciones sobre la nueva versión; no es necesario escribir otro mensaje de holgura.
¿No haría eso que nuestras vidas fueran mucho más cómodas? En un mundo perfecto me despertaba por la mañana. Obtenga mi café, comience a desarrollar la nueva función, corrija algunos errores de la versión probada de ayer, tome otro café ... y termine mi día simplemente viendo cómo la aplicación se construye y entrega automáticamente, lista para probar. Todos reciben notificaciones sobre la nueva versión; no es necesario escribir otro mensaje de holgura.

🔎 El punto de partida

En aquel entonces ya teníamos un Servidor de compilación ( llámelo Jenkins ). Fue usado raramente. En su negocio diario como desarrollador, a veces se vio confrontado e interrumpido por esta Jenkins que se introdujo para que todos puedan crear artefactos de aplicaciones sin la necesidad de hacerlo en su máquina de desarrollo.
Construyendo la aplicación
De vez en cuando, una compilación se activaba manualmente porque era hora de entregar una nueva versión de la aplicación al cliente. Muchos obstáculos yacían de esta manera. A veces ni siquiera te asignaron al proyecto de desarrollo subyacente de esta aplicación, sino al único con un poco de tiempo libre y, afortunadamente, un poco de conocimiento sobre este gran monstruo de Jenkins. Después de encontrar el trabajo de compilación adecuado para el proyecto en el servidor y solucionar muchos problemas de compilación, terminó, generalmente después de muchas horas de adivinanzas, intentos y errores, con un artefacto de compilación.
Descargando el artefacto
Aliviada al ver la luz verde parpadeando después de la compilación exitosa, su tarea consistía en descargar el artefacto correcto en su máquina para la siguiente tarea.
Subirlo a algún lugar para entregarlo
Su siguiente tarea fue encontrar información sobre el proceso de entrega de este proyecto. ¿Dónde subirlo? ¿Cuáles son las credenciales para acceder a la versión cargada?
Después de encontrar a alguien en algún lugar que supiera dónde cargar el artefacto y, afortunadamente, tenía las credenciales correctas, terminó con una aplicación cargada y finalmente envió una notificación al cliente.
¡Me hace feliz! Ahora: Vuelva a trabajar desarrollando su proyecto asignado actual.
Conclusión
La entrega de una versión fue cuestión de suerte encontrar el camino correcto a través de una jungla de obstáculos. Esta no puede ser la etapa final. ¿Tenemos más posibilidades utilizando nuestra infraestructura de construcción?
Etapa 2: Implementación

📦 Integración continua

Comenzamos a sumergirnos en la documentación de nuestro Administrador de repositorios (GitLab) y verificamos si podemos obtener una integración fácil a nuestro servidor Jenkins que desencadene una nueva compilación si el código se actualizó. Descubrimos webhooks y activadores de confirmación e hicimos la configuración en ambos extremos.
Conclusión
¡Lo hicimos! Con algunos pasos simples implementamos la  integración continua sin saberlo y completamos el primer punto de control en nuestra pista. ¡Ahora éramos parte del CI Hype Train!
Las ventajas de tener CI para nuestro proyecto eran obvias. Después de cada inserción de código, teníamos una buena (o mala) sensación de que la aplicación todavía se está construyendo en un entorno de espacio aislado y no solo en nuestros propios entornos locales. Los problemas durante la construcción se anticiparon en una etapa muy temprana que llevó a una vida menos estresante después.

🚀  Entrega continua

Un par de meses más adelante ... establecimos la integración continua en cada nuevo proyecto y para un puñado de proyectos existentes y creamos nuestras primeras mejores prácticas relacionadas con Jenkins. Los días estresantes antes de una fase de entrega de la aplicación se redujeron Ya no es necesario activar manualmente una construcción Jenkins el viernes por la tarde y cruzar los dedos para que aparezca el semáforo verde que indica una construcción exitosa. Ya había un artefacto de construcción en nuestro Jenkins el viernes por la tarde esperando ser cargado en el servidor de archivos desde donde podría compartirse con el cliente.
Nos preguntamos si podemos pasar a la siguiente etapa de automatizar la carga al servidor ftp y agregamos algunas líneas de código a nuestro Jenkins Build Script que hizo el trabajo.
Conclusión
¿Acabamos de llegar a la etapa final de la  entrega continua ? ¡Sí lo hicimos! (al menos pensamos que lo hicimos en ese entonces)
La aplicación ahora se creó después de un impulso a nuestro repositorio y después de una compilación exitosa cargada en el servidor de archivos. ¡Excelente!

♻️ Refactorización

Disfrutamos viendo esta configuración automá g camente subir una acumulación tras otro. Introdujimos una versión adecuada para que los archivos en el servidor no se sobrescribieran e introdujimos un proceso manual de mantenimiento regular en el servidor y eliminación de aplicaciones antiguas.
Jenkins Pipeline Scripts de SCM
Pero tan pronto como se presentó a otros proyectos, vimos que sucedían cosas malas. Los guiones de Jenkins fueron copiados y pegados. Desde el principio, esto nunca fue desafiado y funcionó hasta ahora, pero ahora de repente teníamos una lógica en nuestro script que era lo suficientemente genérica como para ser compartida entre los trabajos ... la lógica simple de cargar un archivo.
Comenzamos a evaluar cuáles son las mejores prácticas para compartir secuencias de comandos entre diferentes trabajos y nos pusimos en contacto con la forma ordenada de extraer secuencias de comandos de un repositorio de código fuente. Jenkins permite esto para cada trabajo Pipeline Script. Continuamos con la creación de un repositorio git para todos nuestros Scripts de Pipeline. En el curso de comenzar a crear todos los nuevos scripts de trabajo en este repositorio, también cambiamos de scripts de bash simples a scripts geniales y extrajimos código reutilizable en un script de utilidades separado que luego importamos en los archivos específicos de la tubería.
Presentamos HockeyApp (ahora AppCenter)
También buscamos una forma más conveniente que nuestro servidor ftp para proporcionar descargas de aplicaciones para plataformas iOS, Android y Windows. HockeyApp (ahora AppCenter) fue la solución para eso. HockeyApp es una plataforma que ofrece una manera fácil de administrar y distribuir binarios de aplicaciones a Beta Testers. El cambio nos permitió gestionar diferentes grupos de probadores (internos y externos) y acelerar los ciclos de prueba que mejoraron notablemente la calidad de cada proyecto.

📬 Notificaciones

Después de la fase de refactorización y una gran cantidad de comentarios de diferentes departamentos, decidimos mejorar el proceso de notificación para nuevas versiones. Afortunadamente, estábamos mejorando nuestros procesos de comunicación interna al mismo tiempo y presentamos la holgura como nuestra principal herramienta de comunicación. La holgura encajaba perfectamente en nuestro escenario. Verificamos las integraciones con Jenkins y rápidamente encontramos una manera de enriquecer nuestros scripts de canalización con notificaciones flojas. En el primer paso, enviamos notificaciones sobre los lanzamientos o fallas de compilación al canal de holgura del proyecto. Lo que condujo a interrupciones de las discusiones en curso allí. Por lo tanto, decidimos tener un canal de notificaciones adicional para cada proyecto que tenga una canalización de CD instalada e invitamos a todos los miembros del proyecto a esos canales.
Conclusión
Con la adición de notificaciones, mejoramos significativamente la transparencia del proyecto. Todos los miembros del proyecto ahora conocían el estado del proyecto en todo momento.
Logramos encontrar una solución adecuada para cada participante del proyecto que resolvió muchos pasos manuales sin disminuir el flujo de información.
Etapa 3: observar y mejorar

🎩 DevOps

Sin saberlo, hicimos mucho trabajo en el área de Operaciones de Desarrollo. En aquel entonces, cuando comenzamos, la expresión DevOps no estaba muy extendida o al menos no nos llegó y nos llevó un tiempo darnos cuenta de lo que DevOps significa para nosotros. Al menos ahora teníamos un término para describir nuestras tareas que era muy útil para la comunicación interna.
Explicar el término  DevOps y el campo de trabajo  correcto es realmente desafiante, al menos para las personas no tecnológicas. Las definiciones van desde "Soy un ingeniero de archivos de texto" hasta "Automatizo las cosas aburridas ... con magia".
Https://www.reddit.com/r/devops/comments/awx6d7/can_anyone_describe_our_profession_to_nontech/ )

📈 Mejoras continuas

Como todos sabemos, quien deja de ser mejor deja de ser bueno. Por lo tanto, nuestro objetivo es mejorar de forma iterativa nuestros procesos en torno a nuestras tuberías de entrega continua.
Grupo de trabajo
Introdujimos un grupo de trabajo de DevOps que incluía expertos de diferentes conjuntos tecnológicos para obtener más comentarios y mejorar el intercambio de conocimientos de la compañía sobre DevOps y las posibilidades y ventajas. Como artefactos, estamos generando las mejores prácticas para diferentes pilas de tecnología. El grupo de trabajo evoluciona lentamente hacia un proveedor de servicios internos para todos los temas relacionados con la mejora de los ciclos de desarrollo y lanzamiento.
Mejores prácticas
Introdujimos scripts de trabajo genéricos y mejores prácticas para diferentes objetivos y plataformas de compilación. Esto permite la creación de una nueva tubería para un nuevo proyecto en poco tiempo al elegir una configuración de trabajo existente y cambiar los parámetros para adaptarse al nuevo proyecto.
Comprobación y prueba de estilo automatizadas
Integramos verificaciones y pruebas de estilo automatizadas para mejorar la calidad de nuestro código y crear un entendimiento común entre los miembros del proyecto sobre la calidad del código en general y que agudizó nuestra definición de hecho. Se iniciaron muchas discusiones sobre este tema.
Generación automatizada de la documentación del código.
Creamos scripts para automatizar la generación de la documentación del código para nuestras bibliotecas internas. Ese sí mismo fue un tema completo en sí mismo con muchas discusiones e iteraciones de prueba y error. Recapitularé este tema en otra publicación.
Construcciones nocturnas
También introdujimos compilaciones nocturnas automáticas para anticipar anticipadamente fallas de infraestructura en nuestra canalización de compilación, problemas de integración de terceros y otros errores que no tuvieron su causa raíz en una confirmación de código de ruptura. Esto era necesario para proyectos que ya se habían implementado y no tenían sprints de desarrollo en curso, y por lo tanto no se construyeron regularmente.
La sensación cada mañana de ver construcciones exitosas para todos sus proyectos en curso es simplemente increíble y comienza su día de trabajo correctamente.

🛤 Currículum (tl; dr)

Etapa 1: Análisis del estado real
Analizamos los principales puntos débiles durante la fase de desarrollo de una aplicación desde la perspectiva de los desarrolladores e intentamos resolver la mayor cantidad posible de ellos gradualmente.
Etapa 2: Implementación
Personalizamos algunas de nuestras herramientas existentes, introdujimos un par de mejores prácticas y procesos y logramos establecer un grupo de trabajo a lo largo de tres años.
Etapa 3: observar y mejorar
Aprendimos que hay un término para lo que estamos haciendo: DevOps. Todavía estamos mejorando lo que hemos implementado en la Etapa 2 para poder adaptarnos a las nuevas tecnologías, plataformas y procesos.
Vemos DevOps como la herramienta principal para mejorar el entorno de trabajo para los desarrolladores. Reducir la perturbación tanto como sea posible al mejorar simultáneamente la transparencia del proyecto y dejar que los desarrolladores se centren en lo esencial. Y, además, obtener mejoras de calidad de la aplicación de forma gratuita.
La implementación de entrega continua se adapta perfectamente a nuestro enfoque de desarrollo ágil con revisiones y sprints de proyectos regulares.

📎 Herramientas y enlaces

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

Post Top Ad

Your Ad Spot

Páginas