Ingeniería y desarrollo en Pandora FMS

Pandora FMS comenzó como un proyecto Opensource totalmente personal allá por 2004. Yo ni siquiera era programador profesional, me dedicaba a la consultoría de seguridad Unix. De hecho, escogí PHP pero Pandora FMS fue mi primera aplicación con PHP, sabía algo de ASP y mi lenguaje de programación favorito había sido el C.

Un proyecto con un solo programador y que no tiene todavía ningún usuario profesional de su software es algo muy diferente de un proyecto con varias decenas de programadores y cientos de clientes que utilizan el software en entornos críticos. La evolución que ha sufrido Pandora FMS del año 2004 al año 2021 es un caso real de mejora continua en el proceso de ingeniería de software.

Afortunadamente no hice mucho caso a esa asignatura de la carrera, porque la mayoría de las cosas que funcionan y que he aprendido con la práctica no vienen en un libro, ni se explican en la universidad, porque cada proyecto de software y cada equipo de personas es muy diferente. Puede sonar a tópico, pero es la realidad, y más vale aceptarla y huir de fórmulas, porque construir un producto de software sólido y que pueda crecer a lo largo del tiempo no es nada trivial.

En este artículo voy a hablar de nuestra experiencia, nuestra evolución a lo largo del tiempo, pero sobre todo de cómo funcionan a día de hoy, nuestros procesos de ingeniería. Siempre he creído que la parte más importante del OpenSource es la transparencia, y que eso debe aplicarse a todo, no sólo al software si no también a los procesos y el conocimiento en general.

Sistema de control de versiones

Es una parte esencial de cualquier proyecto de software. Hoy el omnipresente GIT está en boca de todos (por cierto, no todo el mundo sabe que Git es obra de Linus Torvalds, autor original del kernel de Linux). Un sistema de control de versiones sirve para, en resumidas cuentas, que un grupo de desarrolladores pueda trabajar sin pisarse el trabajo.

Cuando empezó el proyecto de Pandora FMS, yo trabajaba sin control de versiones, porque no había más personas. Cuando empezaron a colaborar algunas personas en él nos dimos cuenta que un simple directorio compartido no valía, porque nos pisábamos el código y, sí, eso de hacer backups para guardar versiones viejas no era un método muy eficiente.

El primer sistema de control de versiones que usamos fue CVS, que estuvimos usando durante ocho años o más. Alrededor de 2008 empezamos a usar SVN (Subversion) otro sistema un poco más eficiente y no fue hasta 2013 cuando empezamos a usar GIT y abrimos nuestro repo oficial en Github.

Repo público de Pandora FMS en Github

Dado que Pandora FMS tiene una parte opensource y una parte Enterprise -con código cerrado y licencia comercial- tenemos dos proyectos GIT, uno público en GitHub y otro privado, que gestionamos con GitLab. La versión de GitHub está sincronizada con nuestra copia privada en GitLab, en nuestras oficinas. A este repositorio privado tienen acceso algunos partners con los que desarrollamos en conjunto, y a través de una extensión de nuestra aplicación de soporte (Pandora ITSM) compartimos todos los tickets de planificación de desarrollo, por releases con algunos de nuestros partners, para que puedan ver en tiempo real, la planificación del desarrollo en base a “releases” y todos los detalles de cada ticket.

Vista de ticket GitLab en Pandora ITSM

Vista de tickets de una release

Metodología de desarrollo usada en Pandora FMS

En Pandora FMS llevamos usando una metodología propia desde el principio, aunque hemos cogido prestadas muchas ideas de las metodologías ágiles, especialmente de SCRUM. Desde el punto de vista del ciclo de vida, utilizamos una adaptación de la metodología de Liberación Continua (Rolling Release).

Estas son algunas definiciones importantes a la hora de definir cómo trabajamos, algunas de ellas, son propias de Scrum, otras de otras metodologías.

Objetivos de la metodología de trabajo de Pandora FMS

Los objetivos incluyen no solo a los miembros de desarrollo, también a Q/A, el equipo de de documentación y parte del equipo de marketing:

• Máxima visualización: todo el equipo debe de ver la misma información, y esta debe fluir de abajo a arriba y de arriba a abajo. Compartiendo objetivos seremos capaces de hacer un trabajo más eficaz.
• Lo que no se ve no existe, lo que implica que toda la información relevante al proyecto debe quedar reflejada en la gestión, implementada con Gitlab. Lo que no se ve no existe y lo que no existe no se tendrá en cuenta a ningún efecto. Hacer un seguimiento estricto de esta metodología, permitirá que todos sean muy conscientes de la planificación:-Cumplimiento estricto de fechas.-Planificación previa sin modificaciones de última hora.

  -Información más clara y en su debido momento.

  -Eliminación de los picos de trabajo y un largo etcétera.

• Integridad, con un proyecto cada vez más grande y complejo, es imperativo mantener una integridad durante el desarrollo. Todo el código debe seguir unos estándares.

Ticket

El ticket es la unidad mínima de trabajo. El responsable de su finalización es una única persona y está planificado para ser realizado en una milestone (release de versión).

Un ticket es la forma en la que se descompone el trabajo de desarrollo, de manera que una gran funcionalidad estará compuesta de diferentes tickets, que idealmente se pueden realizar entre varias personas.

El ticket debe contener un funcional o descripción de los requisitos, que puede incluir esquemas, especificaciones, esquemas de interfaz (mockup), conjuntos de pruebas, ejemplos, etc. En algunos casos puede incluso contener el análisis y el diseño de la solución al completo.

Un ticket completado debe comportarse como se especifica en el documento funcional (ticket) y los cambios que se hayan realizado a estas especificaciones deben quedar reflejadas en el ticket.

El funcional es clave para que Q/A pueda validar un ticket o no. Q/A tendrá que reabrir un ticket si este no cumple alguno de los aspectos del funcional.

Miembros y grupos de trabajo

Product Owner (PO)

Define hacia dónde tiene que ir Pandora FMS, en contacto con los clientes, el soporte y la situación “real” de mercado, aportando directrices técnicas y funcionales pero sin implicarse en el desarrollo como tal.

Comité de producto

Grupo de personas que se reunirán permanentemente con el PO para consensuar hacia dónde va el producto, intentando que todas las decisiones de PO sean colegiadas. Está formado por el líder de cada equipo Desarrollo, Q/A, Soporte, Proyectos y Documentación.

Development Manager (DM)

Gestionará todo el ciclo completo de desarrollo: definirá hitos, prioridades, gestionará individualmente todos los miembros y tomará las decisiones operativas. Reporta exclusivamente a PO y es el líder del equipo de desarrollo.

Equipo de desarrollo

Se encarga del desarrollo de grandes funcionalidades y mejoras de producto, de refactorizaciones completas de código, del desarrollo de cambios (pequeñas funcionalidades), corrección de fallos y mejoras de mantenimiento de producto.

Equipo de Q/A

Verifican que cada unidad atómica de desarrollo funcione tal como viene definido en las especificaciones. También creará y mantendrá un ecosistema de pruebas automatizadas tanto de backend como de experiencia de usuario.

Equipo de Soporte

Son los que tratan directamente con el cliente en la resolución de incidencias. Su experiencia con el día a día del producto hace que su voz haya que ser tenida muy en cuenta, por ello son parte del comité de producto.

Equipo de proyectos

Implementan en cliente final y son los que más cerca tienen al cliente, ya que a menudo están desde antes que el proyecto exista, y suelen traer de la mano, ideas y funcionalidades de todo tipo, a todos los efectos son el “altavoz” del departamento comercial, por ello son parte de comité de producto.

Equipo de Formación y documentación

Responsables de la formación y documentación del producto. Coordinan con el equipo de marketing y el equipo de traducción.

Teletrabajo

Todos los miembros del equipo (desarrollo, Q/A, documentación) teletrabajan con total libertad. De hecho en Pandora FMS participan desarrolladores de Europa, Asia y América y dentro de España están repartidas por el territorio nacional. Somos una empresa 100% distribuida y descentralizada, aunque con jerarquías tradicionales.

Para poder teletrabajar necesitamos que cada miembro se haga responsable de su trabajo, sea autónomo y se comprometa con la planificación. El teletrabajo conlleva reducir al mínimo la necesidad de la comunicación oral y la reunión personal física, sustituyendolas no por teleconferencias, sino por un uso preciso de las herramientas del proceso de desarrollo.

Guardias de desarrollo

Un desarrollador del equipo está especialmente dedicado a solucionar incidencias que impliquen código, en conexión permanente con el equipo de soporte (con horario de 8 a.m. a 8.p.m., CEST). Esto permite no sólo tener la máxima agilidad a la hora de solucionar un problema en un cliente, sino que los cambios en código se integran en el repositorio de código de manera organizada.

Proceso de creación y clasificación de tickets

Cualquier miembro de la empresa (incluidos los comerciales) pueden crear un ticket en GitLab. Esto incluye a clientes y partners, aunque en su caso existe un filtro previo por el equipo de soporte y el equipo comercial respectivamente.

Cuanto más detallado sea el ticket más inequívoco será el desarrollo. Agregar imágenes, gifs, animaciones y todas las aclaraciones que sean necesarias. Así como la forma de acceder al entorno donde se ha encontrado el problema o las personas de contacto. Un desarrollador no contactará nunca directamente con un cliente. En caso de necesitar interactuar con él, se hará a través del equipo de soporte o de proyectos.

Nadie, excepto DM o PO, puede cambiar de milestone un ticket. En la creación el ticket no tendrá milestone asignado ni usuario asignado. La labor de definir en qué release va un ticket es potestad de PO y DM exclusivamente.

Cuando se termine un ticket y el desarrollador cree que debe revisarlo un compañero, le menciona en la merge request se vía @xxxxx. La revisión debe ser nominal. Esta revisión es independiente de la revisión de código llevada a cabo por el responsable de departamento.

Flujo general de trabajo con los Tickets.

• El ticket se asigna a un programador por parte del DM. Si este no tiene ticket asignados, se auto-asignará un ticket. (Ver más abajo las condiciones que regulan este mecanismo).
• El desarrollador debe entender / resolver cualquier duda que pueda surgir tras leer el documento funcional, si es necesario consultar con el DM o el autor del ticket. Esto ha de hacerse antes de empezar a desarrollar. Una vez leído, deberá, por orden:

1. Evaluar (mediante la asignación de etiquetas) su complejidad y su tamaño, llegando a un consenso previo con el DM.
2. Desarrollar la funcionalidad siguiendo las especificaciones del ticket.
3. Documentar todo lo desarrollado en el mismo ticket o si, se requiere, en un nuevo ticket de documentación. Este ticket debe relacionar el ticket “padre” mediante #ID del ticket.
4. El desarrollador deberá probar su funcionalidad al menos en:
   -entorno de desarrollo docker estándar
   -entorno de desarrollo docker con datos.

• Cuando se considere que está terminado, se pondrá la etiqueta Pendiente de Q/A y se pondrá en manos de Q/A.
• Para cada ticket de tipo FUNCIONALIDAD habrá una persona de referencia, generalmente de proyectos, soporte o incluso el PO mismo. Esta persona será quien definirá parte del funcional (junto con DM y PO), pero sobre todo será la persona de referencia para el desarrollador para preguntar cualquier detalle durante el desarrollo, y lo más importante, será a él a quien le deberá ir mostrando el progreso, paso a paso, del desarrollo, para que lo vaya validando.
• Cualquier cambio sobre el funcional quedará reflejado por la persona de referencia en el ticket como comentarios, sin alterar el funcional original.
• Si existe un ticket de documentación hijo, Q/A validará el ticket utilizando la documentación generada por la persona de referencia, NO por el funcional del ticket, validando a la vez, documentación y funcionalidad.

Planificación de releases

Al crear un ticket el milestone debe ser vacío (no asignado) al igual que el usuario. Los únicos que pueden clasificar un ticket son: DM y PO.

Se han definido una serie de milestones que sirven para apoyar el proceso de clasificación de tickets, algunos, los que tienen fecha (releases) se pueden ver como hitos, mientras que el resto se deberían ver como simples contenedores de tickets.

• (No asignado): Es la ausencia de milestone en un ticket. A todos los efectos, este ticket “aún no existe”. DM y PO validarán todos y cada uno de estos tickets para saber si tienen sentido en el roadmap del producto. Ningún desarrollador debería coger ninguno de estos tickets.
• Backlog de funcionalidades: Tickets que se harán en algún momento indeterminado del futuro que tarde o temprano habrá que abordar. Ningún desarrollador debería coger ninguno de estos tickets.
• Bugs de baja prioridad: Bugs reportados de prioridad aún no asignada por PO/DM. Ningún desarrollador debería coger ninguno de estos tickets.
• STAGE: Tickets propuestos por cada departamento para su planificación en una release de producto. En cada reunión de planificación se discutirán estos tickets, y se moverán a otros milestones. Al finalizar la reunión de arranque de ciclo, ésta milestone debe quedar vacía. DM es quien tiene la última decisión de que tickets de STAGE pasan a una release y cuales no, apoyándose en el comité de producto si es preciso. Ningún desarrollador debería coger ninguno de estos tickets.
• XXX: Release XXX. Milestone que agrupa una serie de tickets que van a salir en una fecha determinada. Una milestone lleva asociada una fecha límite. En el caso de las releases RRR esa fecha es móvil, en el caso de las LTS, no.

1. El desarrollo de los tickets asociados a una release debe finalizar 5 días antes del día previsto para la release. Los tickets no completados antes de esa fecha, se moverán a la release siguiente y habrá que justificar el retraso ante el DM.
2. Existen dos tipos de milestones de release:
3. LTS: en abril y noviembre. Se separan entre sí 6 meses.
   Releases Regulares (RRR): existirán de 2 a 4 releases regulares entre las releases LTS

• Un desarrollador sin tareas asignadas de una release, siempre que no quede ningún ticket pendiente de asignación en las milestones de releases correspondientes a su equipo, puede tomar uno de los tickets no asignados de:
  -Release más cercana en fecha.
  -Segunda release más cercana en fecha.

CICD

Los desarrolladores de Pandora FMS integran el código de sus ramas en un repositorio central varias veces al día, haciendo que se ejecuten una serie de pruebas automáticas cuyo objetivo es detectar fallos lo antes posible y mejorar la calidad del producto.

Estas pruebas corren de forma dinámica en una serie de ejecutores o “runners”, algunos de ellos específicos, para determinadas arquitecturas (e.g., ARM), que ejecutan analizadores de código estático, pruebas unitarias, y levantan contenedores para llevar a cabo pruebas de integración en una instalación real de la aplicación.

La generación de paquetes de Pandora FMS está completamente automatizada. Todas las noches se generan paquetes desde la rama de desarrollo para poder realizar pruebas de forma manual. También los puede generar bajo demanda cualquier desarrollador o miembro de los equipos de Q/A o soporte, desde cualquier rama a través de la interfaz web de GitLab.

Cuando se hace una release desde la rama estable, además de la generación de paquetes, se ejecutan una serie de pasos que los despliegan al servidor de paquetes interno de Ártica, a SourceForge, al entorno de soporte para clientes de Ártica, y que, asimismo, actualizan los repositorios de Debian, SUSE y CentOS junto a las imágenes oficiales de Docker.