El problema de la concurrencia

Los desarrolladores de software llevan editando los mismos archivos al mismo tiempo desde la década de 1970. Si dos personas modifican la misma función, una las publica primero y la otra se encuentra con un conflicto de fusión. El control de versiones ha resuelto este problema de forma tan eficaz que todos los desarrolladores lo utilizan sin pensarlo dos veces: preparan los cambios, los publican cuando están listos y resuelven cualquier solapamiento antes de que nada se publique.

Los datos de campo presentan la misma estructura. Dos equipos editan elementos en la misma zona. Uno se encuentra bajo tierra, sin conexión, y el otro al otro lado de la ciudad, con una señal intermitente. Ambos se vuelven a conectar y envían sus cambios. El sistema debe conservar el trabajo de ambos equipos y mostrar dónde se solapan.

Qué se necesita para la edición de campo

La edición sobre el terreno requiere tres elementos a la vez.

Trabajar sin señal. Un equipo realiza ediciones bajo tierra o fuera de cobertura, y las ediciones quedan en espera en el dispositivo hasta que se restablezca la conexión.

Se conservan todas las modificaciones. Si dos equipos editan la misma zona, ambos conservan su trabajo, y la superposición se muestra antes de que se guarde nada.

El espacio compartido sigue siendo compartido. Los equipos trabajan allí donde hay trabajo, y las intersecciones, los corredores y las infraestructuras compartidas siguen siendo modificables por todas las personas que las necesiten.

El modelo de control de versiones

Aptli se inspira en la forma de trabajar de los equipos de desarrollo de software, y los conceptos se corresponden uno a uno.

El guardado es local. Las modificaciones que realiza un trabajador de campo (mover un punto, modificar el trazado de una línea, actualizar propiedades) se guardan en una versión de trabajo en el dispositivo, como si se tratara de editar en una rama local. Las funciones de deshacer y rehacer se aplican a toda la sesión, y un contador indica cuántos cambios están pendientes.

La carga consiste en enviar datos. Cuando el trabajador está listo, la función «Upload» envía la versión en curso al servidor como un único conjunto de cambios, con una marca de tiempo y el nombre del trabajador.

La aprobación consiste en una revisión del código. Al hacer clic en «Enviar», se envía la versión y se solicita la aprobación. La persona encargada de la aprobación comprueba qué se ha modificado y dónde, y a continuación lo confirma o lo devuelve con una nota. El mapa compartido se actualiza cuando la persona encargada de la aprobación lo confirma.

Las comprobaciones de conflictos son comprobaciones de fusión. Antes de que se incorpore una versión, Aptli comprueba si alguien más ha modificado las mismas funcionalidades. Si se detecta un solapamiento, se señala, se muestran ambos conjuntos de cambios y el equipo lo resuelve de forma explícita.

El historial de versiones es el registro de confirmaciones. Cada versión confirmada recoge quién la envió, cuándo, qué cambios se realizaron y quién la aprobó. Una versión confirmada puede restaurarse, y dicha restauración debe pasar por el proceso de aprobación como cualquier otro cambio.

Cómo se aplica esto en la práctica

Hay dos equipos trabajando en la misma red de fibra óptica. El equipo A se encuentra sobre el terreno modificando el trazado de los cables en la sección norte. El equipo B está trabajando bajo tierra modificando los puntos de empalme en la sección central. Ambos equipos están desconectados.

El equipo A finaliza su trabajo, vuelve a conectarse y envía su versión. Nadie más ha modificado esas características. La persona encargada de la aprobación revisa los cambios en el trazado del cableado y los valida.

El equipo B vuelve a conectarse una hora más tarde y envía los cambios. Dos de sus modificaciones en los puntos de empalme se solapan con elementos que el equipo A ya había modificado, por lo que Aptli señala el conflicto. El equipo B comprueba ambos conjuntos de cambios, ajusta sus puntos de empalme a las rutas de cableado del equipo A y vuelve a enviar los cambios. La persona encargada de la aprobación confirma la versión resuelta.

Ambas tripulaciones continúan con su trabajo. La sincronización solo lleva unos minutos, y todas las coincidencias se detectaron antes de que se produjeran.

Diseñado para trabajar sin conexión

La conectividad en el trabajo de campo es intermitente: sótanos, túneles, carreteras rurales, obras de construcción. Un sistema de campo pasa gran parte del día sin conexión.

Las versiones hacen que ese sea el estado normal. Cada modificación permanece en el dispositivo hasta que el trabajador la suba. Se necesita conexión a la red en dos ocasiones: para enviar los cambios y para descargar las últimas actualizaciones de los demás. Entre esos momentos, el trabajador dispone de plena capacidad de edición, y cuando se restablece la conexión, se ejecuta la sincronización.

El modelo parte de cómo se desarrolla el trabajo de campo: principalmente sin conexión, con conexión de vez en cuando.

Resumen

Los datos de campo presentan el problema de concurrencia que el desarrollo de software resolvió hace décadas: varias personas editan lo mismo, a menudo sin conexión.
La edición sobre el terreno debe funcionar sin señal; cada modificación se guarda y se comparte, y dicha información permanece compartida.
El modelo de versiones (guardado local, subidas, aprobación, comprobación de conflictos, historial permanente) se traslada directamente del desarrollo de software a las operaciones sobre el terreno.
Las modificaciones se guardan en el dispositivo hasta que el trabajador las sube. Al enviarlas, se solicita aprobación, y la persona encargada de aprobarlas las confirma o las devuelve con una nota. Los conflictos se ponen de manifiesto para su resolución explícita.
Cada versión confirmada registra quién la ha enviado, la hora y quién la ha aprobado, y una versión confirmada puede restaurarse mediante aprobación.
El modelo parte de cómo se desarrolla el trabajo de campo: principalmente sin conexión, con conexión de vez en cuando.