Använder OASIS-SVN och git för åtkomst till källkodskontroll

OBS: Jag kommer att prata om detta ämne på djupet i det kommande månatliga webbseminariet för Access och SQL Server den 9 juli kl. 18:30 CDT. Registrera dig så att du kan se processen live och ställa frågor!

Eftersom vi arbetar med flera applikationer och ibland i ett team är källkodskontroll ganska viktigt för att hantera förändringar. Vi har börjat älska att använda git för våra projekt. Ursprungligen skulle det vara en utmaning att använda git med Access, men tack vare ett tillägg som heter OASIS-SVN kan vi effektivt använda git med Access-projekt för att hantera ändringarna.

Varför använda källkodskontroll? Kan du inte bara dra ihop den?

Huvudmålet bakom källkodskontroll är att enkelt kunna svara på whodunit.

Det är särskilt viktigt när du har att göra med en felrapport och du blir påmind om att du sett något liknande tidigare och du trodde att du kanske fixade det men kunden rapporterar det fortfarande. Men när felet "fixades" för sex månader sedan, kan det lika gärna vara ett helt nytt fel eftersom vi redan har glömt korrigeringen vi lade in för 6 månader sedan. Jag vet inte hur det är med dig men möjligheten att gräva igenom ett gäng zippade säkerhetskopior känns inte särskilt … upptäckbart.

Att lägga dina ändringar i en källkodskontroll kräver disciplin men kommer att göra det mycket lättare att granska och hantera ändringar. Du kan enkelt söka i historiken och se exakt vad som förändras.

Ett annat scenario är att ta reda på vad exakt förändrats. Om du har gjort flera ändringar och du behöver granska dem innan du trycker på en ny version, är det där källkodskontrollen hjälper dig. Du har möjlighet att kontrollera ditt arbete och se till att du gjort allt du tänkt dig. Inte mer "Jag tror att jag gjorde det redan." bara för att få veta av kunden att du glömde den där mindre detaljen som kunden frågade dig om förra veckan. Dessutom gör detta det möjligt för teamet att göra kodgranskningar för andra; vi kan titta på andras arbete och ge feedback och hjälpa varandra att hålla en hög kvalitetsstandard.

Varför git? Access fungerar med Visual SourceSafe eller hur?

I versioner före Access 2013 stödde Access källkodskontroll inbyggt, men det gjorde det med en proprietär Microsoft-specifikation, MSSCCI. För att göra det värre antar specifikationen en ut-/incheckningsmodell som ger utvecklare ett exklusivt lås över de objekt de arbetar med. Dessutom var tabellerna i Access-applikationen i princip en enda stor klump som inte gick att läsa än mindre granskas.

I praktiken är en sådan modell mycket besvärlig att använda även i ett litet team. En huvudfråga är att en ändringsförfrågan sällan bekräftas till endast ett objekt; utvecklarna kan behöva röra vid mer än en handfull objekt och därför kan kollisioner vara oundvikliga, särskilt för de centrala/delade modulerna.

Git undviker all fulhet som vi ser med gamla utchecknings-/incheckningsmodeller, men detta kräver en annan filosofi för att hantera ändringarna. Istället för att kolla upp något jobbar vi bara bort en gren och när vi är klara med den slår vi ihop den tillbaka till huvudgrenen. Vi kan ha flera grenar parallellt om vi vill men i praktiken behöver vi bara 2 eller 3 parallella grenar; en för att representera produktionsversionen; annan för utveckling och kanske en tredje för kritiska buggfixar. Detta kan göras med ett Access-projekt och bör vara det. Annars kan det vara mycket svårt att hålla reda på vad som kommer in i produktionsfilen, särskilt för icke-triviala applikationer.

En utmärkt resurs för att lära sig git finns här; den har en sandlåda så att du kan leka med. Om du är som jag och gillar att hacka på de köttiga bitarna och vet hur det fungerar är det här en bra resurs.

Slutligen, sluta bara använda Visual SourceSafe redan. Det är buggigt, benäget att förlora din data och har inte stötts på _år_, inte ens av Access sedan 2013.

Men om Access 2013+ inte längre stöder källkodskontroll, hur skulle vi kunna ha det kvar?!?

Eftersom OASIS-SVN inte är en MSSCCI-leverantör utan bara ett vanligt Access-tillägg. Det finns andra liknande Access-tillägg (t.ex. Ivercy till exempel) som fungerar runt begränsningen. I alla fall använder dessa tillägg flitigt exakt samma odokumenterade metoder som Access använde internt för källkodskontroll; Application.SaveAsText och Application.LoadFromText . Dessa metoder finns fortfarande i den nuvarande versionen av Access. Å andra sidan finns det ett UV-objekt för att dokumentera det för att säkerställa kontinuiteten. OASIS-SVN fortsätter att fungera bra även med den nuvarande Access-versionen.

Varför fortsätter du att prata om OASIS-SVN och git? Kan jag bara använda det ena eller det andra?

Det är viktigt att förstå att båda verktygen kompletterar varandra och att du behöver båda. Se, anledningen till att du behöver OASIS-SVN är att göra det enkelt som möjligt för dig att ta ut ditt hårda arbete och representera dem som ett gäng textfiler, snarare än att ha dem i en stor klump av en binär fil som är ACCD*-fil. Det är inte meningsfullt att låta ACCDB-filen vara källkodskontrollerad eftersom den inte skulle ha en korrekt förändringshistorik och i stort sett vara oläslig. Således är OASIS-SVN verktygen för att skapa textfilerna som kan användas för att bygga om din Access-applikation, och det är gits uppgift att faktiskt källkoda dessa filer. Git kan och bör inte fungera med ACCDB-filen.

Om du är ny på git har du ett extra steg jämfört med vad andra brukar göra på sina Visual Studio-projekt eftersom du arbetar med en binär fil, inte en faktisk uppsättning mappar med en massa textfiler med roliga tillägg. Så du kommer att behöva ta för vana att konsekvent exportera/importera dina ändringar mellan ACCDB-filen och textfilerna som utgör ditt git-förråd.

Förutsättningar

För att komma igång behöver vi tre programvaror:

1. Git för Windows
2. TortoiseGit
3. OASIS-SVN

Strängt taget behöver du inte den 2:a och 3:e programvaran. Du skulle faktiskt kunna nöja dig med bara den första men den stora nackdelen är att du måste manuellt exportera/importera genom att skriva din egen VBA-modul för att göra detta och tro mig, det är mycket arbete av skäl som kommer att bli tydligare eftersom vi följer med. Därför rekommenderas OASIS-SVN starkt. Du behöver inte heller ha TortoiseGit, men jag gillar verkligen att ha ett GUI för att göra det enkelt att arbeta. Det kan förolämpa vissa kommandorads-purister som kommer att tala om för dig att du bara ska använda git på en kommandorad, inte via ett vackert GUI. Men jag gillar det lat och snabbt och för det mesta är processen enkel att det är snabbare för mig att bara köra kommandot från en meny än att öppna ett bash-skal och skriva in något kommando. Som sagt, TortoiseGit är egentligen bara ett tunt omslag över git-kommandon, så du bör göra klokt i att vara uppmärksam på vilket git-kommando det kör och vad det betyder.

Installera dem alla; Jag hänvisar till deras respektive webbplatser för detaljerade instruktioner. När allt är klart måste du ha ett projekt som du vill ha kontroll över. Dessutom behöver du en plats att fungera som ditt uppströmsförråd. Kanske har du ett Azure DevOps-konto? Bit hink? GitHub? Det finns flera alternativ tillgängliga för dig för att vara värd för din källkodskontroll. Heck, om du är benägen kan du till och med ställa in en privat git-server. Men det ligger också utanför artikelns ram. Återigen, jag hänvisar dig till respektive leverantörs dokumentation för att ställa in ett tomt arkiv.

När du har ett tomt förråd bör du få en länk till det. Vi använder Auzre DevOps och vi har skapat ett nytt arkiv som finns på denna URL:
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication
Nu när vi har en länk för ett tomt arkiv kan vi installera.

Skapa ett lokalt arkiv

Även om OASIS-SVN har en guide, tycker jag att det är lättare att klona ett befintligt arkiv och arbeta därifrån. Du är fri att använda guiden som kommer att göra något liknande men jag tror att det att följa den manuella vägen hjälper dig att förstå vad som verkligen händer och göra det lättare att arbeta med verktygen. Vi antar att vi har ett program i en viss mapp:

Källmappen är tom och kommer att vara där vi kommer att lagra textfilerna för vårt lokala arkiv. Vi kan högerklicka på vitt utrymme i mappen för att öppna TortoiseGit snabbmenyn och välj klonförråd.

I dialogrutan som öppnas anger du URL:en du fick från din värdleverantör:

OBS

Du bör då få en framgångsdialog om att förvaret har klonats:

Som en effekt av kloning kommer du nu att ha en dold mapp som heter .git . Det är så git håller reda på dina commits och ändringar i ditt lokala arkiv.

Vi har nu ett fungerande lokalt arkiv som vi sedan kan använda för att hålla våra textfiler från Access. Vi kommer att behöva konfigurera OASIS-SVN för att kunna använda detta.

Konfigurera OASIS-SVN

Som nämnts tidigare har OASIS-SVN en guide som kan användas för att få oss att ställa in men vi vill göra detta manuellt så att du är bekant med hur OASIS-SVN fungerar och därmed kan använda guiden effektivt. Vi börjar med att gå till Inställningar menyn på menyfliken OASIS-SVN.

Detta öppnar dialogrutan. För just nu behöver vi bara göra en sak; ställ in källsökvägen. Generellt sett tycker jag att det är bekvämare att använda relativ sökväg snarare än absolut sökväg, så vi lägger in \Källa som illustreras:

När du har lagt in, bör du sedan markera kryssrutan använd alltid :

Det gör förvarsmappen relativ och gör att du kan flytta projektmappen vart du vill. Men se upp – om du kopierar eller flyttar Access-filen utanför den mappen kan den inte hållas under källkodskontroll eftersom OASIS-SVN då inte skulle ha .oasis fil som OASIS-SVN behöver. Klicka på OK för att stänga dialogrutan för att spara ändringarna av inställningarna. Om du tittar i mappen ser du nu .oasis fil för din ACCDB-fil.

.oasen filen är bara en XML-fil som innehåller alla projektinställningar, och den måste ha samma namn som ACCDB-filen så att OASIS-SVN vet att denna ACCDB-fil bör vara under källkodskontroll. Således, om du har för vana att byta namn på din ACCDB-fil, måste du bryta den vanan. Om ditt befintliga arbetsflöde involverar byte av fil, är en metod som jag tycker är praktisk att använda ett fast namn för utvecklingskopia (t.ex. SampleApplication Dev.accdb , kanske), när jag behöver ändra namnet, gör jag en kopia av den filen och anger det korrekta namnet. Det måste betonas att med det i källkodskontroll är det mindre meningsfullt att byta namn som ett sätt att hålla reda på versioner nu eftersom du borde kunna återskapa det från git-historiken snarare än att ha ett gäng kopior med olika namn.

Konfigurera resten av inställningarna

I föregående steg satte vi bara upp källfilen eftersom vi inte hade någon .oasis fil; hade vi gjort några andra ändringar kanske den inte har sparats, men nu har vi skapat en som ett resultat av att vi ställt in projektmappen, vi kan granska resten av inställningarna. Det är förmodligen en bra idé att överväga att ha en mall .oasis fil så att du snabbt kan kopiera och finjustera för att få en enhetlig projektinställning för dina olika Access-projekt. Låt oss gå tillbaka till Inställningar knappen på menyfliksområdet och börja med den första fliken i dialogrutan.

Fönstret Objekttyper

Eftersom vi inte längre arbetar med ADP:er och vi inte använder de föråldrade dataåtkomstsidorna, avmarkerar vi vanligtvis dessa för att hålla import/export-dialogrutans skräp till ett minimum. Du kan också tycka att det är praktiskt att låta den automatiskt välja den automatiska ändringen, vilket kräver spårning av objektets tidsstämpel. Var dock medveten om att objektets tidsstämpel inte är helt tillförlitlig inom Access. Vi kommer att diskutera detta mer i senare avsnitt. Som sagt, det är ett bra sätt att hjälpa till att påpeka om du kanske har glömt att begå något herrelöst föremål.

Fönstret Tabellalternativ

Den här rutan kommer att kräva några noggranna tankar och beror på vilken typ av projekt du har att göra med. Regel nummer ett är att du _inte_ vill styra data i dina tabeller med källkoden. Det är inte vettigt, eftersom data inte är kod. Det är dock inte alltid strikt sant. Till exempel har vi ett antal tabeller som vi använder som applikationskonfigurationsdata. På sätt och vis är dessa tabeller alltså "kod" eftersom de påverkar hur applikationen kommer att fungera. Eftersom majoriteten av våra projekt är Access-gränssnitt med en SQL Server-backend, är de tabeller som vanligtvis finns i huvudsak bara konfigurationstabeller och därför lämpliga för källkodskontroll. Men om vi hade datatabeller borde de förmodligen inte inkluderas. Det är där den avancerade knappen kommer väl till pass. Om du klickar på detta öppnas den här dialogrutan:

Genom att avmarkera Exportera data för alla tabeller kryssrutan längst ned kan du sedan välja vilka tabelldata du vill behålla under källkodskontroll, exklusive de som bara är datatabeller och inte en del av applikationens källkod.

Vi inkluderar i allmänhet inte ODBC-länkade tabeller eftersom vi vanligtvis har en kodrutin för att länka om tabellerna, så att ha den i källkodskontroll är inte vettigt för oss. Men att ha applikationskonfigurationstabellen eller kanske bara definitionen för lokal tabell är en bra idé eftersom vi skulle ha en trasig applikation om vi byggde en fil från git repository utan dessa tabellers definition.

Inställningsfönstret

Vi såg det redan tidigare när vi skapade .oasis fil. Nu när vi har filen kommer vi att ställa in resten av inställningarna. Här är vår typiska konfiguration.

Som jag nämnde i början kan du tänka dig att skriva din egen import/exportrutin. Men värdet av OASIS-SVN är att vi kan lösa olika problem som finns med att hålla Access-textfiler under källkoden. Till exempel kan en Access-textfil ha de typiska fälten överst i filen:
Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form
De är dåliga för källkodskontroll eftersom de kan införa onödiga ändringar och förorena historiken för ändringar som egentligen inte är förändringar. Kontrollsumman kan ändras även om du kanske inte har ändrat något i själva formuläret. Med OASIS-SVN kan vi ta bort onödiga data med alternativet Desinficera exporterade filer :
Version =21
VersionRequired =20
Begin Form
...
End Form
Du kanske har märkt en gul varningsikon för rapporter. Anledningen till att den finns där är att OASIS-SVN också kommer att ta bort skrivardata, vilket är notoriskt dåligt för källkodskontroll. När rapporterna använder standardskrivaren är det vanligtvis inte ett problem. Det är dock inte ovanligt att man skapar rapporter som beror på en specifik skrivare. Till exempel kanske vi har en rapport som gör streckkodsetiketter på en specialiserad skrivare. I den rapporten har vi valt en specifik skrivare snarare än en standardskrivare. Att markera den rutan för rapporter betyder att skrivardata kommer att blåsa bort. Om ditt projekt inte beror på några speciella skrivarinställningar, kanske du tycker att det är lättare att bocka av rapporterna. Annars finns det inga skäl att inte bocka av det för formulär.

Av liknande skäl älskar vi verkligen att ha Split Form-filer och Dela rapportfiler alternativet markerat. Normalt Application.SaveAsText kommer att exportera en enkel textfil för ett enstaka Access-objekt. Men om du har läst textfilen kommer du att se att layoutkoden kan vara ... tråkig att läsa. Att markera det här alternativet betyder att vi får 2 textfiler per Access-objekt; en för att innehålla all layoutdata, och en annan den faktiska VBA-källkoden bakom formuläret. Det gör kodgranskning mycket enklare eftersom du kan fokusera på VBA-ändringarna och förstå vad som ändrades, vilket gör det lättare att smälta vad layoutändringen handlar om.

Du kanske kommer ihåg det från föregående avsnitt om Objekttyper rutan, valde vi den ändrade, vilket kräver att vi sparar objektets datum/tid som ett fildatum/tid. Det är avmarkerat här också. Det är värt att notera att Access inte alltid stämplar tidsstämpeln på ett tillförlitligt sätt när objekten ändras. Vi kommer att diskutera detta igen i senare avsnitt om att göra åtaganden.

Integrationspanel

Vi vill vanligtvis säkerställa att den automatiska korrigeringen alltid är avstängd, men viktigare är alternativet att använda Ctrl+S som en hokey för att göra en export. Det är väldigt mycket användbart och undviker problemet med Access-objektets tidsstämpel. Detta kräver dock disciplin för att konsekvent använda kortkommandot för att spara ändringarna. När du använder tangentbordet kommer du att se den här dialogrutan kort:

Det säkerställer att ditt git-arbetsträd hålls så nära synkat med din fungerande ACCDB-fil när du arbetar igenom ändringarna. Det är viktigt att betona att du inte behöver vara blyg för att spara ofta – det behöver inte betyda att du behöver göra varje sparande, men genom att spara ofta, kommer ditt arbetsträd korrekt att återspegla omfattningen av dina ändringar när du är redo att engagera sig. Vi kommer att diskutera det i detalj i senare avsnitt.

Automatisk UPPDATERING före import och Automatisk COMMIT efter export kan verka som en bekväm sak men i praktiken har vi tyckt att det är mycket bättre att göra detta manuellt, speciellt när vi exporterar med Ctrl+S-genvägen eftersom vi inte nödvändigtvis vill commit; spara bara vårt pågående arbete så att vi vet vad som har förändrats när vi faktiskt är redo att engagera oss. Av den anledningen lämnar vi dem.

.oasis Inställningsfil

När du klickar på OK i inställningsdialogrutan kommer ändringarna du har gjort i olika fönster att skrivas till .oasis fil i en XML-form. Som nämnts kan du kopiera den och skapa en mall så att du snabbt kan konfigurera en annan Access-applikation. Vi är nu redo att göra lite faktisk källkodskontroll.

Exportera och förbinda sig

Som redan nämnts, eftersom vi arbetar med en binär fil, måste vi exportera allt till en textrepresentation så att de kan hanteras korrekt av källkodskontrollen. För att göra detta måste vi exportera objekten. Du kan använda OASIS-SVN-exportknappen enligt anvisningarna.

Du kommer att få en dialogruta med alla objekttyper listade för export. Eftersom detta är vår första export kommer vi att använda Ctrl + A för att välja alla för export.

Klicka på OK för att avsluta exporten. Om allt går bra får du ett meddelande som indikerar det.

Om du tittar in i källmappen ser du alla textfiler som representerar olika objekt som du just exporterat. Observera att namnkonventionen kan skilja sig beroende på vad du valde i fönstret Inställningar som visas i föregående avsnitt. Också eftersom vi valde att dela filer har vi båda en .def och en .layout fil för ett enstaka Access-objekt.

Med objekten exporterade som textfiler måste vi nu genomföra våra ändringar. OASIS-SVN tillhandahåller TortoiseGit-kommandon direkt från Access som visas.

Vanligtvis visas de 4 kommandona du vill använda här - de andra kommandona är bra att använda men vi behöver inte oroa oss för det förrän vi kommer in i mer komplexa git-scenarier. Förresten, dessa kommandon är faktiskt samma kommando som exponeras av TortoiseGit via Windows Explorers snabbmeny:

Dessutom finns en underuppsättning av kommandon tillgängliga via högerklicksmenyn på navigeringsfönstret Access:

Således har du flera sätt att utföra arbete med antingen OASIS-SVN eller med TortoiseGit direkt direkt från Access, eller så kan du bara använda TortotiseGit direkt från Windows Explorer. Observera att du har Commit i alla skärmdumpar; vilket kommer att bli vårt nästa steg. Om du väljer det öppnas en TortoiseGit-dialogruta:

Du kommer vanligtvis att vilja välja alla. Observera att den bara spårar textfilerna som vi lägger i projektmappen. Den punkten är värd att betona; om du inte exporterade ett objekt från Access kan git omöjligt veta om det. Du måste tillhandahålla ett beskrivande commit-meddelande; ju detaljerat desto bättre. Vi föredrar också att göra flera små commits eftersom historien är lättare att förstå. Du vill inte göra en commit en gång i veckan med 1000 ändringar; det skulle vara omöjligt att förstå. Du vill ha en commit efter att du är klar med en uppgift (t.ex. fixa en specifik bugg eller introducera en funktion), så att din historia är lätt att förstå.

När du har för vana att begå ditt arbete, kanske du vill notera att TortoiseGit ger dig tre alternativ för att engagera dig:

Återbinda är användbart om du behöver göra flera commits eftersom du har gjort 2 eller fler uppgifter och du vill separera commit för varje uppgift. Det är förmodligen bäst att inte behöva göra det och begå så fort du är klar med en uppgift, men om du fastnar i spänning, kontrollerar du helt enkelt bara en delmängd av filer du vill begå och klickar på recommit. TortoiseGit kommer bara att commitera de undermängdsfilerna, sedan återställer commit-dialogrutan så att du kan commitera de andra undermängderna av filer med ett separat meddelande.

Beslut och tryck används ofta för att kombinera commit och push. Det är viktigt att komma ihåg att commits endast skriver till ditt lokala git-förråd. Men vi började med att ha ett fjärrlager. Du kan inte dela dina kodändringar med dina kollegor eller ha en fjärrbackup av ditt arbete förrän du har skickat dina lokala commits till servern, och det är vad push är till för. Vi kommer att diskutera detta i detalj senare.

När du förbinder dig kommer TortoiseGit att ge dig en förloppsdialog och meddela dig om den lyckades.

Avsluta

Hittills har du lärt dig hur du ställer in ett git-förråd, får OASIS konfigurerat och gör din första commit. Det skrapar dock knappt på ytan. Den fulla kraften i git är ännu inte uppenbar förrän du börjar förgrena dig, läsa historien och lösa konflikterna. Men det är strikt git-saker och har mindre att göra med antingen Access eller OASIS; någon allmän git-guide som vi redan länkade till i början av artikeln kommer att vara till stor hjälp för att förstå hur man hanterar ett git-förråd. Det är värt att påminna om att TortoiseGit bara är ett tunt GUI-omslag över git-kommandon, så även om handledningen talar om att använda ett bash-skal, bör du kunna göra samma sak via TortoiseGit-menyn med samma namn. Har frågor? Fråga i kommentarerna!