Použití OASIS-SVN a git pro řízení zdrojového kódu Access

POZNÁMKA: O tomto tématu budu hovořit do hloubky v nadcházejícím měsíčním webináři Accessu a SQL Serveru 9. července v 18:30 CDT. Zaregistrujte se, abyste mohli sledovat proces živě a klást otázky!

Protože pracujeme s několika aplikacemi a někdy v týmu, kontrola zdrojového kódu je pro správu změn docela důležitá. Oblíbili jsme si používání git pro naše projekty. Původně by použití git s Accessem představovalo problém, ale díky doplňku s názvem OASIS-SVN můžeme efektivně používat git s projekty Access pro správu změn.

Proč používat kontrolu zdrojového kódu? Nemůžeš to prostě zapnout?

Hlavním cílem kontroly zdrojového kódu je umět snadno odpovědět na kohokoli.

To je zvláště důležité, když se zabýváte hlášením chyby a připomenete si, že jste už něco podobného viděli a mysleli jste si, že jste to možná opravili, ale zákazník to stále hlásí. Když však byla chyba „opravena“ před šesti měsíci, může to být také zcela nová chyba, protože jsme již zapomněli na opravu, kterou jsme zavedli před 6 měsíci. Nevím jak vy, ale vyhlídka na prohrabávání se hromadou zazipovaných záloh mi nepřipadá moc… objevitelná.

Umístění změn do ovládacího prvku zdrojového kódu vyžaduje disciplínu, ale mnohem snadněji bude kontrolovat a spravovat změny. Můžete snadno prohledat historii a zjistit, co přesně se změnilo.

Dalším scénářem je zjišťování, co přesně se změnilo. Pokud jste provedli několik změn a potřebujete je zkontrolovat, než vydáte novou verzi, pomůže vám kontrola zdrojového kódu. Máte příležitost zkontrolovat svou práci a ujistit se, že jste udělali vše, co jste si stanovili. Už žádné "Myslím, že jsem to už udělal." jen aby vám klient řekl, že jste zapomněli na drobný detail, na který se vás klient ptal minulý týden. Navíc to týmu umožňuje provádět kontroly kódu pro ostatní; můžeme se podívat na práci ostatních, poskytovat zpětnou vazbu a pomáhat si navzájem udržovat vysoký standard kvality.

Proč git? Access funguje s Visual SourceSafe, že?

Ve verzích před Accessem 2013 Access nativně podporoval ovládání zdrojového kódu, ale používal to proprietární specifikaci společnosti Microsoft, MSSCCI. Aby to bylo ještě horší, specifikace předpokládá model check-out/check-in, který dává vývojářům exkluzivní zámek nad objekty, na kterých pracují. Navíc tabulky v aplikaci Access byly v podstatě jeden velký blob, který nebylo možné číst, natož recenzovat.

V praxi je použití takového modelu velmi těžkopádné i v prostředí malého týmu. Jedním z hlavních problémů je, že žádost o změnu je zřídkakdy potvrzena pouze jednomu objektu; vývojáři mohou zjistit, že se potřebují dotýkat více než hrstky objektů, a proto mohou být kolize nevyhnutelné, zejména u základních/sdílených modulů.

Git se vyhýbá všem ošklivosti, kterou vidíme u starého modelu check-out/check-in, ale to vyžaduje jinou filozofii při řízení změn. Místo toho, abychom něco prověřili, prostě vypracujeme větev, a když s tím skončíme, sloučíme ji zpět do hlavní větve. Pokud bychom chtěli, můžeme mít několik větví paralelně, i když v praxi potřebujeme pouze 2 nebo 3 paralelní větve; jeden, který bude reprezentovat produkční verzi; další pro vývoj a možná třetí pro opravy kritických chyb. To lze provést pomocí projektu Access a mělo by být. Jinak může být velmi obtížné sledovat, co jde do produkčního souboru, zejména u netriviálních aplikací.

Vynikající zdroj pro učení git lze nalézt zde; má pískoviště, takže si můžete hrát. Pokud jste jako já a rádi si pochutnáte na masitých kouscích a víte, jak to funguje, je to dobrý zdroj.

Nakonec už jen přestaňte používat Visual SourceSafe. Je to zabugované, náchylné ke ztrátě dat a už _roky_ není podporováno, a to ani Accessem od roku 2013.

Pokud ale Access 2013+ již nepodporuje ovládání zdrojového kódu, jak bychom ho mohli mít stále?!?

Protože OASIS-SVN není poskytovatel MSSCCI, ale pouze prostý doplněk Access. Existují další podobné doplňky Accessu (například Ivercy), které toto omezení obcházejí. Ve všech případech tyto doplňky intenzivně využívají přesně stejné nezdokumentované metody, které Access interně používal pro řízení zdrojového kódu; Application.SaveAsText a Application.LoadFromText . Tyto metody jsou stále přítomny v aktuální verzi Accessu. Na druhé straně je zde UV položka, která to dokumentuje, aby byla zajištěna kontinuita. OASIS-SVN nadále dobře funguje i s aktuální verzí Accessu.

Proč pořád mluvíš o OASIS-SVN a git? Mohu použít jen jedno nebo druhé?

Je důležité pochopit, že oba nástroje se doplňují a potřebujete oba. Vidíte, důvod, proč potřebujete OASIS-SVN, je usnadnit vám co nejvíce usnadnit vaši tvrdou práci a reprezentovat je jako hromadu textových souborů, spíše než je mít uvnitř velkého blobu binárního souboru, který je ACCD* soubor. Nemá smysl, aby byl soubor ACCDB řízen zdrojovým kódem, protože by neměl správnou historii změn a byl by z velké části nečitelný. OASIS-SVN je tedy nástrojem pro vytváření textových souborů, které lze použít k přestavbě vaší aplikace Access, a úkolem Gitu je tyto soubory skutečně zdrojově kódovat. Git nemůže a neměl by pracovat se souborem ACCDB.

Pokud jste v gitu nováčkem, máte o krok navíc ve srovnání s tím, co ostatní obvykle dělají na svých projektech Visual Studio, protože pracujete s binárním souborem, nikoli se skutečnou sadou složek s hromadou textových souborů s vtipnými příponami. Budete si tedy muset zvyknout důsledně exportovat/importovat své změny mezi souborem ACCDB a textovými soubory, které tvoří váš git repozitář.

Předpoklady

Abychom mohli začít, potřebujeme 3 kusy softwaru:

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

Přísně vzato nepotřebujete 2. a 3. software. Ve skutečnosti byste si mohli vystačit pouze s prvním, ale velkou nevýhodou je, že byste museli ručně exportovat/importovat napsáním vlastního modulu VBA, abyste to udělali, a věřte mi, že je to hodně práce z důvodů, které budou jasnější, když následujeme. Proto se důrazně doporučuje OASIS-SVN. Také nemusíte mít TortoiseGit, ale opravdu se mi líbí mít GUI, které usnadňuje práci. To může urazit některé puristy z příkazové řádky, kteří vám řeknou, že byste měli git používat pouze v příkazové řádce, ne přes pěkné GUI. Líbí se mi to však líné a rychlé a většinu času je tento proces jednoduchý, protože je pro mě rychlejší pouze spustit příkaz z nabídky, než otevřít bash shell a zadat nějaký příkaz. To znamená, že TortoiseGit je ve skutečnosti jen tenký obal nad příkazy git, takže byste měli věnovat velkou pozornost tomu, jaký příkaz git spouští a co to znamená.

Nainstalujte je všechny; Pro podrobné pokyny odkazuji na jejich příslušné webové stránky. Jakmile je vše nastaveno, musíte mít projekt, který chcete mít pod kontrolou. Kromě toho potřebujete místo, které bude fungovat jako vaše upstream úložiště. Možná máte účet Azure DevOps? Bitbucket? GitHub? Existuje několik možností, jak hostovat ovládací prvek zdrojového kódu. Sakra, pokud máte chuť, můžete si dokonce nastavit soukromý git server. Ale to je také mimo rámec článku. Znovu vás odkazuji na dokumentaci příslušného poskytovatele pro nastavení prázdného úložiště.

Jakmile budete mít prázdné úložiště, měli byste na něj obdržet odkaz. Používáme Auzre DevOps a vytvořili jsme nové úložiště umístěné na této adrese URL:
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication
Nyní, když máme odkaz na prázdné úložiště, můžeme provést nastavení.

Vytvoření místního úložiště

Přestože má OASIS-SVN průvodce, zdá se mi snazší klonovat existující úložiště a pracovat odtud. Můžete volně použít průvodce, který udělá něco podobného, ​​ale myslím si, že postup podle manuálu vám pomůže pochopit, co se skutečně děje, a usnadní vám práci s nástroji. Budeme předpokládat, že máme aplikaci v konkrétní složce:

Složka Source je prázdná a bude tam, kde budeme ukládat textové soubory pro naše místní úložiště. Můžeme kliknout pravým tlačítkem na prázdné místo ve složce a otevřít TortoiseGit kontextové menu a vyberte úložiště klonů.

V dialogovém okně, které se otevře, zadejte adresu URL, kterou jste získali od poskytovatele hostingu:

POZOR

Poté byste měli obdržet dialogové okno o úspěchu, že úložiště bylo naklonováno:

V důsledku klonování nyní budete mít skrytou složku s názvem .git . Takto git sleduje vaše odevzdání a změny ve vašem místním úložišti.

Nyní máme funkční místní úložiště, které pak můžeme použít pro uložení našich textových souborů z Accessu. Abychom toho mohli využít, budeme muset nakonfigurovat OASIS-SVN.

Konfigurace OASIS-SVN

Jak již bylo zmíněno dříve, OASIS-SVN má průvodce, kterého lze použít k nastavení, ale chceme to udělat ručně, abyste byli obeznámeni s tím, jak OASIS-SVN funguje, a mohli tedy průvodce efektivně používat. Začneme tím, že přejdeme do Nastavení na kartě pásu karet OASIS-SVN.

Tím se otevře dialog. Právě teď totiž potřebujeme udělat jen jednu věc; nastavit zdrojovou cestu. Obecně považuji za vhodnější použít relativní cestu než absolutní cestu, takže vložíme \Source jak je znázorněno:

Po vložení byste měli zaškrtnout políčko vždy používat :

Díky tomu je složka úložiště relativní a umožňuje vám tak přesunout složku projektu kamkoli chcete. Ale pozor – pokud zkopírujete nebo přesunete soubor Access mimo tuto složku, nebude možné jej udržovat pod kontrolou zdrojového kódu, protože OASIS-SVN by pak neměl .oasis soubor, který OASIS-SVN potřebuje. Klepnutím na OK zavřete dialogové okno a uložte změny nastavení. Pokud se podíváte do složky, nyní uvidíte .oasis soubor pro váš soubor ACCDB.

.oáza soubor je pouze soubor XML, který obsahuje všechna nastavení projektu, a musí mít stejný název jako soubor ACCDB, aby OASIS-SVN věděl, že tento soubor ACCDB by měl být pod kontrolou zdrojového kódu. Pokud tedy máte ve zvyku přejmenovávat svůj soubor ACCDB, budete muset tento zvyk přerušit. Pokud váš stávající pracovní postup zahrnuje přejmenování souboru, jeden přístup, který považuji za užitečný, je použít pevný název pro vývojovou kopii (např. SampleApplication Dev.accdb , možná), a když potřebuji změnit název, vytvořím kopii tohoto souboru a poskytnu správný název. Je třeba zdůraznit, že s použitím kontroly zdrojového kódu má přejmenování jako prostředek ke sledování verzí nyní menší smysl, protože byste měli být schopni jej znovu vytvořit z historie git, než abyste měli hromadu různě pojmenovaných kopií.

Konfigurace zbývajících nastavení

V předchozím kroku jsme nastavili pouze zdrojový soubor, protože jsme neměli .oasis soubor; kdybychom provedli nějaké jiné změny, možná se neuložilo, ale nyní máme jednu vytvořenou jako výsledek nastavení složky projektu, můžeme zkontrolovat zbývající nastavení. Pravděpodobně je dobré zvážit použití šablony .oasis takže můžete rychle kopírovat a ručně vylepšovat, abyste měli jednotné nastavení projektu pro různé projekty Accessu. Vraťme se do Nastavení na pásu karet a začněte první kartou v dialogu.

Panel Typy objektů

Protože již nepracujeme s ADP a nepoužíváme zastaralé stránky pro přístup k datům, obvykle u nich zrušíme zaškrtnutí, abychom minimalizovali nepořádek v dialogu importu/exportu. Může být také užitečné nechat jej automaticky vybrat automaticky změněné, které vyžadují sledování časového razítka objektu. Mějte však na paměti, že časové razítko objektu není v Accessu plně spolehlivé. To probereme více v pozdější části. To znamená, že je to dobrý způsob, jak pomoci poukázat na to, zda jste nezapomněli spáchat nějaký zbloudilý předmět.

Panel Možnosti tabulky

Tento panel bude vyžadovat pečlivé zamyšlení a bude záviset na typu projektů, se kterými se zabýváte. Pravidlo číslo jedna je, že _nechcete_ řídit data ve svých tabulkách zdrojovým kódem. To nedává smysl, protože data nejsou kód. To však není vždy striktně pravda. Například máme řadu tabulek, které používáme jako konfigurační data aplikace. V jistém smyslu jsou tedy tyto tabulky „kódem“, protože ovlivňují, jak bude aplikace fungovat. Protože většina našich projektů jsou front-endy Accessu s backendy SQL Server, tabulky, které jsou obvykle přítomny, jsou hlavně pouze konfigurační tabulky, a proto jsou vhodné pro kontrolu zdrojového kódu. Ale pokud bychom měli datové tabulky, pravděpodobně by neměly být zahrnuty. To je místo Pokročilé tlačítko přijde vhod. Klepnutím na toto otevře toto dialogové okno:

Zrušením zaškrtnutí políčka Exportovat data pro všechny tabulky zaškrtávacím políčku dole, můžete pak vybrat, která data tabulek chcete ponechat pod kontrolou zdrojového kódu, s výjimkou těch, které jsou pouze datovou tabulkou a nejsou součástí zdrojového kódu aplikace.

Obecně také nezahrnujeme propojené tabulky ODBC, protože obvykle máme kódovou rutinu pro opětovné propojení tabulek, takže mít to v kontrole zdrojového kódu pro nás nedává smysl. Mít konfigurační tabulku aplikace nebo možná dokonce jen definici pro lokální tabulku je však dobrý nápad, protože pokud bychom vytvořili soubor z úložiště git bez definice těchto tabulek, měli bychom nefunkční aplikaci.

Panel nastavení

Už jsme to viděli, když jsme vytvářeli .oázu soubor. Nyní, když máme soubor, nastavíme zbytek nastavení. Zde je naše typické nastavení.

Jak jsem zmínil na začátku, můžete si případně napsat vlastní import/export. Hodnota OASIS-SVN však spočívá v tom, že můžeme řešit různé problémy, které existují s uchováváním textových souborů Accessu pod zdrojovým kódem. Například textový soubor Accessu může mít typická pole v horní části souboru:
Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form
Ty jsou špatné pro kontrolu zdrojového kódu, protože mohou zavádět zbytečné změny a znečišťovat historii změn, které ve skutečnosti změnami nejsou. Kontrolní součet se může změnit, i když jste na samotném formuláři ve skutečnosti nic nezměnili. S OASIS-SVN můžeme tato nepotřebná data odstranit pomocí možnosti Dezinfikovat exportované soubory :
Version =21
VersionRequired =20
Begin Form
...
End Form
Možná jste si všimli žluté varovné ikony u přehledů. Důvodem, proč to tam je, je to, že OASIS-SVN také odstraní data tiskárny, což je notoricky špatné pro kontrolu zdrojového kódu. Když sestavy používají výchozí tiskárnu, obvykle to není problém. Není však neobvyklé vytvářet sestavy, které závisí na konkrétní tiskárně. Například možná máme zprávu, která vytváří štítky s čárovým kódem na specializované tiskárně. V tomto přehledu vybereme spíše konkrétní tiskárnu než výchozí tiskárnu. Zaškrtnutí tohoto políčka pro zprávy znamená, že data tiskárny budou ztracena. Pokud váš projekt nezávisí na žádném konkrétním nastavení tiskárny, může být snazší odškrtávat zprávy. V opačném případě není důvod to u formulářů nezaškrtávat.

Z podobných důvodů opravdu milujeme Soubory rozdělených formulářů a Rozdělit soubory přehledů možnost zaškrtnuta. Normálně Application.SaveAsText exportuje jeden textový soubor pro jeden objekt aplikace Access. Pokud jste si však přečetli textový soubor, uvidíte, že čtení kódu rozvržení může být... ​​únavné. Zaškrtnutím této možnosti získáme 2 textové soubory na objekt Accessu; jeden obsahuje všechna data rozvržení a druhý skutečný zdrojový kód VBA za formulářem. Díky tomu je kontrola kódu mnohem snazší, protože se můžete soustředit na změny VBA a pochopit, co se změnilo, což usnadňuje pochopení toho, čeho se změna rozvržení týká.

Možná si to pamatujete z předchozí části Typy objektů v podokně jsme vybrali změněné, což vyžaduje, abychom uložili datum/čas objektu jako datum/čas souboru. To je zde také zaškrtnuto. Stojí za zmínku, že Access ne vždy spolehlivě orazítkuje časové razítko při změně objektů. Budeme o tom znovu diskutovat v pozdější části o vytváření commitů.

Podokno integrace

Obvykle chceme zajistit, aby byly automatické opravy vždy vypnuty, ale důležitější je možnost použít Ctrl+S jako hokey k provedení exportu. To je velmi užitečné a vyhnete se problému s časovým razítkem objektu Access. To však vyžaduje disciplínu pro důsledné používání klávesové zkratky k uložení změn. Kdykoli spustíte klávesnici, krátce se zobrazí tento dialog:

To zajišťuje, že váš pracovní strom git je udržován tak blízko synchronizace s vaším pracovním souborem ACCDB, když procházíte změnami. Je důležité zdůraznit, že se nemusíte ostýchat častého ukládání – nemusí to znamenat, že musíte provést každé uložení, ale díky častému ukládání bude váš pracovní strom přesně odrážet rozsah vašich změn jsou připraveni se zavázat. Podrobně to probereme v pozdější části.

Automatická AKTUALIZACE před importem a Automatické COMMIT po exportu se může zdát jako pohodlná věc, ale v praxi jsme zjistili, že je mnohem vhodnější to udělat ručně, zvláště když exportujeme pomocí zkratky Ctrl+S, protože se nutně nechceme zavázat; uložte pouze naši rozpracovanou výrobu, abychom věděli, co se změnilo, až budeme skutečně připraveni se zavázat. Z toho důvodu je necháváme vypnuté.

.oasis Nastavení souboru

Po kliknutí na tlačítko OK v dialogovém okně nastavení se změny, které jste provedli v různých podoknech, zapíší do .oasis soubor ve formátu XML. Jak již bylo zmíněno, můžete jej zkopírovat a vytvořit šablonu, abyste měli rychlý způsob, jak nakonfigurovat další aplikaci Access. Nyní jsme připraveni provést skutečnou kontrolu zdrojového kódu.

Export a potvrzení

Jak již bylo zmíněno, protože pracujeme s binárním souborem, musíme vše exportovat do textové reprezentace, aby je bylo možné správně spravovat pomocí kontroly zdrojového kódu. K tomu potřebujeme exportovat objekty. Můžete použít tlačítko exportu OASIS-SVN, jak je uvedeno.

Zobrazí se dialog se všemi typy objektů uvedenými pro export. Protože se jedná o náš první export, použijeme Ctrl + A vyberte vše pro export.

Klepnutím na OK export dokončete. Pokud vše půjde dobře, dostanete zprávu, která to potvrdí.

Pokud se podíváte do zdrojové složky, uvidíte všechny textové soubory představující různé objekty, které jste právě exportovali. Všimněte si, že konvence pojmenování se mohou lišit v závislosti na tom, co jste vybrali v podokně Nastavení, jak je znázorněno v předchozí části. Také proto, že jsme se rozhodli rozdělit soubory, máme oba .def a .layout soubor pro jeden objekt Access.

S objekty exportovanými jako textové soubory nyní musíme provést změny. OASIS-SVN poskytuje příkazy TortoiseGit přímo z aplikace Access, jak je znázorněno.

Obvykle jsou zde zobrazeny 4 příkazy, které budete chtít použít – ostatní příkazy je dobré používat, ale nemusíme si s tím dělat starosti, dokud se nedostaneme ke složitějším scénářům git. Mimochodem, tyto příkazy jsou ve skutečnosti stejné příkazy, které jsou vystaveny TortoiseGit prostřednictvím kontextové nabídky průzkumníka Windows:

Kromě toho je k dispozici podmnožina příkazů prostřednictvím nabídky po kliknutí pravým tlačítkem v navigačním panelu Přístup:

Máte tedy několik způsobů, jak pracovat buď s OASIS-SVN nebo s TortoiseGit přímo z Accessu, nebo můžete TortotiseGit použít přímo z průzkumníka Windows. Všimněte si, že máte Potvrdit na všech snímcích obrazovky; což bude náš další krok. Výběrem se otevře dialog TortoiseGit:

Obvykle budete chtít vybrat všechny. Všimněte si, že sleduje pouze textové soubory, které vložíme do složky projektu. Tento bod stojí za to zdůraznit; pokud jste neexportovali objekt z Accessu, git o něm nemůže vědět. Musíte poskytnout popisnou zprávu o odevzdání; čím podrobnější, tím lépe. Upřednostňujeme také několik malých odevzdání, protože tak je historie snazší pochopit. Nechcete provádět revizi jednou týdně s 1000 změnami; to by nebylo možné pochopit. Po dokončení úkolu (např. opravě konkrétní chyby nebo zavedení funkce) chcete potvrzení, aby byla vaše historie snadno srozumitelná.

Jak si zvyknete odevzdávat svou práci, možná budete chtít poznamenat, že TortoiseGit vám dává 3 možnosti, jak se zavázat:

Potvrdit znovu je užitečné, pokud potřebujete provést více odevzdání, protože jste provedli 2 nebo více úkolů a chcete oddělit odevzdání pro každý úkol. Pravděpodobně je nejlepší to nedělat a odevzdat, jakmile dokončíte úkol, ale pokud vás pohltí vzrušení, jednoduše zaškrtnete pouze podmnožinu souborů, které chcete odevzdat, a kliknete na znovu zadat. TortoiseGit odevzdá pouze tyto podmnožiny souborů, poté resetuje dialogové okno odevzdání, abyste mohli odevzdat další podmnožiny souborů se samostatnou zprávou.

Commit &Push se často používá ke kombinaci commit a push. Je důležité si uvědomit, že commity zapisují pouze do vašeho místního úložiště git. Ale začali jsme tím, že jsme měli vzdálené úložiště. Nemůžete sdílet změny kódu se svými spolupracovníky nebo mít vzdálenou zálohu své práce, dokud neodešlete své místní commity na server, a k tomu slouží push. Podrobnosti probereme později.

Když provedete potvrzení, TortoiseGit vám poskytne dialog o průběhu a upozorní vás, zda byl úspěšný.

Koneckonců

Zatím jste se naučili, jak nastavit úložiště git, nakonfigurovat OASIS a provést svůj první odevzdání. To však sotva poškrábe povrch. Plná síla git ještě není zřejmá, dokud se nedostanete do větvení, čtení historie a řešení konfliktů. To jsou však věci striktně git a mají méně společného s Accessem nebo OASIS; jakýkoli obecný průvodce git, který jsme již propojili na začátku článku, bude velmi užitečný pro pochopení toho, jak spravovat úložiště git. Stojí za to připomenout, že TortoiseGit je jen tenký obal GUI nad příkazy git, takže i když tutoriál hovoří o použití shellu bash, měli byste být schopni udělat totéž prostřednictvím nabídky TortoiseGit se stejným názvem. Máte otázky? Zeptejte se v komentářích!