Camino hacia una publicación sin estrés

Este vídeo garantiza que te reducirá los niveles de estrés antes de tu próxima publicación popular

Laura Daly Laura Daly
Buscar temas

La mejor forma de medir el éxito de un equipo ágil es cuando el software funcional se publica para los clientes. Sin embargo, incluso los equipos de software experimentados sudan la gota gorda cuando es el momento de validar las incidencias completadas con respecto a artefactos; cuando las revisiones de código no se han realizado; cuando el código no se ha fusionado; cuando fallan las compilaciones del código fusionado… ¿Te resulta familiar?

En esta presentación, aprenderás lo siguiente:

  • Prácticas recomendadas de programación que ayudarán a mejorar tu capacidad de ofrecer productos de calidad. Escucha por qué las revisiones de código son fundamentales para ofrecer calidad y cómo supervisar y solucionar compilaciones con error garantizará un tiempo de publicación más rápido.
  • Cómo configurar y maximizar el centro de publicaciones de Jira Software. Aprende cómo ahorrar horas de trabajo permitiendo que el centro de publicaciones proporcione una imagen clara del progreso y el estado de una publicación.
  • Automatización completa desde la compilación y creación de códigos hasta la publicación. Agiliza tu flujo de trabajo publicando tu versión directamente desde el centro de publicaciones.

Mira y aprende

Preguntas y respuestas

Nuestros organizadores Jason Wong y Megan Cook escogieron sus preguntas y respuestas favoritas de esta presentación. Sigue leyendo para descubrir más sobre cómo disfrutar de una publicación con éxito y sin estrés.

P1: ¿Cuáles son los 3 principales factores no técnicos que hacen que utilizar el centro de publicaciones sea un acierto?

R1: (1) Lanza con confianza. Las partes interesadas de dentro y de fuera del equipo podrán saber qué es exactamente lo que está listo para publicarse en cualquier momento a lo largo del ciclo de publicación.

(2) Ahorra tiempo y toma decisiones más rápido. Puedes saber automática e instantáneamente qué funciones están terminadas y listas para enviarse, y cuáles tienen problemas. El centro de publicaciones comprueba todas las incidencias de tu versión por ti, para que no tengas que conciliar manualmente incidencias y código.

(3) Registro de publicaciones: averigua qué salió (cuándo y en qué publicación) examinando las versiones publicadas y qué se ha planificado en esos momentos para cada una de las publicaciones próximas examinando las versiones no publicadas.

P2: ¿Quién gestiona generalmente las versiones de publicación en Atlassian?

R2: Cada equipo de Atlassian tiene su propio enfoque específico, pero, en general, intentamos automatizar lo máximo posible del proceso, para que cualquier desarrollador del equipo pueda aplicar correcciones de errores de producción o publicar una nueva versión de corrección de errores de un producto con una sobrecarga mínima.

Normalmente, los equipos tienen una lista de cosas que tienen que hacer, pero intentamos minimizarlo lo máximo posible. Herramientas como el centro de publicaciones ayudan en este proceso para garantizar que lo que planificamos publicar tiene la máxima calidad y que no hay discrepancias entre los estados de las incidencias de Jira Software y su desarrollo real.

Algunos de los equipos más grandes (por ejemplo, Jira Software y Confluence) tendrán de hecho una rotación exclusiva de un responsable de errores/gestor de publicaciones que gestiona todas las publicaciones.

Para las publicaciones grandes y pequeñas de mayor volumen, generalmente hay una persona específica que está pendiente de la publicación, asegurándose de que el alcance se está controlando y que todo el trabajo que conduce a la publicación está controlado en cuanto al riesgo y el tiempo. Puede que todo esto lo supervise un líder de equipo o un jefe de desarrollo, pero intentamos asegurarnos de que esta función rote entre los miembros del equipo para que todos conozcan el proceso y entiendan los requisitos de publicar software de calidad.

En cuanto a la planificación del cronograma, los líderes de equipo se coordinarán con los gestores de productos y el equipo de marketing para definir expectativas sobre cuándo estará lista una publicación y si tienen que controlarse el alcance o el tiempo. Estas personas son las que toman las decisiones de qué funciones se publicarán en qué versiones.

P3: ¿Qué hacéis para asociar una rama/confirmación/solicitud de extracción/compilación/implementación a una incidencia?

R3:

1. Rama: incluye la clave de incidencia en el nombre de la rama.
2. Confirmación: incluye la clave de incidencia en el mensaje de confirmación.
3. Solicitud de extracción: incluye la clave de incidencia en el nombre de la rama de origen, el mensaje de confirmación incluido o el título de la solicitud de extracción.
4. Compilación: incluye la clave de incidencia en un mensaje de confirmación incluido.
5. Implementación: incluye la clave de incidencia en un mensaje de confirmación incluido.

P4: ¿Cuál ha sido vuestra experiencia al abordar los conflictos que surgen cuando se trabaja en el mismo código en ramas de incidencias aisladas?

R4: Nuestra experiencia es que esto casi nunca supone un problema. La mayoría de las incidencias tienen poco código que se solapa, pero en ocasiones sí que se producen conflictos.

Normalmente, hay 2 problemas que suceden:

  • Ramas de función de larga ejecución aisladas del otro desarrollo en curso
  • Tareas de refactorización enormes que tienen que separarse hasta que se completen, prueben y estén listas para la publicación

Para el primer caso, una opción seria es hacer el desarrollo e integrar con frecuencia, pero mantener las funciones en sí tras indicadores de funciones, para que solo nuestro propio equipo interno de pruebas o unos pocos clientes seleccionados vean los cambios en curso. Así se garantiza que el código conflictivo esté continuamente integrado y minimiza las probabilidades de conflicto, además de minimizar el riesgo y el impacto cuando una función grande se añade a la rama de desarrollo principal.

Si esto no es posible y, en el caso de refactorizaciones importantes, nos aseguramos que la rama de desarrollo se integre en la rama de función con la mayor frecuencia posible (fusionando los cambios de la rama base/de desarrollo en la rama de función). Así se garantiza que todo el desarrollo en curso se complete y compruebe con respecto a la rama de función de larga ejecución con la mayor frecuencia posible. Si hay algún conflicto de fusión, es mucho más fácil pedir a las personas que hicieron los cambios que te ayuden a resolver los conflictos de fusión o, por lo menos, mantener su alcance al mínimo para que sea más sencilla su resolución.

La mejor solución es desglosar el trabajo en fragmentos que puedan fusionarse en la rama estable o de desarrollo con la mayor frecuencia posible. Esto minimiza la probabilidad de que se realicen cambios en los mismos archivos en las ramas de función al mismo tiempo.

P5: ¿Qué estrategia recomendáis para gestionar ramas paralelas para desarrollo continuo (funciones), correcciones y su implementación en diferentes entornos (control de calidad/entorno de ensayo/producción)?

R5: Tenemos una serie de estrategias de ramas documentadas en nuestro sitio web de git. En particular, consulta la sección Comparación de flujos de trabajo.

Se pueden encontrar detalles más avanzados en algunos seminarios anteriores (disponibles en inglés), como Getting Git Right, y los flujos de trabajo de implementación continua se explican con más detalle en Git workflows for SaaS teams.

En resumen, hay dos flujos de trabajo predominantes: un flujo de trabajo de publicación de productos para los productos descargables y un flujo de trabajo SAAS para los servicios en línea (flujos de trabajo de Git para equipos SaaS).

Para los productos descargables, la mayoría de equipos utilizan una variante del flujo de trabajo de Gitflow donde la rama maestra se utiliza para el desarrollo continuo, y cada publicación pequeña anterior tiene su propia rama, desde las que se crean las ramas de corrección de errores y se vuelven a fusionar y, cuando se requiere, se compila una publicación de corrección de errores. Cada rama de publicación anterior fusiona todos los cambios en el repositorio local con las publicaciones posteriores y la rama maestra para garantizar que todas las correcciones de errores estén incluidas en todas las versiones posteriores.

P6: ¿El centro de publicaciones funciona bien con kanban y las publicaciones frecuentes?

R6: Sí, funciona perfectamente. El botón Publicar del tablero de kanban puede utilizarse para crear una nueva versión que contenga todas las incidencias de esa publicación. Una vez creada esta versión, el centro de publicaciones puede utilizarse para comprobar si hay advertencias u obtener un resumen de la versión.

Incluso sin el tablero de kanban, puedes crear una versión en cualquier momento y añadirle incidencias incluso si estas se han completado. A continuación, el centro de publicaciones puede utilizarse para comprobar si hay advertencias y asegurarse de que la publicación esté lista.

P7: ¿El centro de publicaciones puede mostrar información de las incidencias de múltiples proyectos de Jira Software o es específico de proyectos y versiones de corrección?

R7: El centro de publicaciones es una vista detallada de una versión. Como las versiones son específicas en ese momento de un proyecto, el centro de publicaciones también es específico de un proyecto.

P8: ¿Podéis hacer que las advertencias del centro de publicaciones se rellenen automáticamente en una sala de Hipchat?

R8: En el día de hoy, no hay integraciones entre las advertencias del centro de publicaciones y Hipchat , y no entra entre nuestros planes compilar ninguna. Hemos estado pensando en diferentes formas en las que el centro de publicaciones podría mejorar la colaboración de los equipos con Hipchat y nos encantaría que nuestros clientes nos contaran cómo podrían utilizar esta integración o cualquier otra integración con nuestros otros productos.

P9: ¿A qué está enlazado el botón "Publicar"? ¿Un script para implementar en tu servidor de producción como un trabajo en Bamboo?

R9: El botón "Publicar" tiene unas cuantas funciones asociadas a él:

  • Puede definir la fecha de publicación y cambiar el estado de una versión a "Publicada". Si hay incidencias abiertas en la versión, te dará la opción de moverlas a otra versión. Todo esto está disponible con o sin la integración con Bamboo.
  • Cuando Bamboo está integrado con Jira Software, el botón Publicar puede utilizarse para iniciar una nueva compilación que puede configurarse en Bamboo para que dé los pasos necesarios para publicar tu versión (por ejemplo, un script para implementar a producción, o producir un nuevo artefacto).
  • Asimismo, el botón Publicar puede utilizarse para iniciar una fase manual para una compilación de Bamboo que se ha ejecutado. Esto te permite tener una compilación que se ejecuta automáticamente, pero tener una fase opcional que solo se activa de forma manual y que es la que en realidad realiza la implementación/publicación. (La fase equivaldría a toda la compilación en la segunda opción, pero puede usar los artefactos que produce la compilación en su ejecución).

P10: ¿Hay algún plan para integrar el centro de publicaciones con GitHub/GitHub Enterprise?

R10: El centro de publicaciones ya funciona con GitHub y GitHub Enterprise. Todo lo que tienes que hacer es conectar tu instancia de Jira Software con tu cuenta de GitHub mediante DVCS Accounts, que está en el menú del administrador de complementos de Jira Software. A continuación, puedes empezar a realizar el seguimiento del progreso de cualquiera de tus versiones con cualquier información de desarrollo relacionada incluida en el centro de publicaciones.

A continuación
Qa at speed