tener - Cómo incorporar el control de versiones(Git) en un gran proyecto de Lotus Notes

¿qué herramienta podemos hacer para tener un mayor control de nuestros proyecto en github?

Question

Mantenemos un gran sitio web basado en Lotus Notes, que se ejecuta en Domino Server 8.5.3. Recientemente, hemos estado hartos de la falta de control de fuente en nuestro proyecto, así que pensamos que trataríamos de ponerle un poco de humor. Pero cómo hacer esto, ¿verdad?

Por diversas razones que no entraré aquí, no podemos ejecutar nuestras aplicaciones localmente en las PC de desarrollo. Solo podemos ejecutarlos en los servidores de desarrollo, almacenamiento y producción. (El servidor Domino local que se ejecuta en las PC de desarrollo no es una opción, desafortunadamente).

Esta figura ilustra la situación actual:

En producción (y puesta en escena) hay varios sitios web que tienen todas la misma funcionalidad. Básicamente son el mismo sitio con el mismo diseño, pero con diferente contenido. Cada sitio consta de varias bases de datos de Notes (Noticias, Archivo, Discusión, etc.). El diseño de estas bases de datos es el mismo para todos los sitios, por lo que todos heredan su diseño del mismo conjunto de plantillas maestras (NewsTemplate, ArchiveTemplate, DiscussionTemplate, etc.).

Un conjunto de réplicas de las plantillas maestras reside en el servidor de Desarrollo. Cuando implementamos una nueva funcionalidad, los cambios de código requeridos se agregan a las plantillas en el Dev. servidor (más detalles sobre esto a continuación). A continuación, estas plantillas se replican en el servidor de ensayo para probarlas y finalmente en el servidor de producción. Esta parte funciona bastante bien.

Los problemas se pueden encontrar en la parte inferior de la figura. Actualmente somos dos desarrolladores, y ambos trabajamos en el mismo conjunto de desarrolladores. bases de datos (Noticias, Archivo, Discusión, etc.) en el desarrollador. servidor. Naturalmente, seguimos tropezando con el trabajo de los demás, lo cual es bastante frustrante. Cuando llega el momento de la implementación, el código que se debe implementar se copia / copia selectivamente del conjunto de dev. bases de datos para el desarrollador. plantillas. Esto se hace de forma manual y, por lo tanto, el riesgo de errores es alto. No podemos simplemente reemplazar el diseño de las plantillas con el del desarrollador. bases de datos, porque el dev. las bases de datos en todo momento contienen código que está en desarrollo. Por lo tanto, debemos tener mucho cuidado de implementar solo el código que está "terminado". Además, no tenemos historial de cambios. Esta es una forma horrible, horrible, horrible (agregar tantos horribles como creas conveniente) de desarrollo de software, y lo sabemos.

Ahora, usando Git, réplicas locales, copias de bases de datos o lo que sea, ¿cuál sería la mejor manera de lograr un esquema de desarrollo y despliegue más sencillo?

Answer 1

Esta figura ilustra una posible solución al problema:

Como se explica aquí , cada desarrollador debe tener su propia COPIA (no réplica) de la base de datos / plantilla (o en nuestro caso conjunto de plantillas) para desarrollarla. Entonces, en cada desarrollador. PC hay un conjunto de plantillas, y cada plantilla está sincronizada con un proyecto en disco. El conjunto de proyectos en disco estará bajo control de fuente con Git.

El desarrollador no podrá ejecutar la aplicación localmente, por lo que necesita un conjunto de bases de datos de prueba en el desarrollador. servidor. Habrá uno de estos conjuntos para cada desarrollador. Las bases de datos de prueba heredarán su diseño de las plantillas del desarrollador. ORDENADOR PERSONAL. Por lo tanto, para probar sus cambios de código, el desarrollador debe actualizar el diseño de su conjunto designado de bases de datos de prueba con el de sus plantillas (que residen en su PC).

El flujo de trabajo para cada desarrollador será el siguiente:

1. Haga cambios de código en el conjunto de plantillas en la propia PC del desarrollador. Pruebe continuamente refrescando el diseño de las bases de datos de prueba en el desarrollador. servidor. Sincroniza con proyectos en disco, confirma y ramifica "a voluntad".

2. Cuando el desarrollador está listo para enviar al repositorio remoto de Git:

   a) Extraiga los cambios del repositorio remoto de Git.

   c) Empuje los cambios al repositorio remoto de Git. Sincronizar bases de datos con proyectos en disco.

   d) Si actualmente está en la rama de desarrollo : Reemplace el diseño del conjunto de plantillas en el desarrollo. servidor con el diseño del conjunto de plantillas en el desarrollador. ORDENADOR PERSONAL. Esto asegurará que la rama de desarrollo del repo de Git remoto siempre sea consistente con las plantillas en el desarrollador. servidor, aunque no haya una conexión directa entre ellos.

3. Desde aquí, los cambios se pueden implementar en etapas y producción al replicar las plantillas del desarrollador. servidor. Antes de implementar en producción, la rama de desarrollo debe fusionarse en la rama principal , de modo que el maestro siempre refleje la versión de producción actual.

Si alguien tiene comentarios, adiciones u objeciones, me encantaría escucharlos.

Editar: para acortar el ciclo de retroalimentación en el punto 1 anterior, el desarrollo se puede hacer directamente en las bases de datos de prueba en el desarrollador. servidor. Esto elimina la necesidad de actualizar el diseño de las bases de datos de prueba cada vez que necesita probar los cambios, aunque debe tener cuidado de copiar todos los cambios al desarrollador. plantillas a intervalos regulares para mantener su código seguro y mantener actualizado el repositorio Git. Esto se puede hacer rápidamente haciendo una comparación elemento por elemento de la base de datos y la plantilla . Esto también sirve como una oportunidad para revisar sus cambios antes de realizar una confirmación, lo cual es un muy buen hábito.

Otra opción para copiar los cambios a la plantilla es hacer la base de datos de prueba en el desarrollador. servidor una plantilla maestra y establecer temporalmente la plantilla en el desarrollador. PC para heredar el diseño de esa plantilla maestra. Luego, los cambios se pueden copiar con "Refresh design" en el desarrollador. Plantilla de PC, después de lo cual puede eliminar la herencia nuevamente.