OBSERVAÇÃO: Falarei sobre esse tópico em profundidade no próximo webinar mensal do Access e SQL Server em 9 de julho às 18h30 CDT. Cadastre-se para poder visualizar o processo ao vivo e tirar dúvidas!
Como trabalhamos com vários aplicativos e às vezes em equipe, o controle do código-fonte é muito importante para gerenciar as mudanças. Nós adoramos usar o git para nossos projetos. Originalmente, usar git com Access seria um desafio, mas graças a um add-in chamado OASIS-SVN, podemos efetivamente usar git com projetos do Access para gerenciar as alterações.
Por que usar o controle de código-fonte? Você não pode simplesmente fechá-lo?
O principal objetivo por trás do controle de código-fonte é ser capaz de responder facilmente a quem foi o culpado.
Isso é especialmente crítico quando você está lidando com um relatório de bug e é lembrado de que viu algo semelhante antes e pensou que talvez tenha corrigido, mas o cliente ainda está relatando. No entanto, quando o bug foi “consertado” seis meses atrás, pode ser um bug novo porque já esquecemos a correção que colocamos há 6 meses. Eu não sei sobre você, mas a perspectiva de vasculhar um monte de backups compactados não parece muito… detectável.
Colocar suas alterações em um controle de código-fonte requer disciplina, mas tornará muito mais fácil revisar e gerenciar as alterações. Você pode pesquisar facilmente o histórico e ver exatamente o que muda.
Outro cenário é descobrir o que exatamente mudou. Se você fez várias alterações e precisa revisá-las antes de enviar uma nova versão, é aí que o controle de código-fonte o ajuda. Você tem a oportunidade de verificar seu trabalho e certificar-se de que fez tudo o que se propôs a fazer. Chega de “acho que já fiz isso”. apenas para ser informado pelo cliente que você esqueceu aquele pequeno detalhe que o cliente lhe perguntou na semana passada. Além disso, isso permite que a equipe faça revisões de código para outras pessoas; podemos olhar para o trabalho dos outros e fornecer feedback e ajudar uns aos outros a manter um alto padrão de qualidade.
Por que desistir? O Access funciona com o Visual SourceSafe, não é?
Nas versões anteriores ao Access 2013, o Access suportava o controle de código-fonte nativamente, mas o fazia usando uma especificação proprietária da Microsoft, MSSCCI. Para piorar, a especificação assume um modelo de check-out/check-in que dá aos desenvolvedores um bloqueio exclusivo sobre os objetos que estão trabalhando. Além disso, as tabelas dentro do aplicativo Access eram basicamente um grande blob que não podia ser lido e muito menos revisado.
Na prática, esse modelo é muito complicado de usar, mesmo em ambientes de equipe pequena. Um problema principal é que uma solicitação de mudança raramente é confirmada para apenas um objeto; os desenvolvedores podem precisar tocar em mais do que um punhado de objetos e, portanto, as colisões podem ser inevitáveis, especialmente para os módulos principais/compartilhados.
O Git evita toda a feiúra que vemos no modelo antigo de check-out/check-in, mas isso requer uma filosofia diferente no gerenciamento das mudanças. Em vez de fazer o check-out de algo, apenas trabalhamos fora de uma ramificação e, quando terminamos, a mesclamos de volta à ramificação principal. Podemos ter várias ramificações em paralelo se quisermos, mas na prática precisamos apenas de 2 ou 3 ramificações paralelas; um para representar a versão de produção; outro para desenvolvimento e talvez um terceiro para correções críticas de bugs. Isso pode ser feito com um projeto do Access e deve ser. Caso contrário, pode ser muito difícil acompanhar o que está entrando no arquivo de produção, especialmente para aplicativos não triviais.
Um excelente recurso para aprender git pode ser encontrado aqui; tem uma caixa de areia para que você possa jogar junto. Se você é como eu e gosta de mastigar os pedaços de carne e sabe como funciona, este é um bom recurso.
Finalmente, basta parar de usar o Visual SourceSafe já. É bugado, propenso a perder seus dados e não tem suporte há _anos_, nem mesmo pelo Access desde 2013.
Mas se o Access 2013+ não oferece mais suporte ao controle de código-fonte, como poderíamos tê-lo ainda?!?
Porque o OASIS-SVN não é um provedor MSSCCI, mas apenas um suplemento de acesso simples. Existem outros suplementos semelhantes do Access (por exemplo, Ivercy, por exemplo) que contornam a limitação. Em todos os casos, esses suplementos fazem uso intenso dos mesmos métodos não documentados que o Access usou internamente para controle de código-fonte; Application.SaveAsText e Application.LoadFromText . Esses métodos ainda estão presentes na versão atual do Access. Por outro lado, há um item UV para documentá-lo para garantir a continuidade. OASIS-SVN continua a funcionar bem mesmo com a versão atual do Access.
Por que você continua falando sobre OASIS-SVN e git? Posso usar apenas um ou outro?
É importante entender que ambas as ferramentas são complementares e você precisa de ambas. Veja, a razão pela qual você precisa do OASIS-SVN é tornar mais fácil possível para você tirar seu trabalho duro e representá-los como um monte de arquivos de texto, em vez de tê-los dentro de um grande blob de um arquivo binário que é o arquivo ACCD*. Não faz sentido que o arquivo ACCDB seja controlado pelo código-fonte porque ele não teria um histórico adequado de alterações e seria em grande parte ilegível. Assim, o OASIS-SVN é a ferramenta para criar os arquivos de texto que podem ser usados para reconstruir seu aplicativo Access, e é o trabalho do git realmente codificar esses arquivos. O git não pode e não deve funcionar com o arquivo ACCDB.
Se você é novo no git, você tem uma etapa extra em comparação com o que os outros geralmente fazem em seus projetos do Visual Studio porque você está trabalhando com um arquivo binário, não um conjunto real de pastas com vários arquivos de texto com extensões engraçadas. Portanto, você precisará adquirir o hábito de exportar/importar consistentemente suas alterações entre o arquivo ACCDB e os arquivos de texto que compõem seu repositório git.
Pré-requisitos
Para começar, precisamos de 3 softwares:
- Git para Windows
- TortoiseGit
- OASIS-SVN
Estritamente falando, você não precisa do 2º e 3º software. Na verdade, você poderia se contentar apenas com o primeiro, mas a grande desvantagem é que você teria que exportar/importar manualmente escrevendo seu próprio módulo VBA para fazer isso e acredite, isso é muito trabalho por motivos que ficarão mais claros à medida que nós acompanhamos. Assim, o OASIS-SVN é fortemente recomendado. Você também não precisa ter o TortoiseGit, mas eu realmente gosto de ter uma GUI para facilitar o trabalho. Isso pode ofender alguns puristas de linha de comando que lhe dirão que você deve usar o git em uma linha de comando, não por meio de uma GUI bonita. No entanto, eu gosto dele preguiçoso e rápido e na maioria das vezes, o processo é simples que é mais rápido para mim apenas executar o comando de um menu do que abrir um shell bash e digitar algum comando. Dito isto, TortoiseGit é realmente apenas um wrapper fino sobre comandos git, então você deve prestar muita atenção em qual comando git ele executa e o que isso significa.
Instale-os todos; Vou consultar seus respectivos sites para obter instruções detalhadas. Uma vez que tudo esteja configurado, você precisa ter um projeto que deseja colocar no controle. Além disso, você precisa de um local para atuar como seu repositório upstream. Talvez você tenha uma conta do Azure DevOps? Bitbucket? GitHub? Há várias opções disponíveis para você hospedar seu controle de código-fonte. Heck, se você estiver inclinado, você pode até configurar um servidor git privado. Mas isso também está fora do escopo do artigo. Novamente, indico a documentação do respectivo provedor para configurar um repositório em branco.
Depois de ter um repositório em branco, você deve receber um link para ele. Usamos o Auzre DevOps e criamos um novo repositório localizado neste URL:
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication Agora que temos um link para um repositório em branco, podemos configurar.
Criando um repositório local
Embora o OASIS-SVN tenha um assistente, acho mais fácil clonar um repositório existente e trabalhar a partir dele. Você está livre para usar o assistente que fará algo semelhante, mas acho que seguir o caminho manual ajudará você a entender o que realmente está acontecendo e facilitará o trabalho com as ferramentas. Vamos supor que temos um aplicativo em uma pasta específica:
A pasta Source está vazia e será onde iremos abrigar os arquivos de texto para nosso repositório local. Podemos clicar com o botão direito do mouse no espaço em branco da pasta para abrir o TortoiseGit menu de contexto e escolha repositório clone.
Na caixa de diálogo que se abre, coloque a URL que você recebeu do seu provedor de hospedagem:
ATENÇÃO
Observe que o padrão é usar o nome do repositório da URL como a nova pasta do diretório. Quando você cola a URL na caixa de diálogo, o TortoiseGit irá preencher automaticamente o diretório. Se você não gostar do padrão, você pode reajustá-lo para um caminho e nomear como desejar. Observe na imagem que o diretório tem \Source , em vez de \SampleApplication como seria o padrão.Você deve obter uma caixa de diálogo de sucesso informando que o repositório foi clonado:
Como efeito da clonagem, agora você terá uma pasta oculta chamada .git . É assim que o git acompanha seus commits e alterações em seu repositório local.
Agora temos um repositório local de trabalho que podemos usar para armazenar nossos arquivos de texto do Access. Precisaremos configurar o OASIS-SVN para fazer uso disso.
Configurando o OASIS-SVN
Como mencionado anteriormente, o OASIS-SVN tem um assistente que pode ser usado para nos configurar, mas queremos fazer isso manualmente para que você esteja familiarizado com o funcionamento do OASIS-SVN e, assim, possa usar o assistente de forma eficaz. Começaremos acessando as Configurações menu na guia da faixa de opções OASIS-SVN.
Isso abrirá a caixa de diálogo. Por enquanto, só precisamos fazer uma coisa; configurar o caminho de origem. Em geral, acho mais conveniente usar o caminho relativo em vez do caminho absoluto, então colocaremos \Source como ilustrado:
Uma vez inserido, você deve marcar a caixa de seleção sempre usar
Isso torna a pasta do repositório relativa e, assim, permite que você mova a pasta do projeto para qualquer lugar que desejar. Mas cuidado - se você copiar ou mover o arquivo do Access para fora dessa pasta, ele não poderá ser mantido sob controle do código-fonte porque o OASIS-SVN não terá o .oasis arquivo que o OASIS-SVN precisa. Clique em OK para fechar a caixa de diálogo para salvar as alterações nas configurações. Se você olhar na pasta, verá o .oasis arquivo para seu arquivo ACCDB.
O .oasis file é apenas um arquivo XML que contém todas as configurações do projeto e deve ter o mesmo nome do arquivo ACCDB para que o OASIS-SVN saiba que esse arquivo ACCDB deve estar sob controle do código-fonte. Assim, se você tem o hábito de renomear seu arquivo ACCDB, precisará quebrar esse hábito. Se o seu fluxo de trabalho existente envolve renomear o arquivo, uma abordagem que acho útil é usar um nome fixo para a cópia de desenvolvimento (por exemplo, SampleApplication Dev.accdb , talvez), então quando preciso alterar o nome, faço uma cópia desse arquivo e forneço o nome correto. Deve-se enfatizar que com ele no controle do código-fonte, renomear como meio de acompanhar as versões faz menos sentido agora, pois você deve poder recriá-lo a partir do histórico do git em vez de ter várias cópias com nomes diferentes.
Definindo o restante das configurações
Na etapa anterior, apenas configuramos o arquivo de origem, pois não tínhamos .oasis Arquivo; se tivéssemos feito alguma outra alteração, talvez ela não tivesse sido salva, mas agora temos uma criada como resultado da configuração da pasta do projeto, podemos revisar o restante das configurações. Provavelmente é uma boa ideia considerar ter um modelo .oasis para que você possa rapidamente copiar e ajustar manualmente para ter uma configuração de projeto uniforme para seus diferentes projetos do Access. Vamos voltar para Configurações botão na faixa de opções e comece com a primeira guia na caixa de diálogo.
Painel Tipos de objeto
Como não trabalhamos mais com ADPs e não usamos as páginas de acesso a dados obsoletas, geralmente desmarcamos essas para manter a desordem da caixa de diálogo de importação/exportação no mínimo. Você também pode achar útil selecionar automaticamente a alteração automática, que exige o rastreamento do carimbo de data e hora do objeto. No entanto, esteja ciente de que o carimbo de data/hora do objeto não é totalmente confiável no Access. Discutiremos isso mais em seção posterior. Dito isso, é uma boa maneira de ajudar a apontar se você pode ter esquecido de confirmar algum objeto perdido.
Painel de opções de tabela
Este painel exigirá algumas reflexões cuidadosas e dependerá do tipo de projeto com o qual você está lidando. A regra número um é que você _não_ deseja que o código-fonte controle os dados em suas tabelas. Isso não faz sentido, já que dados não são códigos. No entanto, isso nem sempre é estritamente verdade. Por exemplo, temos várias tabelas que usamos como dados de configuração do aplicativo. Assim, de certa forma, essas tabelas são “códigos”, pois influenciam o funcionamento da aplicação. Como a maioria de nossos projetos são front-ends de acesso com back-ends SQL Server, as tabelas que geralmente estão presentes são principalmente apenas tabelas de configuração e, portanto, apropriadas para controle de código-fonte. Mas, se tivéssemos tabelas de dados, elas provavelmente não deveriam ser incluídas. É aí que o Avançado botão vem a calhar. Clicar nele abrirá esta caixa de diálogo:
Ao desmarcar a opção Exportar dados para todas as tabelas caixa de seleção na parte inferior, você pode selecionar os dados das tabelas que deseja manter sob controle do código-fonte, excluindo aqueles que são apenas tabelas de dados e não fazem parte do código-fonte do aplicativo.
Geralmente também não incluímos tabelas vinculadas ODBC porque geralmente temos uma rotina de código para revincular as tabelas, portanto, tê-la no controle do código-fonte não faz sentido para nós. No entanto, ter a tabela de configuração do aplicativo ou talvez apenas a definição para a tabela local é uma boa ideia, pois teríamos um aplicativo quebrado se construíssemos um arquivo do repositório git sem a definição dessas tabelas.
Painel de configurações
Já vimos isso antes quando estávamos criando o .oasis Arquivo. Agora que temos o arquivo, vamos configurar o restante das configurações. Aqui está nossa configuração típica.
Como mencionei no início, você poderia escrever sua própria rotina de importação/exportação. No entanto, o valor do OASIS-SVN é que podemos resolver vários problemas que existem com a manutenção de arquivos de texto do Access no código-fonte. Por exemplo, um arquivo de texto do Access pode ter os campos típicos na parte superior de seu arquivo:
Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form Essas são ruins para o controle do código-fonte porque podem introduzir alterações desnecessárias e poluir o histórico de alterações que não são realmente alterações. A soma de verificação pode ser alterada mesmo que você não tenha realmente alterado nada no formulário em si. Com o OASIS-SVN, podemos remover esses dados desnecessários usando a opção Sanear arquivos exportados :
Version =21
VersionRequired =20
Begin Form
...
End Form Você deve ter notado um ícone de aviso amarelo para relatórios. A razão pela qual existe é porque o OASIS-SVN também removerá os dados da impressora que são notoriamente ruins para o controle do código-fonte. Quando os relatórios usam a impressora padrão, isso geralmente não é um problema. No entanto, não é incomum criar relatórios que dependem de uma impressora específica. Por exemplo, talvez tenhamos um relatório que está fazendo uma etiqueta de código de barras em uma impressora especializada. Nesse relatório, escolheremos uma impressora específica em vez de uma impressora padrão. Marcar essa caixa para relatórios significa que os dados da impressora serão perdidos. Se o seu projeto não depender de nenhuma configuração específica da impressora, talvez seja mais fácil marcar os relatórios. Caso contrário, não há motivos para não marcar para formulários.
Por motivos semelhantes, adoramos ter arquivos de formulário dividido e arquivos de relatórios divididos opção marcada. Normalmente, Application.SaveAsText exportará um único arquivo de texto para um único objeto do Access. No entanto, se você leu o arquivo de texto, verá que o código de layout pode ser… tedioso de ler. Marcar esta opção significa que obtemos 2 arquivos de texto por objeto Access; um para conter todos os dados de layout e outro o código-fonte VBA real por trás do formulário. Isso torna a revisão de código muito mais fácil, pois você pode se concentrar nas alterações do VBA e entender o que mudou, o que facilita a digestão do que é a alteração de layout.
Você deve se lembrar da seção anterior sobre Tipos de objeto painel, escolhemos o alterado, o que exige que salvemos a data/hora do objeto como um arquivo data/hora. Isso está marcado aqui também. Vale a pena notar que o Access nem sempre marca de forma confiável o carimbo de data/hora ao alterar os objetos. Discutiremos isso novamente na seção posterior sobre como fazer commits.
Painel de integração
Normalmente, queremos garantir que a correção automática esteja sempre desligada, mas o mais importante é a opção de usar Ctrl + S como um hokey para fazer uma exportação. Isso é muito útil e evita o problema com o carimbo de data/hora do objeto Access. No entanto, isso requer disciplina para usar consistentemente o atalho de teclado para salvar as alterações. Sempre que você executar o teclado, você verá esta caixa de diálogo mostrada brevemente:
Isso garante que sua árvore de trabalho do git seja mantida em sincronia com o arquivo ACCDB de trabalho enquanto você trabalha nas alterações. É importante enfatizar que você não precisa ter vergonha de salvar com frequência - isso não significa que você precise confirmar todos os salvamentos, mas salvando com frequência, sua árvore de trabalho refletirá com precisão a extensão de suas alterações quando você estão prontos para se comprometer. Discutiremos isso em detalhes na seção posterior.
ATUALIZAÇÃO automática antes da importação e COMMIT automático após exportação pode parecer uma coisa conveniente, mas na prática, achamos muito preferível fazer isso manualmente, especialmente quando estamos exportando com o atalho Ctrl+S, pois não queremos necessariamente fazer o commit; apenas salve nosso trabalho em andamento para que saibamos o que foi alterado quando estivermos realmente prontos para confirmar. Por esse motivo, os deixamos de fora.
.oasis Arquivo de configuração
Depois de clicar em OK na caixa de diálogo de configurações, as alterações feitas em vários painéis serão gravadas no .oasis arquivo em formato XML. Conforme mencionado, você pode copiá-lo e criar um modelo para ter uma maneira rápida de configurar outro aplicativo do Access. Agora estamos prontos para fazer algum controle real do código-fonte.
Exportando e comprometendo
Como já mencionado, por estarmos trabalhando com um arquivo binário, precisamos exportar tudo para uma representação textual para que possam ser gerenciados adequadamente pelo controle do código-fonte. Para fazer isso, precisamos exportar os objetos. Você pode usar o botão de exportação OASIS-SVN conforme indicado.
Você obterá uma caixa de diálogo com todos os tipos de objetos listados para exportação. Como esta é nossa primeira exportação, usaremos Ctrl + A para selecionar todos para exportação.
Clique em OK para finalizar a exportação. Se tudo correr bem, você receberá uma mensagem indicando isso.
Se você olhar dentro da pasta de origem, verá todos os arquivos de texto representando vários objetos que você acabou de exportar. Observe que a convenção de nomenclatura pode ser diferente dependendo do que você selecionou no painel Configurações, conforme mostrado na seção anterior. Também porque optamos por dividir os arquivos, temos um .def e um .layout arquivo para um único objeto do Access.
Com os objetos exportados como arquivos de texto, agora precisamos confirmar nossas alterações. OASIS-SVN fornece os comandos TortoiseGit diretamente de dentro do Access como mostrado.
Normalmente, os 4 comandos que você deseja usar são mostrados aqui – os outros comandos são bons de usar, mas não precisamos nos preocupar com isso até chegarmos a cenários git mais complexos. A propósito, esses comandos são, na verdade, os mesmos comandos expostos pelo TortoiseGit através do menu de contexto do Windows Explorer:
Além disso, um subconjunto de comandos está disponível através do menu do botão direito do mouse no painel de navegação do Access:
Assim, você tem várias maneiras de executar o trabalho com o OASIS-SVN ou com o TortoiseGit diretamente do Access, ou pode simplesmente usar o TortotiseGit diretamente do Windows Explorer. Observe que você tem Commit em todas as capturas de tela; que será nosso próximo passo. Escolher isso abrirá uma caixa de diálogo TortoiseGit:
Você geralmente desejará selecionar todos. Observe que ele rastreia apenas os arquivos de texto que colocamos na pasta do projeto. Esse ponto vale a pena enfatizar; se você não exportou um objeto do Access, o git não pode saber sobre isso. Você precisa fornecer uma mensagem de confirmação descritiva; quanto mais detalhado melhor. Também preferimos fazer vários commits pequenos porque assim o histórico é mais fácil de entender. Você não quer fazer um commit uma vez por semana com 1000 alterações; isso seria impossível de entender. Você deseja um commit depois de concluir uma tarefa (por exemplo, corrigir um bug específico ou introduzir um recurso), para que seu histórico seja fácil de entender.
Conforme você adquire o hábito de submeter seu trabalho, você pode querer notar que o TortoiseGit lhe dá 3 opções de submissão:
Reconfirmar é útil se você precisar fazer vários commits porque você fez 2 ou mais tarefas e deseja separar o commit para cada tarefa. Provavelmente, é melhor não ter que fazer isso e confirmar assim que terminar uma tarefa, mas se você ficar empolgado, basta verificar apenas um subconjunto de arquivos que deseja confirmar e clicar em recommit. O TortoiseGit irá submeter apenas aqueles subconjuntos de arquivos, então redefinirá a caixa de diálogo de submissão para que você possa submeter o(s) outro(s) subconjunto(s) de arquivos com uma mensagem separada.
Confirmar e enviar é usado frequentemente para combinar commit e push. É importante lembrar que commits só gravam em seu repositório git local. Mas começamos com um repositório remoto. Você não pode compartilhar suas alterações de código com seus colegas de trabalho ou ter um backup remoto do seu trabalho até que você tenha enviado seus commits locais para o servidor, e é para isso que serve o push. Discutiremos isso em detalhes mais tarde.
Quando você faz um commit, o TortoiseGit irá lhe fornecer uma caixa de diálogo de progresso e notificá-lo se foi bem sucedido.
Encerrando
Até agora você aprendeu como configurar um repositório git, configurar o OASIS e fazer seu primeiro commit. No entanto, isso é apenas arranhar a superfície. O poder total do git ainda não é aparente até que você comece a ramificar, ler o histórico e resolver os conflitos. No entanto, essas são coisas estritamente git e têm menos a ver com Access ou OASIS; qualquer guia geral do git que já linkamos no início do artigo será muito útil para entender como gerenciar um repositório git. Vale a pena lembrar que o TortoiseGit é apenas um wrapper de GUI fino sobre comandos git, portanto, mesmo que o tutorial fale sobre o uso de um shell bash, você poderá fazer a mesma coisa através do menu TortoiseGit com o mesmo nome. Tem perguntas? Pergunte nos comentários!
