NOTA: Hablé sobre este tema en profundidad en el seminario web mensual de Access y SQL Server el 9 de julio a las 6:30 PM CDT. ¡Regístrese para que pueda ver seminarios en vivo y hacer preguntas

Como trabajamos con varias aplicaciones y en algún momento en un equipo, el control del código fuente es bastante importante para gestionar los cambios. Nos ha encantado usar git para nuestros proyectos. Originalmente, usar git con Access sería un desafío, pero gracias a un complemento llamado OASIS-SVN, podemos usar efectivamente git con proyectos de Access para administrar los cambios.

¿Por qué usar el control de código fuente? ¿No puedes simplemente cerrarla?
El objetivo principal detrás del control del código fuente es poder responder fácilmente

Esto es especialmente importante cuando se trata de un informe de error y se le recuerda que vio algo similar antes y pensó que tal vez lo solucionó pero el cliente todavía lo está informando. Sin embargo, cuando se solucionó el error hace seis meses, podría ser también un error nuevo porque ya nos hemos olvidado de la solución que pusimos hace 6 meses. No sé sobre ti, pero la perspectiva de buscar en un montón de copias de seguridad con cremallera no se siente muy … visible.

Otro escenario es averiguar qué cambió exactamente. Si ha realizado varios cambios y necesita revisarlos antes de presentar una nueva versión, ahí es donde el control del código fuente lo ayuda. Tiene la oportunidad de revisar su trabajo y asegurarse de haber hecho todo lo propuesto. No más «Creo que ya lo hice». Solo para que el cliente le diga que olvidó ese detalle menor por el que preguntó la semana pasada. Además, esto permite al equipo hacer revisiones de código para otros; podemos observar el trabajo de otros y proporcionar comentarios, de este modo ayudarnos unos a otros a mantener un alto nivel de calidad.

¿Por qué git? Access funciona con Visual SourceSafe, ¿no es así?

En versiones anteriores a Access 2013, Access admitía el control del código fuente de forma nativa, pero lo hacía usando una especificación de Microsoft patentada, MSSCCI. Para empeorar las cosas, la especificación asume un modelo de check-out / check-in que otorga a los desarrolladores un bloqueo exclusivo sobre los objetos que están trabajando. Además, las tablas dentro de la aplicación de Access eran básicamente un gran blob que no se podía leer y mucho menos revisar.

En la práctica, este modelo es muy engorroso de usar incluso en una configuración de equipo pequeño. El principal problema es que una solicitud de cambio rara vez se confirma a un solo objeto; los desarrolladores pueden tener que tocar más de un puñado de objetos y, por lo tanto, las colisiones pueden ser inevitables, especialmente para los módulos centrales / compartidos.

Git evita toda la fealdad que vemos con el antiguo modelo de check-out / check-in, pero esto requiere una filosofía diferente en la gestión de los cambios. En lugar de revisar algo, simplemente trabajamos en una rama y cuando terminamos con eso, lo fusionamos de nuevo en la rama principal. Podemos tener varias ramas en paralelo si lo queremos, aunque en la práctica solo necesitamos 2 o 3 ramas paralelas; uno para representar la versión de producción; otra para el desarrollo y tal vez una tercera para correcciones de errores críticos. Esto se puede y debría hacerse con un proyecto de Access. De lo contrario, puede ser muy difícil hacer un seguimiento de lo que está pasando en el archivo de producción, especialmente para aplicaciones no triviales.

Un excelente recurso para aprender git se puede encontrar aquí; Tiene una caja de arena para que puedas jugar. Si eres como yo y te gusta picar los trozos de carne y sabes cómo funciona, este es un buen recurso.

Finalmente, simplemente deja de usar Visual SourceSafe ya. Tiene fallas, es propenso a perder sus datos y no ha sido compatible con _años_, ni siquiera con Access desde 2013.

Pero si Access 2013+ ya no es compatible con el control de código fuente, ¿cómo podríamos tenerlo todavía?

Debido a que OASIS-SVN no es un proveedor de MSSCCI, solo es un simple complemento de Access. Hay otros complementos de Access similares (por ejemplo, Ivercy) que funcionan en torno a la limitación. En todos los casos, esos complementos hacen un uso intensivo de los mismos métodos no documentados que Access utiliza internamente para el control del código fuente; Application.SaveAsText y Application.LoadFromText. Esos métodos aún están presentes en la versión actual de Access. En un lado, hay un elemento UV para documentarlo y garantizar la continuidad. OASIS-SVN sigue funcionando bien incluso con la versión actual de Access.

¿Por qué sigues hablando de OASIS-SVN y git? ¿Puedo usar uno u otro?

Es importante entender que ambas herramientas son complementarias y tu necesitas ambas. Vea, la razón por la que necesita OASIS-SVN es para que le sea lo más fácil posible sacar su trabajo duro y representarlo como un montón de archivos de texto, en lugar de tenerlos dentro de un gran blob de un archivo binario que es el Archivo ACCD *. No tiene sentido que el archivo ACCDB tenga un código fuente controlado porque no tendría un historial de cambios adecuado y sería en gran medida ilegible. Por lo tanto, OASIS-SVN es la herramienta para crear los archivos de texto que pueden usarse para reconstruir su aplicación de Access, y es un trabajo de git para realmente codificar esos archivos. El git no puede y no debe funcionar con el archivo ACCDB.

Si eres nuevo en git, tienes un paso adicional en comparación a lo que otros suelen hacer en sus proyectos de Visual Studio, porque estas trabajando con un archivo binario, no con un conjunto real de carpetas con un montón de archivos de texto con extensiones divertidas. Por lo tanto, tendrá que acostumbrarse a exportar / importar constantemente sus cambios entre el archivo ACCDB y los archivos de texto que componen su repositorio git.

Prerrequisitos

Para empezar, necesitamos 3 piezas de software:

Git For Windows
TortoiseGit
OASIS-SVN

Estrictamente hablando, no necesitas el segundo y tercer software. Realmente podría conformarse con el primero, pero el gran inconveniente es que tendría que exportar / importar manualmente escribiendo su propio módulo VBA para hacer esto y créanme, eso es mucho trabajo por razones que serán más claras a medida que seguimos a lo largo Por lo tanto, OASIS-SVN es muy recomendable. Tampoco es necesario tener TortoiseGit, pero me gusta mucho tener una GUI para que sea fácil de trabajar. Eso puede ofender a algunos puristas de la línea de comandos que te dirán que debes usar git en una línea de comandos, no a través de una GUI bonita. Sin embargo, me gusta perezoso y rápido, y la mayoría de las veces, el proceso es simple, es más rápido para mí simplemente ejecutar un comando desde un menú que abrir un shell bash y escribir algún comando. Dicho esto, TortoiseGit es en realidad solo una envoltura delgada sobre los comandos de git, por lo que debería hacer un buen esfuerzo para prestar atención a qué comando de git se ejecuta y qué significa.

Instálalas todas; Me referiré a sus respectivos sitios web para obtener instrucciones detalladas. Una vez que todo esto esté configurado, debe tener un proyecto que desee poner en control. Además, necesita un lugar para actuar como su repositorio ascendente. Tal vez usted tiene una cuenta de DevOps de Azure? Bitbucket? GitHub? Existen varias opciones disponibles para alojar el control de su código fuente. Diablos, si lo desea, incluso podría configurar un servidor git privado. Pero eso también está fuera del alcance del artículo. Nuevamente, lo remito a la documentación del proveedor respectivo para configurar un repositorio en blanco.

Una vez que tenga un repositorio en blanco, se le debe proporcionar un enlace. Usamos Azure DevOps, y hemos creado un nuevo repositorio ubicado en esta URL:

https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication

Creando un repositorio local

Aunque OASIS-SVN tiene un asistente, me resulta más fácil clonar un repositorio existente y trabajar desde allí. Usted es libre de usar el asistente que hará algo similar, pero creo que seguirlo de forma manual lo ayudará a comprender lo que realmente está sucediendo y facilitará el trabajo con las herramientas. Supondremos que tenemos una aplicación en una carpeta en particular:

La carpeta Fuente está vacía y será donde alojaremos los archivos de texto de nuestro repositorio local. Podemos hacer clic derecho en el espacio en blanco en la carpeta para abrir el menú contextual de TortoiseGit y elegir el repositorio de clonación.

En el cuadro de diálogo que se abre, ingrese la URL que recibió de su proveedor de alojamiento:

[note style=»info» show_icon=»true»]zzzzzzzzz[/note]

[note style=»info» show_icon=»true»]ATENCIÓN Tenga en cuenta que el valor predeterminado es usar el nombre del repositorio de la URL como la nueva carpeta de directorio. Cuando pegue la URL en el cuadro de diálogo, TortoiseGit llenará automáticamente el directorio. Si no le gusta el valor predeterminado, puede reajustarlo a una ruta y nombrarlo como desee. Observe en la imagen que el directorio tiene \ Source, en lugar de \ SampleApplication, como sería el predeterminado.[/note]

Luego debería obtener un cuadro de diálogo satisfactorio, que el repositorio ha sido clonado:

Como efecto de la clonación, ahora tendrá una carpeta oculta llamada .git. Así es como git realiza un seguimiento de sus confirmaciones y cambios en su repositorio local.

Ahora tenemos un repositorio local que podemos usar para guardar nuestros archivos de texto desde Access. Necesitaremos configurar OASIS-SVN para hacer uso de esto.

Configurando OASIS-SVN

Como se mencionó anteriormente, OASIS-SVN tiene un asistente que se puede usar para configurar, pero queremos hacerlo manualmente para que esté familiarizado con el funcionamiento de OASIS-SVN y, por lo tanto, pueda usar el asistente de manera efectiva. Comenzaremos por ir al menú, Configuración en la pestaña de cinta OASIS-SVN.

Esto abrirá el diálogo. Por ahora, solo necesitamos hacer una cosa; configurar la ruta de origen. En general, encuentro más conveniente utilizar una ruta relativa en lugar de una ruta absoluta, por lo que pondremos en \Source como se ilustra:

Una vez instalado, debe marcar la casilla de verificación, use siempre <CurrentProject.Path>:

Eso hace que la carpeta del repositorio sea relativa y, por lo tanto, le permite mover la carpeta del proyecto a cualquier lugar que desee. Pero tenga cuidado: si copia o mueve el archivo de Access fuera de esa carpeta, no se puede mantener bajo el control del código fuente porque OASIS-SVN no tendrá el archivo .oasis que necesita OASIS-SVN. Haga clic en Aceptar para cerrar el cuadro de diálogo para guardar los cambios en la configuración. Si busca en la carpeta, ahora verá el archivo .oasis para su archivo ACCDB.

El archivo .oasis es solo un archivo XML que contiene todas las configuraciones del proyecto, y debe tener el mismo nombre que el archivo ACCDB para que OASIS-SVN sepa que este archivo ACCDB debe estar bajo el control del código fuente. Por lo tanto, si está acostumbrado a cambiar el nombre de su archivo ACCDB, tendrá que romper ese hábito. Si su flujo de trabajo existente implica cambiar el nombre del archivo, un enfoque que me parece útil es usar un nombre fijo para la copia de desarrollo (por ejemplo, Dev.accdb, tal vez), luego, cuando necesito cambiar el nombre, haga una copia de ese archivo y proporcione el nombre propio. Debe enfatizarse con esto en el control de código fuente, cambiar de nombre como un medio para realizar un seguimiento de las versiones ahora tiene menos sentido, ya que debería poder recrearlo desde el historial de git en lugar de tener un montón de copias con nombres diferentes.

Otras configuraciones

En el paso anterior, solo configuramos el archivo fuente ya que no teníamos ningún archivo .oasis; si hubiéramos hecho otros cambios, es posible que no se hayan guardado, pero ahora que hemos creado uno como resultado de la configuración de la carpeta del proyecto, podemos revisar el resto de la configuración. Probablemente sea una buena idea considerar tener plantilla de un archivo .oasis que pueda copiar y modificar a mano rápidamente teniendo una configuración de proyecto uniforme para sus diferentes proyectos de Access. Volvamos al botón Configuración en la cinta y comencemos con la primera pestaña en el cuadro de diálogo.

Tipos de objetos

Como ya no trabajamos con los ADP y no usamos las Data Access Page en desuso, usualmente, desmarcamos para mantener el minimo desorden del diálogo de importación / exportación. También puede resultarle útil seleccionar automáticamente el cambio automático, que requiere el seguimiento de la marca de tiempo del objeto. Sin embargo, tenga en cuenta que la marca de tiempo del objeto no es completamente confiable dentro de Access. Discutiremos esto más adelante en la sección. Dicho esto, es una buena manera de ayudar a señalar si es posible que haya olvidado algún objeto perdido.

Opciones de Tablas

Este panel requerirá algunos pensamientos cuidadosos y dependerá del tipo de proyectos con los que esté tratando. La regla número uno es que no quiere que el código fuente controle los datos en sus tablas. Eso no tiene sentido, ya que los datos no son códigos. Sin embargo, eso no siempre es estrictamente cierto. Por ejemplo, tenemos una serie de tablas que utilizamos como datos de configuración de la aplicación. Por lo tanto, en cierto sentido, esas tablas son «código», ya que influyen en cómo funcionará la aplicación. Debido a que la mayoría de nuestros proyectos son Access front-ends con SQL Server, las tablas que suelen estar presentes son principalmente solo tablas de configuración y, por lo tanto, son apropiadas para el control del código fuente. Pero, si tuviéramos tablas de datos, probablemente no deberían incluirse. Ahí es donde el botón Avanzado es útil. Al hacer clic en este se abrirá este cuadro de diálogo:


Al desmarcar en la parte inferior la casilla de verificación Exportar datos para todas las tablas, puede seleccionar qué datos de las tablas desea mantener bajo el control del código fuente, excluyendo aquellos que son solo tabla de datos y no una parte del código fuente de la aplicación.

En general, tampoco incluimos tablas vinculadas a ODBC porque generalmente tenemos una rutina de código para volver a vincular las tablas, por lo que tenerlo en el control de código fuente no tiene sentido para nosotros. Sin embargo, es una buena idea tener la tabla de configuración de la aplicación o tal vez solo la definición de la tabla local, ya que tendríamos una aplicación dañada si compilamos un archivo desde el repositorio de git sin la definición de esas tablas.

Panel de Configuración

Ya vimos esto antes cuando estábamos creando el archivo .oasis. Ahora que tenemos el archivo y haremos el resto de las configuraciones. Aquí está nuestra típica configuración .

Como mencioné al principio, posiblemente podría escribir su propia rutina de importación / exportación. Sin embargo, el valor de OASIS-SVN es que podemos solucionar varios problemas que existen al mantener los archivos de texto de Access bajo el código fuente. Por ejemplo, un archivo de texto de Access puede tener los campos típicos en la parte superior de su archivo:

Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form

Esos son malos para el control del código fuente porque pueden introducir cambios innecesarios y contaminar el historial de cambios que realmente no son cambios. La suma de comprobación puede cambiar aunque es posible que no haya cambiado nada sobre el formulario en sí. Con OASIS-SVN, podemos eliminar los datos innecesarios con la opción Desinfectar archivos exportados:

Version =21
VersionRequired =20
Begin Form
...
End Form

Es posible que haya notado un icono de advertencia amarillo para los informes. La razón por la que está ahí es porque OASIS-SVN también eliminará los datos de la impresora que son notoriamente malos para el control del código fuente. Cuando los informes utilizan la impresora predeterminada, eso no suele ser un problema. Sin embargo, no es infrecuente crear informes que dependen de una impresora específica. Por ejemplo, tal vez tengamos un informe que hace una etiqueta de código de barras en una impresora especializada. En ese informe, habremos elegido una impresora específica en lugar de una impresora predeterminada. Al marcar esa casilla para los informes, los datos de la impresora se perderán. Si su proyecto no depende de ninguna configuración de impresora en particular, puede que le resulte más fácil marcar los informes. De lo contrario, no hay razones para no marcar los formularios.

Por razones similares, nos encanta tener marcados los archivos Dividir formulario y Dividir informes. Normalmente, Application.SaveAsText exportará un archivo de texto único para un solo objeto de Access. Sin embargo, si has leído el archivo de texto, verás que el código de diseño puede ser … tedioso de leer. Al marcar esta opción, obtenemos 2 archivos de texto por objeto de Access; uno para contener todos los datos de diseño, y otro el código fuente de VBA real detrás del formulario. Eso hace que la revisión del código sea mucho más fácil, ya que puede centrarse en los cambios de VBA y comprender qué ha cambiado, lo que facilita la digestión de qué se trata el cambio de diseño.

Puede recordar que de la sección anterior en el panel Tipos de objetos, elegimos el cambio, que nos obliga a guardar la fecha / hora del objeto como una fecha / hora de archivo Eso está marcado aquí también. Vale la pena señalar que Access no siempre marca de manera confiable la marca de tiempo al cambiar los objetos. Discutiremos esto nuevamente en la sección posterior sobre cómo hacer confirmaciones.

Panel de Integración


Por lo general, queremos asegurarnos de que la corrección automática siempre esté desactivada, pero lo más importante es la opción de usar Ctrl + S como un hokey para realizar una exportación. Eso es muy útil y evita el problema con la marca de tiempo del objeto Access. Sin embargo, esto requiere disciplina para usar constantemente el método abreviado de teclado para guardar los cambios. Cuando ejecute el teclado, verá este cuadro de diálogo que se muestra brevemente:


eL UPDATE automático antes de la importación y COMMIT automático después de la exportación pueden parecer convenientes, pero en la práctica, es mucho más conveniente hacerlo manualmente, especialmente cuando estamos exportando con el acceso directo Ctrl + S, ya que no necesariamente queremos cometer; solo guarde nuestro trabajo en curso para que sepamos qué ha cambiado cuando realmente estamos listos para comprometernos. Por eso, los dejamos fuera.

Configuración de Archivo .oasis

Una vez que haga clic en Aceptar en el cuadro de diálogo de configuración, los cambios que haya realizado en varios paneles se escribirán en el archivo .oasis en un formulario XML. Como se mencionó, puede copiarlo y hacer una plantilla para tener una forma rápida de configurar otra aplicación de Access. Ahora estamos listos para hacer un control de código fuente actual.

Exportando y Commit

Como ya se mencionó, debido a que estamos trabajando con un archivo binario, debemos exportar todo a una representación textual para que puedan ser manejados adecuadamente por el control del código fuente. Para hacer esto, necesitamos exportar los objetos. Puede utilizar el botón de exportación OASIS-SVN como se indica.


Obtendrá un cuadro de diálogo con todos los tipos de objetos listados para exportar. Como esta es nuestra primera exportación, usaremos Ctrl + A para seleccionar todo para exportar.


Haga clic en Aceptar para finalizar la exportación. Si todo va bien, recibirá un mensaje que lo indica.


Si mira dentro de la carpeta de origen, verá todos los archivos de texto que representan diversos objetos que acaba de exportar. Tenga en cuenta que la convención de nomenclatura puede ser diferente según lo que seleccionó en el panel de Configuración, como se muestra en la sección anterior. También porque optamos por dividir archivos, tenemos tanto un archivo .def como un archivo .layout para un solo objeto de Access.

Con los objetos exportados como archivos de texto, ahora debemos confirmar nuestros cambios. OASIS-SVN proporciona los comandos de TortoiseGit directamente desde Access como se muestra.


Además, hay un subconjunto de comandos disponibles a través del menú del botón derecho en el panel de navegación de Access:


Por lo tanto, tiene varias formas de realizar el trabajo con OASIS-SVN o con TortoiseGit directamente fuera de Access, o puede usar TortotiseGit directamente desde el explorador de Windows. Tenga en cuenta que tiene Commit en todas las capturas de pantalla; ¿Cuál será nuestro próximo paso? Al elegirlo se abrirá un diálogo de TortoiseGit:


Normalmente querrá seleccionar todo. Tenga en cuenta que solo rastrea los archivos de texto que colocamos en la carpeta del proyecto. Vale la pena enfatizar ese punto; si no exportó un objeto desde Access, es probable que git no lo sepa. Debe proporcionar un mensaje de confirmación descriptivo; cuanto más detallado mejor. También preferimos hacer varios commit pequeños porque de esa manera la historia es más fácil de entender. No quieres hacer un commit una vez a la semana con 1000 cambios; Eso sería imposible de entender. Desea un commit después de finalizar una tarea (por ejemplo, corregir un error específico o introducir una función), para que su historial sea fácil de entender.

A medida que adquieres el hábito de trabajar commit, es posible que desee tener en cuenta que TortoiseGit le ofrece 3 opciones para hacer:


Recommit: es útil si necesita realizar múltiples commits, porque hiciste 2 o más tareas y desea separar el commit para cada tarea. Probablemente sea mejor no tener que hacer eso y confirmar tan pronto como termine una tarea, pero si se siente atrapado por la emoción, simplemente marque solo un subconjunto de archivos que desee confirmar y haga clic en volver a enviar. TortoiseGit solo confirmará esos archivos de subconjuntos, luego restablecerá el cuadro de diálogo de confirmación para que pueda enviar los otros subconjuntos de archivos con un mensaje separado.

Commit & Push: se utiliza a menudo para combinar commit y push. Es importante recordar que los commits solo se escriben en el repositorio de git local. Pero empezamos con tener un repositorio remoto. No puede compartir sus cambios de código con sus compañeros de trabajo o tener una copia de seguridad remota de su trabajo hasta que haya enviado sus commits locales al servidor, y para eso es para eso. Discutiremos esto en detalle más adelante.

Cuando se comprometa, TortoiseGit le proporcionará un cuadro de diálogo de progreso y le notificará si tuvo éxito.

Terminando

Hasta ahora, ha aprendido cómo configurar un repositorio de git, configurar OASIS y realizar su primer commit. Sin embargo, eso es apenas arañar la superficie. El poder completo de git aún no está claro hasta que te metes en la bifurcación, lees el historial y resuelves los conflictos. Sin embargo, esas son estrictamente cosas gif y tienen menos que ver con Access o con OASIS; Cualquier guía general de git que ya hayamos enlazado al comienzo del artículo será muy útil para comprender cómo administrar un repositorio de git. Vale la pena recordar que TortoiseGit es solo un delgado envoltorio GUI sobre los comandos git, por lo que incluso si el tutorial habla sobre el uso de un shell bash, debería poder hacer lo mismo a través del menú TortoiseGit que tiene el mismo nombre. ¿Tener preguntas? ¡Pregunte en los comentarios!