Brug af OASIS-SVN og git til adgang til kildekodekontrol

BEMÆRK: Jeg vil tale om dette emne i dybden i det kommende månedlige Access og SQL Server webinar den 9. juli kl. 18:30 CDT. Tilmeld dig, så du kan se processen live og stille spørgsmål!

Da vi arbejder med flere applikationer og engang i et team, er kildekodekontrol ret vigtig for styring af ændringer. Vi er begyndt at elske at bruge git til vores projekter. Oprindeligt ville det være en udfordring at bruge git med Access, men takket være et tilføjelsesprogram ved navn OASIS-SVN kan vi effektivt bruge git med Access-projekter til at administrere ændringerne.

Hvorfor bruge kildekodekontrol? Kan du ikke bare lyne den op?

Hovedmålet bag kildekodekontrol er let at kunne svare på whodunit.

Det er især kritisk, når du har at gøre med en fejlrapport, og du bliver mindet om, at du har set noget lignende før, og du troede, at du måske har rettet det, men kunden rapporterer det stadig. Men da fejlen blev "rettet" for seks måneder siden, kunne det lige så godt være en helt ny fejl, fordi vi allerede har glemt den rettelse, vi lagde ind for 6 måneder siden. Jeg ved ikke med dig, men udsigten til at grave gennem en masse lynlåste sikkerhedskopier føles ikke særlig … opdagelig.

At sætte dine ændringer i en kildekodekontrol kræver disciplin, men vil gøre det meget nemmere at gennemgå og administrere ændringer. Du kan nemt søge i historikken og se, hvad der præcist ændrer sig.

Et andet scenarie er at finde ud af, hvad der præcist ændrede sig. Hvis du har foretaget flere ændringer, og du skal gennemgå dem, før du skubber en ny version, er det her, kildekodekontrol hjælper dig. Du har mulighed for at tjekke dit arbejde og sikre dig, at du gjorde alt, hvad du satte dig for. Ikke mere "Jeg tror, ​​jeg gjorde det allerede." kun for at få at vide af klienten, at du glemte den lille detalje, som klienten spurgte dig om i sidste uge. Desuden gør dette teamet i stand til at lave kodegennemgange for andre; vi kan se på andres arbejde og give feedback og hjælpe hinanden med at opretholde en høj kvalitetsstandard.

Hvorfor git? Access virker med Visual SourceSafe ikke?

I versioner før Access 2013 understøttede Access indbygget kildekodekontrol, men det gjorde den ved hjælp af en proprietær Microsoft-specifikation, MSSCCI. For at gøre det værre, forudsætter specifikationen en check-out/check-in model, som giver udviklere en eksklusiv lås over de objekter, de arbejder med. Desuden var tabellerne i Access-applikationen dybest set én stor klat, som ikke kunne læses endsige gennemgås.

I praksis er en sådan model meget besværlig at bruge selv i et lille team. Et hovedproblem er, at en ændringsanmodning sjældent bekræftes til kun ét objekt; udviklerne kan finde på at skulle røre ved mere end en håndfuld objekter, og derfor kan kollisioner være uundgåelige, især for de centrale/delte moduler.

Git undgår al den grimhed, som vi ser med gammel check-out/check-in model, men dette kræver en anden filosofi i håndteringen af ​​ændringerne. I stedet for at tjekke noget ud, arbejder vi bare fra en gren, og når vi er færdige med den, flettes den tilbage til hovedgrenen. Vi kan have flere forgreninger parallelt, hvis vi ville, men i praksis behøver vi kun 2 eller 3 parallelle grene; en til at repræsentere produktionsversionen; andet til udvikling og måske en tredje til kritiske fejlrettelser. Dette kan gøres med et Access-projekt, og bør være det. Ellers kan det være meget svært at holde styr på, hvad der går ind i produktionsfilen, især for ikke-trivielle applikationer.

En fremragende ressource til at lære git kan findes her; den har en sandkasse, så du kan lege med. Hvis du er ligesom mig og kan lide at hugge ned på de kødfulde stykker og ved, hvordan det virker, er dette en god ressource.

Stop endelig med at bruge Visual SourceSafe allerede. Den er buggy, tilbøjelig til at miste dine data og er ikke blevet understøttet i _år_, ikke engang af Access siden 2013.

Men hvis Access 2013+ ikke længere understøtter kildekodekontrol, hvordan kunne vi så have det stadig?!?

Fordi OASIS-SVN ikke er en MSSCCI-udbyder, men blot et almindeligt Access-tilføjelsesprogram. Der er andre lignende Access-tilføjelser (f.eks. Ivercy), der fungerer uden om begrænsningen. I alle tilfælde gør disse tilføjelser stor brug af nøjagtig de samme udokumenterede metoder, som Access brugte internt til kildekodekontrol; Application.SaveAsText og Application.LoadFromText . Disse metoder er stadig til stede i den nuværende version af Access. Til gengæld er der et UV-element til at dokumentere det for at sikre kontinuiteten. OASIS-SVN fortsætter med at fungere godt selv med den nuværende Access-version.

Hvorfor bliver du ved med at tale om OASIS-SVN og git? Kan jeg bare bruge det ene eller det andet?

Det er vigtigt at forstå, at begge værktøjer er komplementære, og du har brug for begge. Se, grunden til, at du har brug for OASIS-SVN, er at gøre det nemt som muligt for dig at tage dit hårde arbejde ud og repræsentere dem som en masse tekstfiler, i stedet for at have dem inde i en stor klat af en binær fil, der er ACCD* fil. Det giver ikke mening at få ACCDB-filen til at være kildekodestyret, fordi den ikke ville have en ordentlig ændringshistorik og stort set ville være ulæselig. Således er OASIS-SVN værktøjerne til at skabe de tekstfiler, der kan bruges til at genopbygge din Access-applikation, og det er git's opgave faktisk at kildekode disse filer. Git kan og bør ikke fungere med ACCDB-filen.

Hvis du er ny til git, har du et ekstra trin i forhold til, hvad andre normalt gør på deres Visual Studio-projekter, fordi du arbejder med en binær fil, ikke et egentligt sæt mapper med en masse tekstfiler med sjove udvidelser. Så du bliver nødt til at vænne dig til konsekvent at eksportere/importere dine ændringer mellem ACCDB-filen og tekstfilerne, der udgør dit git-lager.

Forudsætninger

For at komme i gang har vi brug for 3 stykker software:

1. Git til Windows
2. TortoiseGit
3. OASIS-SVN

Strengt taget behøver du ikke 2. og 3. software. Du kunne faktisk nøjes med kun den første, men den store ulempe er, at du manuelt skulle eksportere/importere ved at skrive dit eget VBA-modul for at gøre dette, og tro mig, det er meget arbejde af årsager, der vil blive tydeligere som vi følger med. Derfor anbefales OASIS-SVN stærkt. Du behøver heller ikke at have TortoiseGit, men jeg kan virkelig godt lide at have en GUI for at gøre det nemt at arbejde. Det kan støde nogle kommandolinjepurister, som vil fortælle dig, at du bare skal bruge git i en kommandolinje, ikke via en smuk GUI. Jeg kan dog godt lide det doven og hurtigt, og det meste af tiden er processen enkel, at det er hurtigere for mig bare at udføre kommandoen fra en menu end at åbne en bash-shell og skrive en kommando. Når det er sagt, er TortoiseGit egentlig bare en tynd indpakning over git-kommandoer, så du bør gøre klogt i at være meget opmærksom på, hvilken git-kommando den kører, og hvad det betyder.

Installer dem alle; Jeg vil henvise til deres respektive websteder for detaljerede instruktioner. Når det hele er sat op, skal du have et projekt, du vil have styr på. Desuden har du brug for et sted, hvor du kan fungere som dit upstream-lager. Måske har du en Azure DevOps-konto? Bitbucket? GitHub? Der er flere muligheder tilgængelige for dig for at hoste din kildekodekontrol. For pokker, hvis du er tilbøjelig, kan du endda oprette en privat git-server. Men det er også uden for artiklens rammer. Igen henviser jeg til den respektive udbyders dokumentation for opsætning af et tomt lager.

Når du har et tomt lager, skal du have et link til det. Vi bruger Auzre DevOps, og vi har oprettet et nyt lager placeret på denne URL:
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication
Nu hvor vi har et link til et tomt lager, kan vi få opsætningen.

Oprettelse af et lokalt lager

Selvom OASIS-SVN har en guide, finder jeg det nemmere at klone et eksisterende lager og arbejde derfra. Du kan frit bruge guiden, som vil gøre noget lignende, men jeg tror, ​​at det at følge den manuelle vej vil hjælpe dig med at forstå, hvad der virkelig sker, og gøre det lettere at arbejde med værktøjerne. Vi vil antage, at vi har et program i en bestemt mappe:

Kildemappen er tom og vil være der, hvor vi vil gemme tekstfilerne til vores lokale depot. Vi kan højreklikke på det hvide mellemrum i mappen for at åbne TortoiseGit kontekstmenu og vælg klonlager.

I den dialog, der åbnes, skal du indtaste den URL, du har fået fra din hostingudbyder:

OBS

Du skulle derefter få en succesdialog om, at depotet er blevet klonet:

Som en effekt af kloning vil du nu have en skjult mappe ved navn .git . Det er sådan, git holder styr på dine commits og ændringer i dit lokale lager.

Vi har nu et fungerende lokalt lager, som vi derefter kan bruge til at holde vores tekstfiler fra Access. Vi bliver nødt til at konfigurere OASIS-SVN for at gøre brug af dette.

Konfiguration af OASIS-SVN

Som før nævnt har OASIS-SVN en guide, der kan bruges til at få os sat op, men vi ønsker at gøre dette manuelt, så du er fortrolig med, hvordan OASIS-SVN fungerer og dermed kan bruge guiden effektivt. Vi starter med at gå til Indstillinger menu på OASIS-SVN båndfanen.

Dette åbner dialogen. For lige nu skal vi kun gøre én ting; opsætte kildestien. Generelt finder jeg det mere bekvemt at bruge relativ sti frem for absolut sti, så vi indsætter \Source som illustreret:

Når den er sat ind, skal du så markere afkrydsningsfeltet brug altid :

Det gør depotmappen relativ og giver dig dermed mulighed for at flytte projektmappen hvor som helst du vil. Men pas på – hvis du kopierer eller flytter Access-filen uden for den mappe, kan den ikke holdes under kildekodekontrol, fordi OASIS-SVN så ikke ville have .oasis fil, som OASIS-SVN har brug for. Klik på OK for at lukke dialogen for at gemme ændringerne af indstillingerne. Hvis du kigger i mappen, vil du nu se .oasis fil til din ACCDB-fil.

.oasen fil er blot en XML-fil, der indeholder alle projektindstillingerne, og den skal have samme navn som ACCDB-filen, så OASIS-SVN ved, at denne ACCDB-fil skal være under kildekodekontrol. Så hvis du har for vane at omdøbe din ACCDB-fil, bliver du nødt til at bryde denne vane. Hvis din eksisterende arbejdsgang involverer omdøbning af fil, er en fremgangsmåde, jeg finder praktisk, at bruge et fast navn til udviklingskopi (f.eks. SampleApplication Dev.accdb , måske), når jeg skal ændre navnet, laver jeg en kopi af filen og angiver det rigtige navn. Det skal understreges, at med det i kildekodekontrol giver det mindre mening at omdøbe som et middel til at holde styr på versioner nu, da du burde være i stand til at genskabe det fra git-historikken i stedet for at have en masse forskelligt navngivne kopier.

Konfiguration af resten af ​​indstillinger

I det foregående trin satte vi kun kildefilen op, da vi ikke havde nogen .oasis fil; havde vi lavet andre ændringer, er den muligvis ikke blevet gemt, men nu har vi oprettet en som følge af indstilling af projektmappen, vi kan gennemgå resten af ​​indstillinger. Det er nok en god idé at overveje at have en skabelon .oasis fil, så du hurtigt kan kopiere og håndtweak for at få en ensartet projektindstilling for dine forskellige Access-projekter. Lad os gå tilbage til Indstillinger knappen på båndet og start med den første fane i dialogboksen.

Ruden Objekttyper

Fordi vi ikke længere arbejder med ADP'er, og vi ikke bruger de forældede dataadgangssider, fjerner vi normalt markeringen af ​​dem for at holde import/eksportdialogens rod til et minimum. Du kan også finde det praktisk at få det til at automatisk vælge den automatiske ændring, hvilket kræver sporing af objektets tidsstempel. Vær dog opmærksom på, at objektets tidsstempel ikke er fuldt pålideligt i Access. Vi vil diskutere dette mere i senere afsnit. Når det er sagt, er det en god måde at hjælpe med at påpege, om du måske har glemt at begå et vildfarent objekt.

Ruden Tabelindstillinger

Denne rude vil kræve nogle omhyggelige overvejelser og vil afhænge af den type projekter, du har at gøre med. Nummer et regel er, at du _ikke_ ønsker at kildekodekontrollere dataene i dine tabeller. Det giver ikke mening, da data ikke er kode. Det er dog ikke altid strengt taget sandt. For eksempel har vi en række tabeller, vi bruger som applikationskonfigurationsdata. På en måde er disse tabeller således "kode", da de påvirker, hvordan applikationen fungerer. Fordi størstedelen af ​​vores projekter er Access-frontends med en SQL Server-backends, er de tabeller, der normalt er til stede, hovedsageligt kun konfigurationstabeller og dermed egnede til kildekodekontrol. Men hvis vi havde datatabeller, skulle de sandsynligvis ikke inkluderes. Det er her Avanceret knappen er praktisk. Hvis du klikker på dette, åbnes denne dialogboks:

Ved at fjerne markeringen i Eksporter data for alle tabeller afkrydsningsfeltet nederst, kan du derefter vælge, hvilke tabellers data du vil beholde under kildekodekontrol, undtagen dem, der kun er datatabel og ikke en del af applikationens kildekode.

Vi inkluderer generelt heller ikke ODBC-linkede tabeller, fordi vi normalt har en koderutine til at genlinke tabellerne, så det giver ikke mening for os at have det i kildekodekontrol. Det er dog en god idé at have applikationskonfigurationstabellen eller måske endda blot definitionen for lokal tabel, da vi ville have en ødelagt applikation, hvis vi byggede en fil fra git repository uden disse tabellers definition.

Indstillingsruden

Vi har allerede set dette før, da vi oprettede .oasis fil. Nu hvor vi har filen, vil vi opsætte resten af ​​indstillinger. Her er vores typiske opsætning.

Som jeg nævnte i starten, kunne du tænke dig at skrive din egen import/eksport rutine. Værdien af ​​OASIS-SVN er dog, at vi kan løse forskellige problemer, der eksisterer med at holde Access-tekstfiler under kildekoden. For eksempel kan en Access-tekstfil have de typiske felter øverst i filen:
Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form
Disse er dårlige for kildekodekontrol, fordi de kan indføre unødvendige ændringer og forurene historien om ændringer, der ikke er ændringer. Kontrolsummen kan ændre sig, selvom du måske ikke har ændret noget ved selve formularen. Med OASIS-SVN kan vi fjerne de unødvendige data ved at bruge muligheden Saniser eksporterede filer :
Version =21
VersionRequired =20
Begin Form
...
End Form
Du har muligvis bemærket et gult advarselsikon for rapporter. Grunden til, at det er der, er, at OASIS-SVN også fjerner printerdataene, hvilket er notorisk dårligt til kildekodekontrol. Når rapporterne bruger standardprinteren, er det normalt ikke et problem. Det er dog ikke ualmindeligt at lave rapporter, der afhænger af en bestemt printer. For eksempel har vi måske en rapport, der laver stregkodeetiket på en specialiseret printer. I den rapport har vi valgt en bestemt printer i stedet for en standardprinter. Hvis du markerer dette felt for rapporter, betyder det, at printerdataene vil blive blæst væk. Hvis dit projekt ikke afhænger af bestemte printeropsætninger, kan det være lettere for dig at markere rapporterne. Ellers er der ingen grund til ikke at markere det for formularer.

Af lignende årsager elsker vi virkelig at have Split Form-filer og Opdel rapporter-filer mulighed markeret. Normalt Application.SaveAsText vil eksportere en enkelt tekstfil for et enkelt Access-objekt. Men hvis du har læst tekstfilen, vil du se, at layoutkoden kan være … trættende at læse. At markere denne indstilling betyder, at vi får 2 tekstfiler pr. Access-objekt; en til at indeholde alle layoutdata, og en anden den faktiske VBA-kildekode bag formularen. Det gør kodegennemgang meget nemmere, da du kan fokusere på VBA-ændringerne og forstå, hvad der er ændret, hvilket gør det lettere at fordøje, hvad layoutændringen handler om.

Du husker det måske fra det forrige afsnit om Objekttyper ruden, valgte vi den ændrede, hvilket kræver, at vi gemmer objektets dato/tid som en fildato/tid. Det er også afkrydset her. Det er værd at bemærke, at Access ikke altid pålideligt stempler tidsstemplet, når objekterne ændres. Vi vil diskutere dette igen i et senere afsnit om at lave forpligtelser.

Integrationsrude

Vi ønsker normalt at sikre, at autokorrekturen altid er slået fra, men endnu vigtigere er muligheden for at bruge Ctrl+S som en hokey til at udføre en eksport. Det er meget meget nyttigt og undgår problemet med Access-objektets tidsstempling. Dette kræver dog disciplin til konsekvent at bruge tastaturgenvejen til at gemme ændringerne. Hver gang du udfører tastaturet, vil du se denne dialog kort vist:

Det sikrer, at dit git-arbejdstræ holdes så tæt synkroniseret med din arbejdende ACCDB-fil, mens du arbejder dig igennem ændringerne. Det er vigtigt at understrege, at du ikke behøver at være bleg for at gemme ofte – det behøver ikke at betyde, at du skal foretage alle opsparinger, men ved at gemme ofte, vil dit arbejdstræ nøjagtigt afspejle omfanget af dine ændringer, når du er klar til at forpligte sig. Vi vil diskutere det i detaljer i senere afsnit.

Automatisk OPDATERING før import og Automatisk COMMIT efter eksport kan virke som en praktisk ting, men i praksis har vi fundet det meget at foretrække at gøre dette manuelt, især når vi eksporterer med Ctrl+S-genvejen, da vi ikke nødvendigvis ønsker at forpligte os; gem kun vores igangværende arbejde, så vi ved, hvad der er ændret, når vi faktisk er klar til at forpligte os. Af den grund udelader vi dem.

.oasis Indstilling af fil

Når du klikker på OK i indstillingsdialogen, vil de ændringer, du har foretaget i forskellige ruder, blive skrevet til .oasis fil i en XML-form. Som nævnt kan du kopiere den og lave en skabelon, så du har en hurtig måde at konfigurere en anden Access-applikation på. Vi er nu klar til at udføre nogle faktiske kildekodekontrol.

Eksport og forpligtelse

Som allerede nævnt, fordi vi arbejder med en binær fil, skal vi eksportere alt til en tekstlig repræsentation, så de kan styres korrekt af kildekodekontrollen. For at gøre dette skal vi eksportere objekterne. Du kan bruge OASIS-SVN eksportknap som angivet.

Du får en dialog med alle objekttyper, der er listet til eksport. Da dette er vores første eksport, vil vi bruge Ctrl + A for at vælge alle til eksport.

Klik på OK for at afslutte eksporten. Hvis alt går godt, får du en besked, der indikerer det.

Hvis du kigger inde i kildemappen, vil du se alle tekstfilerne, der repræsenterer forskellige objekter, som du lige har eksporteret. Bemærk, at navngivningskonventionen kan være anderledes afhængigt af, hvad du valgte i indstillingsruden som vist i forrige afsnit. Også fordi vi valgte at opdele filer, har vi begge en .def og et .layout fil for et enkelt Access-objekt.

Med objekterne eksporteret som tekstfiler, skal vi nu foretage vores ændringer. OASIS-SVN leverer TortoiseGit-kommandoerne direkte inde fra Access som vist.

Typisk vises de 4 kommandoer, du vil bruge, her - de andre kommandoer er gode at bruge, men vi behøver ikke bekymre os om det, før vi kommer ind i mere komplekse git-scenarier. Forresten, disse kommandoer er faktisk den samme kommando, som er eksponeret af TortoiseGit via Windows Explorers kontekstmenu:

Ydermere er et undersæt af kommandoer tilgængelige via højrekliksmenuen på Adgang til navigationsruden:

Du har således flere måder at udføre arbejde med enten OASIS-SVN eller med TortoiseGit direkte direkte fra Access, eller du kan bare bruge TortotiseGit direkte fra Windows Explorer. Bemærk, at du har Commit i alle skærmbilleder; hvilket bliver vores næste skridt. Hvis du vælger det, åbnes en TortoiseGit-dialog:

Du vil normalt vælge alle. Bemærk, at det kun sporer de tekstfiler, som vi lægger i projektmappen. Den pointe er værd at understrege; hvis du ikke eksporterede et objekt fra Access, kan git umuligt vide om det. Du skal give en beskrivende forpligtelsesbesked; jo detaljeret jo bedre. Vi foretrækker også at lave flere små commits, fordi historien på den måde er lettere at forstå. Du ønsker ikke at foretage en commit en gang om ugen med 1000 ændringer; det ville være umuligt at forstå. Du vil have en commit, når du er færdig med en opgave (f.eks. at rette en specifik fejl eller introducere en funktion), så din historie er nem at forstå.

Når du vænner dig til at begå dit arbejde, vil du måske bemærke, at TortoiseGit giver dig 3 muligheder for at forpligte dig:

Forpligt igen er nyttig, hvis du har brug for at foretage flere commits, fordi du har udført 2 eller flere opgaver, og du vil adskille commit for hver opgave. Det er nok bedst ikke at skulle gøre det og forpligte sig, så snart du er færdig med en opgave, men hvis du bliver fanget af begejstring, kontrollerer du blot kun et undersæt af filer, du vil begå, og klikker på genforpligtelse. TortoiseGit commiterer kun disse undersætfiler, og nulstiller derefter commit-dialogen, så du kan begå de andre undergrupper af filer med en separat besked.

Bekræft og skub bruges ofte til at kombinere commit og push. Det er vigtigt at huske, at commits kun skriver til dit lokale git-lager. Men vi startede med at have et fjernlager. Du kan ikke dele dine kodeændringer med dine kolleger eller have en ekstern backup af dit arbejde, før du har skubbet dine lokale commits til serveren, og det er det, push er for. Vi vil diskutere dette i detaljer senere.

Når du forpligter dig, vil TortoiseGit give dig en fremskridtsdialog og give dig besked, hvis det lykkedes.

Afslutning

Indtil videre har du lært, hvordan du opsætter et git-lager, får OASIS konfigureret og gør din første commit. Det ridser dog næsten ikke overfladen. Den fulde kraft af git er endnu ikke synlig, før du begynder at forgrene dig, læse historien og løse konflikterne. Det er dog strengt git-ting og har mindre at gøre med enten Access eller OASIS; enhver generel git-vejledning, som vi allerede linkede til i starten af ​​artiklen, vil være meget nyttig for at forstå, hvordan man administrerer et git-lager. Det er værd at minde om, at TortoiseGit kun er en tynd GUI-indpakning over git-kommandoer, så selvom tutorialen taler om at bruge en bash-shell, burde du være i stand til at gøre det samme via TortoiseGit-menuen med samme navn. Har du spørgsmål? Spørg væk i kommentarerne!