Como trabajamos con varias aplicaciones y, en ocasiones, en equipo, el control del código fuente es muy importante para gestionar los cambios. Hemos llegado a amar 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 cerrar la cremallera?
El objetivo principal detrás del control del código fuente es poder responder fácilmente a whodunit.
Eso es especialmente crítico 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 aún lo informa. Sin embargo, cuando el error se "arregló" hace seis meses, bien podría ser un error completamente nuevo porque ya nos olvidamos de la solución que pusimos hace 6 meses. No sé tú, pero la perspectiva de buscar en un montón de copias de seguridad comprimidas no se siente muy... reconocible.
Poner sus cambios en un control de código fuente requiere disciplina, pero hará que sea mucho más fácil revisar y administrar los cambios. Puede buscar fácilmente en el historial y ver qué cambia exactamente.
Otro escenario es averiguar qué cambió exactamente. Si ha realizado varios cambios y necesita revisarlos antes de enviar una nueva versión, ahí es donde el control del código fuente lo ayuda. Tienes la oportunidad de revisar tu trabajo y asegurarte de que hiciste todo lo que te propusiste hacer. No más "Creo que ya hice eso". solo para que el cliente le diga que olvidó ese detalle menor que el cliente le preguntó la semana pasada. Además, esto permite que el equipo haga revisiones de código para otros; podemos ver el trabajo de otros y proporcionar comentarios y ayudarnos mutuamente a mantener un alto nivel de calidad.
¿Por qué git? Access funciona con Visual SourceSafe, ¿no?
En versiones anteriores a Access 2013, Access admitía el control de código fuente de forma nativa, pero lo hacía utilizando una especificación patentada de Microsoft, MSSCCI. Para empeorar las cosas, la especificación asume un modelo de check-out/check-in que brinda a los desarrolladores un bloqueo exclusivo sobre los objetos en los que están trabajando. Además, las tablas dentro de la aplicación de Access eran básicamente una gran mancha que no se podía leer y mucho menos revisar.
En la práctica, dicho modelo es muy engorroso de usar incluso en entornos de equipos pequeños. Un problema principal es que una solicitud de cambio rara vez se confirma en un solo objeto; los desarrolladores pueden necesitar tocar más de un puñado de objetos y, por lo tanto, las colisiones pueden ser inevitables, especialmente para los módulos principales/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 verificar algo, solo trabajamos en una rama y cuando terminamos, la fusionamos nuevamente en la rama principal. Podemos tener varias ramas en paralelo si queremos aunque en la práctica solo necesitamos 2 o 3 ramas en paralelo; uno para representar la versión de producción; otro para desarrollo y tal vez un tercero para corrección de errores críticos. Esto se puede hacer con un proyecto de Access, y debería serlo. 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.
Se puede encontrar un excelente recurso para aprender git aquí; tiene una caja de arena para que puedas seguir el juego. Si eres como yo y te gusta masticar los trozos carnosos y sabes cómo funciona, este es un buen recurso.
Finalmente, simplemente deje de usar Visual SourceSafe. Tiene errores, es propenso a perder sus datos y no ha sido compatible durante _años_, ni siquiera por 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?!
Porque OASIS-SVN no es un proveedor de MSSCCI sino un simple complemento de Access. Hay otros complementos de Access similares (por ejemplo, Ivercy, por ejemplo) que solucionan la limitación. En todos los casos, esos complementos hacen un uso intensivo de exactamente los mismos métodos no documentados que Access usó internamente para el control del código fuente; Aplicación.Guardar como texto y Aplicación.LoadFromText . Esos métodos todavía están presentes en la versión actual de Access. Por un lado, hay un elemento UV para documentarlo para 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 comprender que ambas herramientas son complementarias y que necesita ambas. Mire, la razón por la que necesita OASIS-SVN es para que le sea más fácil sacar su arduo trabajo y representarlo como un montón de archivos de texto, en lugar de tenerlos dentro de una gran mancha de un archivo binario que es el Archivo ACCD*. No tiene sentido que el archivo ACCDB esté controlado por el código fuente porque no tendría un historial de cambios adecuado y sería en gran medida ilegible. Por lo tanto, OASIS-SVN son las herramientas para crear los archivos de texto que se pueden usar para reconstruir su aplicación de Access, y es trabajo de git codificar la fuente de esos archivos. El git no puede y no debe funcionar con el archivo ACCDB.
Si es nuevo en git, tiene un paso adicional en comparación con lo que otros suelen hacer en sus proyectos de Visual Studio porque está 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, deberá adquirir el hábito de exportar/importar constantemente sus cambios entre el archivo ACCDB y los archivos de texto que componen su repositorio git.
Requisitos
Para comenzar, necesitamos 3 piezas de software:
- Git para Windows
- TortugaGit
- OASIS-SVN
Estrictamente hablando, no necesita el segundo y el tercer software. En realidad, podría arreglárselas solo con el primero, pero la gran desventaja 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 se aclararán a medida que seguimos a lo largo Por lo tanto, se recomienda encarecidamente OASIS-SVN. Tampoco es necesario tener TortoiseGit, pero me gusta mucho tener una GUI para facilitar el trabajo. Eso puede ofender a algunos puristas de la línea de comandos que le dirán que solo debe usar git en una línea de comandos, no a través de una GUI bonita. Sin embargo, me gusta lento y rápido, y la mayor parte del tiempo, 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 prestar mucha atención a qué comando de git ejecuta y qué significa.
Instálalos todos; Me referiré a sus respectivos sitios web para obtener instrucciones detalladas. Una vez que todo esté configurado, debe tener un proyecto que desee controlar. Además, necesita un lugar para actuar como su repositorio ascendente. ¿Tal vez tiene una cuenta de Azure DevOps? ¿Bitbucket? ¿GitHub? Hay varias opciones disponibles para hospedar su control de código fuente. Diablos, si está inclinado, incluso podría configurar un servidor privado de git. 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 a él. Usamos Auzre DevOps y creamos un nuevo repositorio ubicado en esta URL:
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication
Ahora que tenemos un enlace para un repositorio en blanco, podemos configurarlo.
Crear un repositorio local
Aunque OASIS-SVN tiene un asistente, me resulta más fácil clonar un repositorio existente y trabajar desde allí. Puede usar el asistente que hará algo similar, pero creo que seguir el método 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 determinada:
La carpeta Fuente está vacía y será donde alojaremos los archivos de texto para nuestro repositorio local. Podemos hacer clic con el botón derecho en el espacio en blanco de la carpeta para abrir TortoiseGit menú contextual y elija clonar repositorio.
En el cuadro de diálogo que se abre, ingrese la URL que obtuvo de su proveedor de alojamiento:
ATENCIÓN
Tenga en cuenta que el valor predeterminado es usar el nombre del repositorio de la URL como la nueva carpeta del directorio. Cuando pegue la URL en el cuadro de diálogo, TortoiseGit completará automáticamente el directorio. Si no le gusta el valor predeterminado, puede volver a ajustarlo a una ruta y nombrarlo como desee. Tenga en cuenta en la imagen que el directorio tiene \Source , en lugar de \SampleApplication como sería el predeterminado.
A continuación, debería obtener un cuadro de diálogo de éxito que indica que el repositorio se ha 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 en funcionamiento que luego podemos usar para almacenar nuestros archivos de texto de Access. Tendremos que configurar OASIS-SVN para hacer uso de esto.
Configuración de OASIS-SVN
Como se mencionó anteriormente, OASIS-SVN tiene un asistente que se puede usar para configurarlo, 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 yendo a la Configuración menú en la pestaña de la cinta OASIS-SVN.
Esto abrirá el cuadro de diálogo. Por ahora, solo necesitamos hacer una sola cosa; configurar la ruta de origen. En general, encuentro más conveniente usar la ruta relativa en lugar de la ruta absoluta, por lo que pondremos \Source como se ilustra:
Una vez instalado, debe marcar la casilla de verificación siempre usar
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ía el .oasis archivo que necesita OASIS-SVN. Haga clic en Aceptar para cerrar el cuadro de diálogo y guardar los cambios en la configuración. Si miras en la carpeta, ahora verás el .oasis archivo para su archivo ACCDB.
El .oasis El archivo 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 tiene la costumbre de cambiar el nombre de su archivo ACCDB, deberá romper ese hábito. Si su flujo de trabajo existente implica cambiar el nombre del archivo, un enfoque que encuentro útil es usar un nombre fijo para la copia de desarrollo (por ejemplo, SampleApplication Dev.accdb , tal vez), luego, cuando necesito cambiar el nombre, hago una copia de ese archivo y proporciono el nombre correcto. Debe enfatizarse que con él en el control del código fuente, el cambio de nombre como medio para realizar un seguimiento de las versiones tiene menos sentido ahora, ya que debería poder recrearlo desde el historial de git en lugar de tener un montón de copias con nombres diferentes.
Configuración del resto de ajustes
En el paso anterior solo configuramos el archivo fuente ya que no teníamos .oasis expediente; si hubiéramos hecho otros cambios, es posible que no se haya guardado, pero ahora que tenemos uno creado como resultado de configurar la carpeta del proyecto, podemos revisar el resto de configuraciones. Probablemente sea una buena idea considerar tener una plantilla .oasis archivo para que pueda copiarlo y modificarlo a mano rápidamente para tener una configuración de proyecto uniforme para sus diferentes proyectos de Access. Volvamos a Configuración en la cinta y comience con la primera pestaña en el cuadro de diálogo.
Panel Tipos de objetos
Debido a que ya no trabajamos con ADP y no usamos las Páginas de acceso a datos en desuso, generalmente las desmarcamos para mantener el desorden del cuadro de diálogo de importación/exportación al mínimo. También puede resultarle útil hacer que seleccione automáticamente el cambio automático, lo 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 en una sección posterior. Dicho esto, es una buena manera de ayudar a señalar si es posible que haya olvidado cometer algún objeto perdido.
Panel de opciones de tabla
Este panel requerirá algunas reflexiones cuidadosas y dependerá del tipo de proyectos con los que esté tratando. La regla número uno es que _no_ desea que el código fuente controle los datos en sus tablas. Eso no tiene sentido, ya que los datos no son código. Sin embargo, eso no siempre es estrictamente cierto. Por ejemplo, tenemos una serie de tablas que usamos 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 front-ends de Access con backends de 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 Avanzado El botón es útil. Al hacer clic aquí, se abrirá este cuadro de diálogo:
Al desmarcar Exportar datos para todas las tablas casilla de verificación en la parte inferior, puede seleccionar los datos de las tablas que desea mantener bajo el control del código fuente, excluyendo aquellas que son solo tablas de datos y no forman parte del código fuente de la aplicación.
Por lo general, tampoco incluimos tablas vinculadas ODBC porque generalmente tenemos una rutina de código para volver a vincular las tablas, por lo que tenerlo en el control del código fuente no tiene sentido para nosotros. Sin embargo, tener la tabla de configuración de la aplicación o tal vez incluso solo la definición de la tabla local es una buena idea, ya que tendríamos una aplicación rota si creamos 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 .oasis expediente. Ahora que tenemos el archivo, configuraremos el resto de configuraciones. Esta es nuestra configuración típica.
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 abordar 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 en realidad no son cambios. La suma de comprobación puede cambiar aunque es posible que no haya cambiado nada en el formulario en sí. Con OASIS-SVN, podemos eliminar esos datos innecesarios usando 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, lo que es notoriamente malo para el control del código fuente. Cuando los informes usan la impresora predeterminada, eso no suele ser un problema. Sin embargo, no es raro crear informes que dependen de una impresora específica. Por ejemplo, tal vez tengamos un informe que esté haciendo 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. Marcar esa casilla para informes significa que los datos de la impresora desaparecerá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 razón para no marcarlo en los formularios.
Por razones similares, nos encanta tener archivos de formulario dividido y archivos de informes divididos opción marcada. Normalmente, Application.SaveAsText exportará un solo archivo de texto para un solo objeto de Access. Sin embargo, si ha leído el archivo de texto, verá que el código de diseño puede ser... tedioso de leer. Marcar esta opción significa que obtenemos 2 archivos de texto por objeto de Access; uno para contener todos los datos de diseño y otro el código fuente real de VBA detrás del formulario. Eso hace que la revisión del código sea mucho más fácil, ya que puede concentrarse en los cambios de VBA y comprender qué cambió, lo que hace que sea más fácil digerir de qué se trata el cambio de diseño.
Puede que lo recuerde de la sección anterior sobre Tipos de objetos panel, elegimos el modificado, que requiere que guardemos 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. Hablaremos de esto nuevamente en una sección posterior sobre cómo hacer confirmaciones.
Panel de integración
Por lo general, queremos asegurarnos de que la autocorrección esté siempre desactivada, pero lo más importante es la opción de usar Ctrl+S como un truco para hacer una exportación. Eso es muy útil y evita el problema con la marca de tiempo del objeto de Access. Sin embargo, esto requiere disciplina para usar constantemente el atajo de teclado para guardar los cambios. Cada vez que ejecute el teclado, verá este cuadro de diálogo que se muestra brevemente:
Eso garantiza que su árbol de trabajo de git se mantenga lo más sincronizado posible con su archivo ACCDB de trabajo mientras trabaja con los cambios. Es importante enfatizar que no debe ser tímido para guardar con frecuencia; no tiene por qué significar que deba confirmar cada guardado, pero al guardar con frecuencia, su árbol de trabajo reflejará con precisión el alcance de sus cambios cuando están listos para comprometerse. Hablaremos de eso en detalle en una sección posterior.
ACTUALIZACIÓN automática antes de la importación y COMMIT automático después de la exportación puede parecer algo conveniente, pero en la práctica, hemos encontrado que es mucho más preferible hacer esto manualmente, especialmente cuando estamos exportando con el atajo Ctrl+S ya que no necesariamente queremos comprometernos; solo guarde nuestro trabajo en progreso para que sepamos qué ha cambiado cuando estemos realmente listos para comprometernos. Por esa razón, los dejamos fuera.
.oasis Archivo de configuración
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 .oasis archivo en formato XML. Como se mencionó, puede copiarlo y crear una plantilla para tener una forma rápida de configurar otra aplicación de Access. Ahora estamos listos para hacer un control real del código fuente.
Exportar y confirmar
Como ya se mencionó, debido a que estamos trabajando con un archivo binario, necesitamos exportar todo a una representación textual para que el control del código fuente pueda administrarlos correctamente. Para hacer esto, necesitamos exportar los objetos. Puede usar el botón de exportación de OASIS-SVN como se indica.
Obtendrá un cuadro de diálogo con todos los tipos de objetos enumerados para exportar. Dado que 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 indicándolo.
Si mira dentro de la carpeta de origen, verá todos los archivos de texto que representan varios objetos que acaba de exportar. Tenga en cuenta que la convención de nomenclatura puede ser diferente según lo que haya seleccionado en el panel Configuración, como se muestra en la sección anterior. Además, debido a que optamos por dividir los archivos, tenemos un .def y un .diseño archivo para un único 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 dentro de Access como se muestra.
Por lo general, los 4 comandos que querrá usar se muestran aquí:los otros comandos son buenos para usar, pero no tenemos que preocuparnos por eso hasta que lleguemos a escenarios de git más complejos. Por cierto, esos comandos son en realidad los mismos comandos expuestos por TortoiseGit a través del menú contextual del explorador de Windows:
Además, un subconjunto de comandos está disponible a través del menú contextual en el panel de navegación Acceder:
Por lo tanto, tiene varias formas de trabajar con OASIS-SVN o con TortoiseGit directamente desde Access, o simplemente puede usar TortotiseGit directamente desde el explorador de Windows. Tenga en cuenta que tiene Compromiso en todas las capturas de pantalla; que va a ser nuestro siguiente paso. Al elegirlo, se abrirá un cuadro de diálogo de TortoiseGit:
Por lo general, 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 exportaste un objeto desde Access, git no puede saberlo. Debe proporcionar un mensaje de confirmación descriptivo; cuanto más detallado mejor. También preferimos hacer varias confirmaciones pequeñas porque de esa manera la historia es más fácil de entender. No quieres hacer una confirmación una vez a la semana con 1000 cambios; eso sería imposible de entender. Desea una confirmación después de terminar una tarea (por ejemplo, corregir un error específico o introducir una característica), para que su historial sea fácil de entender.
A medida que se acostumbre a confirmar su trabajo, es posible que desee tener en cuenta que TortoiseGit le ofrece 3 opciones para confirmar:
Volver a comprometer es útil si necesita realizar varias confirmaciones porque realizó 2 o más tareas y desea separar la confirmación para cada tarea. Probablemente sea mejor no tener que hacer eso y comprometerse tan pronto como termine una tarea, pero si queda atrapado en la emoción, simplemente marque solo un subconjunto de archivos que desea confirmar y haga clic en volver a confirmar. TortoiseGit confirmará solo esos archivos de subconjunto, luego restablecerá el cuadro de diálogo de confirmación para que pueda confirmar los otros subconjuntos de archivos con un mensaje separado.
Comprometer y empujar se usa a menudo para combinar commit y push. Es importante recordar que las confirmaciones solo escriben en su repositorio git local. Pero comenzamos 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 confirmaciones locales al servidor, y para eso está el envío. 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.
Conclusión
Hasta ahora, ha aprendido cómo configurar un repositorio de git, configurar OASIS y realizar su primera confirmación. Sin embargo, eso es apenas rascar la superficie. El poder total de git aún no es evidente hasta que comienzas a ramificar, leer el historial y resolver los conflictos. Sin embargo, esas son estrictamente cosas de git y tienen menos que ver con Access u OASIS; cualquier guía general de git que ya vinculamos 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 contenedor de GUI delgado sobre los comandos de 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 con el mismo nombre. ¿Tiene preguntas? ¡Pregunta en los comentarios!
