NOTA: Parlerò di questo argomento in modo approfondito nel prossimo webinar mensile di Access e SQL Server il 9 luglio alle 18:30 CDT. Registrati per vedere il processo dal vivo e fare domande!
Poiché lavoriamo con diverse applicazioni e talvolta in un team, il controllo del codice sorgente è piuttosto importante per la gestione delle modifiche. Abbiamo imparato ad amare usare git per i nostri progetti. In origine, utilizzare git con Access sarebbe stata una sfida, ma grazie a un componente aggiuntivo denominato OASIS-SVN, possiamo utilizzare efficacemente git con i progetti di Access per gestire le modifiche.
Perché usare il controllo del codice sorgente? Non puoi semplicemente comprimerlo?
L'obiettivo principale dietro il controllo del codice sorgente è essere in grado di rispondere facilmente a whodunit.
Ciò è particolarmente critico quando hai a che fare con una segnalazione di bug e ti viene ricordato che hai visto qualcosa di simile prima e hai pensato che forse l'hai risolto ma il cliente lo sta ancora segnalando. Tuttavia, quando il bug è stato "risolto" sei mesi fa, potrebbe anche essere un bug nuovo di zecca perché ci siamo già dimenticati della correzione che abbiamo inserito 6 mesi fa. Non so voi, ma la prospettiva di scavare in un mucchio di backup zippati non sembra molto... rilevabile.
L'inserimento delle modifiche in un controllo del codice sorgente richiede disciplina, ma renderà molto più semplice la revisione e la gestione delle modifiche. Puoi facilmente cercare nella cronologia e vedere cosa cambia esattamente.
Un altro scenario è capire cosa è cambiato esattamente. Se hai apportato diverse modifiche e devi esaminarle prima di inviare una nuova versione, è qui che il controllo del codice sorgente ti aiuta. Hai l'opportunità di controllare il tuo lavoro e assicurarti di aver fatto tutto ciò che ti sei prefissato di fare. Non più "Penso di averlo già fatto". solo per essere detto dal cliente che hai dimenticato quel piccolo dettaglio di cui il cliente ti ha chiesto la scorsa settimana. Inoltre, ciò consente al team di eseguire revisioni del codice per altri; possiamo guardare il lavoro degli altri e fornire feedback e aiutarci a vicenda a mantenere uno standard di qualità elevato.
Perché Git? Access funziona con Visual SourceSafe, vero?
Nelle versioni precedenti a Access 2013, Access supportava il controllo del codice sorgente in modo nativo, ma utilizzava una specifica Microsoft proprietaria, MSSCCI. A peggiorare le cose, la specifica presuppone un modello di check-out/check-in che offre agli sviluppatori un blocco esclusivo sugli oggetti su cui stanno lavorando. Inoltre, le tabelle all'interno dell'applicazione Access erano fondamentalmente un grande blob che non poteva essere letto e tanto meno rivisto.
In pratica, tale modello è molto ingombrante da utilizzare anche in un piccolo team di impostazioni. Un problema principale è che una richiesta di modifica raramente viene confermata su un solo oggetto; gli sviluppatori potrebbero trovarsi a dover toccare più di una manciata di oggetti e quindi le collisioni possono essere inevitabili, specialmente per i moduli core/condivisi.
Git evita tutte le brutture che vediamo con il vecchio modello di check-out/check-in, ma ciò richiede una filosofia diversa nella gestione delle modifiche. Invece di controllare qualcosa, lavoriamo semplicemente da un ramo e quando abbiamo finito, lo uniamo di nuovo al ramo principale. Possiamo avere più rami in parallelo volendo però in pratica abbiamo bisogno solo di 2 o 3 rami paralleli; uno per rappresentare la versione di produzione; altro per lo sviluppo e forse un terzo per la correzione di bug critici. Questo può essere fatto con un progetto Access e dovrebbe esserlo. In caso contrario, può essere molto difficile tenere traccia di ciò che sta accadendo nel file di produzione, soprattutto per applicazioni non banali.
Un'eccellente risorsa per l'apprendimento di git può essere trovata qui; ha una sandbox in modo da poter giocare insieme. Se sei come me e ti piace sgranocchiare i pezzi carnosi e sapere come funziona, questa è una buona risorsa.
Infine, smetti di usare già Visual SourceSafe. È pieno di bug, tende a perdere i tuoi dati e non è stato supportato per _anni_, nemmeno da Access dal 2013.
Ma se Access 2013+ non supporta più il controllo del codice sorgente, come potremmo averlo ancora?!?
Perché OASIS-SVN non è un provider MSSCCI ma solo un semplice componente aggiuntivo di Access. Esistono altri componenti aggiuntivi di Access simili (ad esempio Ivercy, ad esempio) che aggirano la limitazione. In tutti i casi, questi componenti aggiuntivi fanno un uso massiccio degli stessi metodi non documentati utilizzati da Access internamente per il controllo del codice sorgente; Applicazione.Salva come testo e Application.LoadFromText . Questi metodi sono ancora presenti nella versione corrente di Access. Da un lato, c'è un elemento UV per documentarlo per garantire la continuità. OASIS-SVN continua a funzionare bene anche con l'attuale versione di Access.
Perché continui a parlare di OASIS-SVN e git? Posso usare solo l'uno o l'altro?
È importante capire che entrambi gli strumenti sono complementari e sono necessari entrambi. Vedi, il motivo per cui hai bisogno di OASIS-SVN è renderti il più semplice possibile portare a termine il tuo duro lavoro e rappresentarli come un mucchio di file di testo, piuttosto che averli all'interno di un grande blob di un file binario che è il file ACCD*. Non ha senso che il file ACCDB sia controllato dal codice sorgente perché non avrebbe una cronologia adeguata delle modifiche e sarebbe in gran parte illeggibile. Pertanto, OASIS-SVN è lo strumento per creare i file di testo che possono essere utilizzati per ricostruire la tua applicazione Access, ed è compito di git codificare effettivamente quei file. Il git non può e non deve funzionare con il file ACCDB.
Se non conosci git, hai un passaggio in più rispetto a ciò che gli altri di solito fanno nei loro progetti di Visual Studio perché stai lavorando con un file binario, non un vero e proprio insieme di cartelle con un mucchio di file di testo con estensioni divertenti. Quindi dovrai prendere l'abitudine di esportare/importare in modo coerente le modifiche tra il file ACCDB e i file di testo che compongono il tuo repository git.
Prerequisiti
Per iniziare, abbiamo bisogno di 3 software:
- Git per Windows
- TortoiseGit
- OASIS-SVN
A rigor di termini non è necessario il 2° e il 3° software. In realtà potresti accontentarti solo del primo, ma il grande svantaggio è che dovresti esportare/importare manualmente scrivendo il tuo modulo VBA per farlo e credimi, è molto lavoro per ragioni che diventeranno più chiare man mano che seguiamo. Pertanto, OASIS-SVN è fortemente raccomandato. Inoltre, non devi avere TortoiseGit, ma mi piace molto avere una GUI per semplificare il lavoro. Ciò potrebbe offendere alcuni puristi della riga di comando che ti diranno che dovresti semplicemente usare git in una riga di comando, non tramite una bella GUI. Tuttavia, mi piace pigro e veloce e la maggior parte delle volte il processo è semplice, per me è più veloce eseguire semplicemente un comando da un menu piuttosto che aprire una shell bash e digitare qualche comando. Detto questo, TortoiseGit è in realtà solo un sottile involucro sui comandi git, quindi dovresti fare bene a prestare molta attenzione a quale comando git esegue e cosa significa.
Installali tutti; Farò riferimento ai rispettivi siti Web per istruzioni dettagliate. Una volta che tutto è impostato, devi avere un progetto che vuoi mettere sotto controllo. Inoltre, hai bisogno di un posto dove fungere da repository a monte. Forse hai un account Azure DevOps? Bitbucket? GitHub? Sono disponibili diverse opzioni per l'hosting del controllo del codice sorgente. Diamine, se sei propenso, potresti persino configurare un server git privato. Ma anche questo esula dallo scopo dell'articolo. Ancora una volta, ti rimando alla documentazione del rispettivo provider per impostare un repository vuoto.
Una volta che hai un repository vuoto, dovresti ricevere un collegamento ad esso. Utilizziamo Auzre DevOps e abbiamo creato un nuovo repository che si trova a questo URL:
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication
Ora che abbiamo un collegamento per un repository vuoto, possiamo eseguire l'installazione.
Creazione di un repository locale
Sebbene OASIS-SVN abbia una procedura guidata, trovo più facile clonare un repository esistente e lavorare da lì. Sei libero di usare la procedura guidata che farà qualcosa di simile, ma penso che seguire il percorso manuale ti aiuterà a capire cosa sta realmente accadendo e semplificherà il lavoro con gli strumenti. Supponiamo di avere un'applicazione in una cartella particolare:
La cartella Source è vuota e sarà la posizione in cui conserveremo i file di testo per il nostro repository locale. Possiamo fare clic con il pulsante destro del mouse sullo spazio bianco nella cartella per aprire TortoiseGit menu contestuale e scegli clone repository.
Nella finestra di dialogo che si apre, inserisci l'URL che hai ricevuto dal tuo provider di hosting:
ATTENZIONE
Si noti che l'impostazione predefinita consiste nell'utilizzare il nome del repository dall'URL come nuova cartella di directory. Quando incolli l'URL nella finestra di dialogo, TortoiseGit compilerà automaticamente la directory. Se non ti piace l'impostazione predefinita, sei libero di regolarla nuovamente su un percorso e nominando come preferisci. Nota nell'immagine che la directory ha \Source , anziché \SampleApplication come sarebbe l'impostazione predefinita.
Dovresti quindi ottenere una finestra di dialogo di successo che il repository è stato clonato:
Come effetto della clonazione, ora avrai una cartella nascosta denominata .git . È così che git tiene traccia dei tuoi commit e delle modifiche nel tuo repository locale.
Ora abbiamo un repository locale funzionante che possiamo quindi utilizzare per conservare i nostri file di testo da Access. Dovremo configurare OASIS-SVN per utilizzarlo.
Configurazione di OASIS-SVN
Come accennato in precedenza, OASIS-SVN ha una procedura guidata che può essere utilizzata per configurarci, ma vogliamo farlo manualmente in modo che tu abbia familiarità con il funzionamento di OASIS-SVN e quindi possa utilizzare la procedura guidata in modo efficace. Inizieremo andando alle Impostazioni menu nella scheda della barra multifunzione OASIS-SVN.
Questo aprirà la finestra di dialogo. Per ora, abbiamo solo bisogno di fare solo una cosa; impostare il percorso di origine. In generale, trovo più conveniente usare il percorso relativo piuttosto che il percorso assoluto, quindi inseriremo \Source come illustrato:
Una volta inserito, dovresti quindi selezionare la casella di controllo usa sempre
Ciò rende la cartella del repository relativa e quindi ti consente di spostare la cartella del progetto ovunque tu voglia. Ma attenzione:se copi o sposti il file di Access al di fuori di quella cartella, non può essere tenuto sotto il controllo del codice sorgente perché OASIS-SVN non avrebbe quindi .oasis file necessario per OASIS-SVN. Fare clic su OK per chiudere la finestra di dialogo per salvare le modifiche alle impostazioni. Se guardi nella cartella, ora vedrai il .oasis per il tuo file ACCDB.
L'.oasi file è solo un file XML che contiene tutte le impostazioni del progetto e deve avere lo stesso nome del file ACCDB in modo che OASIS-SVN sappia che questo file ACCDB dovrebbe essere sotto il controllo del codice sorgente. Pertanto, se hai l'abitudine di rinominare il tuo file ACCDB, dovrai rompere quell'abitudine. Se il flusso di lavoro esistente prevede la ridenominazione del file, un approccio che ritengo utile consiste nell'utilizzare un nome fisso per la copia di sviluppo (ad es. SampleApplication Dev.accdb , forse), quindi quando devo cambiare il nome, faccio una copia di quel file e fornisco il nome corretto. Va sottolineato che con esso nel controllo del codice sorgente, rinominare come mezzo per tenere traccia delle versioni ora ha meno senso poiché dovresti essere in grado di ricrearlo dalla cronologia di git piuttosto che avere un mucchio di copie con nomi diversi.
Configurazione del resto delle impostazioni
Nel passaggio precedente abbiamo impostato solo il file sorgente poiché non avevamo .oasis file; se avessimo apportato altre modifiche, potrebbe non essere stato salvato, ma ora ne abbiamo creato uno come risultato dell'impostazione della cartella del progetto, possiamo rivedere il resto delle impostazioni. Probabilmente è una buona idea prendere in considerazione l'idea di avere un modello .oasis file in modo da poter copiare rapidamente e modificare manualmente per avere un'impostazione del progetto uniforme per i diversi progetti di Access. Torniamo alle Impostazioni pulsante sulla barra multifunzione e inizia con la prima scheda nella finestra di dialogo.
Riquadro Tipi di oggetto
Poiché non lavoriamo più con ADP e non utilizziamo le pagine di accesso ai dati deprecate, di solito deselezionamo quelle per ridurre al minimo il disordine della finestra di dialogo di importazione/esportazione. Potresti anche trovare utile che selezioni automaticamente la modifica automatica, che richiede il tracciamento del timestamp dell'oggetto. Tuttavia, tieni presente che il timestamp dell'oggetto non è completamente affidabile in Access. Ne discuteremo di più nella sezione successiva. Detto questo, è un buon modo per sottolineare se potresti aver dimenticato di commettere qualche oggetto randagio.
Riquadro Opzioni tabella
Questo riquadro richiederà alcune riflessioni attente e dipenderà dal tipo di progetti con cui hai a che fare. La regola numero uno è che _non_ vuoi che il codice sorgente controlli i dati nelle tue tabelle. Ciò non ha senso, dal momento che i dati non sono codice. Tuttavia, questo non è sempre del tutto vero. Ad esempio, abbiamo un numero di tabelle che utilizziamo come dati di configurazione dell'applicazione. Pertanto, in un certo senso, quelle tabelle sono "codice" poiché influenzano il funzionamento dell'applicazione. Poiché la maggior parte dei nostri progetti sono front-end di Access con back-end di SQL Server, le tabelle solitamente presenti sono principalmente solo tabelle di configurazione e quindi appropriate per il controllo del codice sorgente. Ma, se avessimo tabelle di dati, probabilmente non dovrebbero essere incluse. È qui che l'Avanzato il pulsante è utile. Facendo clic su questo si aprirà questa finestra di dialogo:
Deselezionando Esporta i dati per tutte le tabelle casella di controllo in basso, puoi quindi selezionare i dati delle tabelle che desideri mantenere sotto il controllo del codice sorgente, escludendo quelli che sono solo tabelle di dati e non fanno parte del codice sorgente dell'applicazione.
Inoltre, generalmente non includiamo tabelle collegate ODBC perché di solito abbiamo una routine di codice per ricollegare le tabelle, quindi averla nel controllo del codice sorgente non ha senso per noi. Tuttavia, avere la tabella di configurazione dell'applicazione o forse anche solo la definizione per la tabella locale è una buona idea poiché avremmo un'applicazione rotta se avessimo creato un file dal repository git senza la definizione di quelle tabelle.
Riquadro delle impostazioni
L'abbiamo già visto durante la creazione di .oasis file. Ora che abbiamo il file, configureremo il resto delle impostazioni. Ecco la nostra configurazione tipica.
Come ho detto all'inizio, potresti in teoria scrivere la tua routine di importazione/esportazione. Tuttavia, il valore di OASIS-SVN è che possiamo affrontare vari problemi che esistono con il mantenimento dei file di testo di Access sotto il codice sorgente. Ad esempio, un file di testo di Access potrebbe avere i campi tipici nella parte superiore del file:
Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form
Quelli sono dannosi per il controllo del codice sorgente perché possono introdurre modifiche non necessarie e inquinare la cronologia delle modifiche che non sono realmente modifiche. Il checksum può cambiare anche se potresti non aver effettivamente modificato nulla del modulo stesso. Con OASIS-SVN, possiamo eliminare i dati non necessari utilizzando l'opzione Disinfetta i file esportati :
Version =21
VersionRequired =20
Begin Form
...
End Form
Potresti aver notato un'icona di avviso gialla per i rapporti. Il motivo è che OASIS-SVN rimuoverà anche i dati della stampante, il che è notoriamente dannoso per il controllo del codice sorgente. Quando i report utilizzano la stampante predefinita, di solito non è un problema. Tuttavia, non è raro creare report che dipendono da una stampante specifica. Ad esempio, forse abbiamo un rapporto che sta facendo etichette con codici a barre su una stampante specializzata. In quel rapporto, avremo scelto una stampante specifica anziché una stampante predefinita. Selezionando quella casella per i rapporti, i dati della stampante verranno spazzati via. Se il tuo progetto non dipende da alcuna configurazione particolare della stampante, potresti trovare più facile controllare i rapporti. In caso contrario, non ci sono motivi per non spuntarlo per i moduli.
Per ragioni simili, amiamo davvero avere file a modulo diviso e Dividi i file dei rapporti opzione selezionata. Normalmente, Application.SaveAsText esporterà un singolo file di testo per un singolo oggetto di Access. Tuttavia, se hai letto il file di testo, vedrai che il codice di layout può essere... noioso da leggere. Selezionando questa opzione si ottengono 2 file di testo per oggetto Access; uno per contenere tutti i dati di layout e l'altro il codice sorgente VBA effettivo dietro il modulo. Ciò rende la revisione del codice molto più semplice poiché puoi concentrarti sulle modifiche VBA e capire cosa è cambiato, il che rende più facile digerire di cosa tratta la modifica del layout.
Potresti ricordarlo dalla sezione precedente sui Tipi di oggetti riquadro, abbiamo scelto il modificato, che richiede di salvare la data/ora dell'oggetto come data/ora del file. Anche questo è spuntato qui. Vale la pena notare che Access non timbra sempre in modo affidabile il timestamp quando si cambiano gli oggetti. Ne discuteremo di nuovo nella sezione successiva sull'esecuzione di commit.
Riquadro Integrazione
Di solito vogliamo assicurarci che la correzione automatica sia sempre disattivata, ma più importante è l'opzione per usare Ctrl+S come tasto per eseguire un'esportazione. Questo è molto molto utile ed evita il problema con il timestamp dell'oggetto Access. Tuttavia, ciò richiede disciplina per utilizzare in modo coerente la scorciatoia da tastiera per salvare le modifiche. Ogni volta che esegui la tastiera, vedrai questa finestra di dialogo mostrata brevemente:
Ciò garantisce che il tuo albero di lavoro git sia mantenuto il più vicino sincronizzato con il tuo file ACCDB funzionante mentre lavori con le modifiche. È importante sottolineare che non devi essere timido nel salvare frequentemente:non deve significare che devi eseguire il commit di tutti i salvataggi, ma salvando frequentemente, il tuo albero di lavoro rifletterà accuratamente l'entità delle tue modifiche quando sono pronti a impegnarsi. Ne discuteremo in dettaglio nella sezione successiva.
AGGIORNAMENTO automatico prima dell'importazione e COMMIT automatico dopo l'esportazione può sembrare una cosa conveniente ma in pratica abbiamo ritenuto preferibile farlo manualmente, specialmente quando esportiamo con la scorciatoia Ctrl+S poiché non vogliamo necessariamente impegnarci; salva solo il nostro lavoro in corso in modo da sapere cosa è cambiato quando siamo effettivamente pronti per impegnarci. Per questo motivo, li lasciamo fuori.
.oasi File di impostazione
Dopo aver fatto clic su OK nella finestra di dialogo delle impostazioni, le modifiche apportate nei vari riquadri verranno quindi scritte in .oasis file in un formato XML. Come accennato, puoi copiarlo e creare un modello in modo da avere un modo rapido per configurare un'altra applicazione Access. Ora siamo pronti per eseguire un vero e proprio controllo del codice sorgente.
Esportazione e commit
Come già accennato, poiché stiamo lavorando con un file binario, dobbiamo esportare tutto in una rappresentazione testuale in modo che possano essere gestiti correttamente dal controllo del codice sorgente. Per fare ciò, dobbiamo esportare gli oggetti. Puoi utilizzare il pulsante di esportazione OASIS-SVN come indicato.
Verrà visualizzata una finestra di dialogo con tutti i tipi di oggetti elencati per l'esportazione. Poiché questa è la nostra prima esportazione, utilizzeremo Ctrl + A per selezionare tutto per l'esportazione.
Fare clic su OK per terminare l'esportazione. Se tutto va bene, riceverai un messaggio che lo indica.
Se guardi all'interno della cartella di origine, vedrai tutti i file di testo che rappresentano vari oggetti che hai appena esportato. Tieni presente che la convenzione di denominazione potrebbe essere diversa a seconda di ciò che hai selezionato nel riquadro Impostazioni come mostrato nella sezione precedente. Anche perché abbiamo scelto di dividere i file, abbiamo entrambi un .def e un .layout file per un singolo oggetto Access.
Con gli oggetti esportati come file di testo, ora dobbiamo confermare le nostre modifiche. OASIS-SVN fornisce i comandi TortoiseGit direttamente dall'interno di Access come mostrato.
In genere i 4 comandi che vorrai usare sono mostrati qui:gli altri comandi sono utili da usare ma non dobbiamo preoccuparcene fino a quando non arriveremo a scenari git più complessi. A proposito, quei comandi sono in realtà lo stesso comando esposto da TortoiseGit tramite il menu contestuale di Windows Explorer:
Inoltre, è disponibile un sottoinsieme di comandi tramite il menu di scelta rapida nel riquadro di navigazione di Access:
Pertanto, hai diversi modi per eseguire il lavoro con OASIS-SVN o con TortoiseGit direttamente da Access, oppure puoi semplicemente utilizzare TortotiseGit direttamente da Windows Explorer. Tieni presente che hai Commit in tutti gli screenshot; che sarà il nostro prossimo passo. Scegliendolo si aprirà una finestra di dialogo TortoiseGit:
Di solito vorrai selezionare tutto. Nota che tiene traccia solo dei file di testo che inseriamo nella cartella del progetto. Vale la pena sottolineare questo punto; se non hai esportato un oggetto da Access, git non può saperlo. È necessario fornire un messaggio di commit descrittivo; più è dettagliato meglio è. Preferiamo anche fare diversi piccoli commit perché in questo modo la cronologia è più facile da capire. Non vuoi fare un commit una volta alla settimana con 1000 modifiche; sarebbe impossibile da capire. Vuoi un commit dopo aver terminato un'attività (ad es. correzione di un bug specifico o introduzione di una funzionalità), in modo che la tua cronologia sia facile da capire.
Quando prendi l'abitudine di impegnare il tuo lavoro, potresti voler notare che TortoiseGit ti offre 3 opzioni per impegnarti:
Ripeti è utile se devi fare più commit perché hai svolto 2 o più attività e vuoi separare il commit per ogni attività. Probabilmente è meglio non doverlo fare e impegnarsi non appena finisci un'attività, ma se vieni preso dall'eccitazione, devi semplicemente controllare solo un sottoinsieme di file che vuoi impegnare e fare clic su reimpegna. TortoiseGit eseguirà il commit solo di quei file di sottoinsiemi, quindi ripristinerà la finestra di dialogo di commit in modo da poter eseguire il commit degli altri sottoinsiemi di file con un messaggio separato.
Impegnati e spingi è usato spesso per combinare commit e push. È importante ricordare che i commit scrive solo nel tuo repository git locale. Ma abbiamo iniziato con un repository remoto. Non puoi condividere le modifiche al codice con i tuoi colleghi o avere un backup remoto del tuo lavoro finché non hai inviato i tuoi commit locali al server, ed è a questo che serve il push. Ne discuteremo in dettaglio più avanti.
Quando ti impegni, TortoiseGit ti fornirà una finestra di dialogo di avanzamento e ti avviserà se ha avuto successo.
Conclusione
Finora hai imparato come impostare un repository git, configurare OASIS e fare il tuo primo commit. Tuttavia, questo graffia a malapena la superficie. Il pieno potere di git non è ancora evidente fino a quando non si entra nella ramificazione, nella lettura della cronologia e nella risoluzione dei conflitti. Tuttavia, quelle sono cose strettamente git e hanno meno a che fare con Access o OASIS; qualsiasi guida git generale che abbiamo già collegato all'inizio dell'articolo sarà molto utile per capire come gestire un repository git. Vale la pena ricordare che TortoiseGit è solo un sottile wrapper della GUI sui comandi git, quindi anche se il tutorial parla dell'uso di una shell bash, dovresti essere in grado di fare la stessa cosa tramite il menu TortoiseGit con lo stesso nome. Hai domande? Chiedi nei commenti!
