Използване на OASIS-SVN и git за контрол на изходния код на Access

ЗАБЕЛЕЖКА: Ще говоря подробно за тази тема в предстоящия месечен уебинар за Access и SQL Server на 9 юли от 18:30 CDT. Регистрирайте се, за да можете да видите процеса на живо и да задавате въпроси!

Тъй като работим с няколко приложения и понякога в екип, контролът на изходния код е доста важен за управлението на промените. Обичаме да използваме git за нашите проекти. Първоначално използването на git с Access би било предизвикателство, но благодарение на добавка, наречена OASIS-SVN, можем ефективно да използваме git с проекти на Access за управление на промените.

Защо да използвате контрола на изходния код? Не можете ли просто да го закопчаете?

Основната цел зад контрола на изходния код е да можете лесно да отговаряте на whodunit.

Това е особено важно, когато се занимавате с доклад за грешка и ви се напомня, че сте виждали нещо подобно преди и сте си помислили, че може би сте го поправили, но клиентът все още го докладва. Въпреки това, когато грешката беше „отстранена“ преди шест месеца, може да е и чисто нова грешка, защото вече сме забравили за корекцията, която поставихме преди 6 месеца. Не знам за вас, но перспективата да се разровите в куп архивирани архиви не изглежда много... откриваема.

Поставянето на вашите промени в контрола на изходния код изисква дисциплина, но ще направи много по-лесно преглеждането и управлението на промените. Можете лесно да търсите в историята и да видите какво точно се променя.

Друг сценарий е да разберем какво точно се промени. Ако сте направили няколко промени и трябва да ги прегледате, преди да пуснете нова версия, това е мястото, където контролът на изходния код ви помага. Имате възможност да проверите работата си и да се уверите, че сте направили всичко, което сте си поставили за цел. Няма повече „Мисля, че вече го направих“. само за да ви каже клиентът, че сте забравили онзи незначителен детайл, за който клиентът ви попита миналата седмица. Освен това, това позволява на екипа да прави прегледи на код за други; можем да разгледаме работата на другите и да предоставим обратна връзка и да си помогнем да поддържаме висок стандарт за качество.

Защо git? Access работи с Visual SourceSafe, нали?

Във версиите преди Access 2013, Access поддържаше първоначално контрол на изходния код, но използваше собствена спецификация на Microsoft, MSSCCI. За да стане още по-лошо, спецификацията предполага модел на напускане/чекиране, който дава на разработчиците изключително заключване на обектите, с които работят. Освен това таблиците в приложението Access бяха основно едно голямо петно, което не можеше да бъде прочетено, да не говорим за преглед.

На практика такъв модел е много тромав за използване дори в условия на малък екип. Един основен проблем е, че заявката за промяна рядко се потвърждава само за един обект; разработчиците може да се наложи да докоснат повече от шепа обекти и по този начин сблъсъците могат да бъдат неизбежни, особено за основните/споделените модули.

Git избягва цялата грозота, която виждаме при стария модел на напускане/чекиране, но това изисква различна философия при управлението на промените. Вместо да проверяваме нещо, ние просто обработваме клон и когато приключим с него, го сливаме обратно в основния клон. Можем да имаме няколко паралелни клона, ако искаме, но на практика се нуждаем само от 2 или 3 успоредни клона; един за представяне на производствената версия; друг за разработка и може би трети за корекции на критични грешки. Това може да стане с проект на Access и трябва да бъде. В противен случай може да бъде много трудно да се следи какво влиза в производствения файл, особено за нетривиални приложения.

Отличен ресурс за изучаване на git може да бъде намерен тук; има пясъчник, за да можете да играете заедно. Ако сте като мен и обичате да хапнете месните парченца и знаете как работи, това е добър ресурс.

И накрая, просто спрете да използвате Visual SourceSafe вече. Той е с бъгове, склонен е да губи вашите данни и не се поддържа от _години_, дори от Access от 2013 г. насам.

Но ако Access 2013+ вече не поддържа контрол на изходния код, как бихме могли да го имаме все още?!?

Тъй като OASIS-SVN не е доставчик на MSSCCI, а е просто добавка за достъп. Има други подобни добавки за достъп (например Ivercy например), които заобикалят ограничението. Във всички случаи тези добавки използват силно точно същите недокументирани методи, които Access използва вътрешно за контрол на изходния код; Application.SaveAsText и Application.LoadFromText . Тези методи все още присъстват в текущата версия на Access. Отстрани има UV елемент, който да го документира, за да осигури приемственост. OASIS-SVN продължава да работи добре дори с текущата версия на Access.

Защо продължавате да говорите за OASIS-SVN и git? Мога ли да използвам само едно или друго?

Важно е да разберете, че и двата инструмента се допълват и имате нужда и от двата. Вижте, причината, поради която имате нужда от OASIS-SVN, е, за да ви улесни възможно най-лесно да извадите упоритата си работа и да ги представите като куп текстови файлове, вместо да ги държите в голям блок от двоичен файл, който е ACCD* файл. Няма смисъл ACCDB файлът да бъде контролиран с изходен код, защото няма да има подходяща история на промените и би бил до голяма степен нечетлив. По този начин, OASIS-SVN е инструментът за създаване на текстови файлове, които могат да се използват за възстановяване на вашето приложение за Access и работата на git е всъщност да кодира тези файлове. git не може и не трябва да работи с ACCDB файла.

Ако сте нов в git, имате допълнителна стъпка в сравнение с това, което другите обикновено правят в своите проекти на Visual Studio, защото работите с двоичен файл, а не с действителен набор от папки с куп текстови файлове със забавни разширения. Така че ще трябва да свикнете постоянно да експортирате/импортирате промените си между ACCDB файла и текстовите файлове, които съставят вашето git хранилище.

Предварителни условия

За да започнем, имаме нужда от 3 софтуерни части:

1. Git за Windows
2. TortoiseGit
3. OASIS-SVN

Строго погледнато нямате нужда от 2-ри и 3-ти софтуер. Всъщност бихте могли да се справите само с първото, но големият недостатък е, че ще трябва ръчно да експортирате/импортирате, като напишете свой собствен VBA модул, за да направите това и повярвайте ми, това е много работа по причини, които ще станат по-ясни, тъй като следваме. Поради това OASIS-SVN се препоръчва силно. Също така не е нужно да имате TortoiseGit, но аз наистина харесвам да имам графичен интерфейс, за да улесня работата. Това може да обиди някои пуристи на командния ред, които ще ви кажат, че трябва просто да използвате git в команден ред, а не чрез красив GUI. Въпреки това, аз го харесвам мързеливо и бързо и през повечето време процесът е прост, тъй като за мен е по-бързо просто да изпълня команда от меню, отколкото да отворя bash shell и да напиша някаква команда. Въпреки това TortoiseGit всъщност е просто тънка обвивка върху git командите, така че трябва да обърнете голямо внимание на това коя команда git изпълнява и какво означава тя.

Инсталирайте ги всички; Ще се позова на съответните им уебсайтове за подробни инструкции. След като всичко това е настроено, трябва да имате проект, който искате да поставите под контрол. Освен това имате нужда от място, което да действа като ваше хранилище нагоре по веригата. Може би имате акаунт в Azure DevOps? Bitbucket? GitHub? Има няколко опции, които са ви достъпни за хостване на вашия контрол на изходния код. По дяволите, ако сте склонни, можете дори да настроите частен git сървър. Но това също е извън обхвата на статията. Отново ви препращам към документацията на съответния доставчик за настройка на празно хранилище.

След като имате празно хранилище, трябва да ви бъде предоставена връзка към него. Ние използваме Auzre DevOps и създадохме ново хранилище, разположено на този URL:
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication
Сега, когато имаме връзка към празно хранилище, можем да се настроим.

Създаване на локално хранилище

Въпреки че OASIS-SVN има съветник, намирам за по-лесно да клонирам съществуващо хранилище и да работя от там. Свободни сте да използвате съветника, който ще направи нещо подобно, но мисля, че следването на ръчния начин ще ви помогне да разберете какво наистина се случва и ще улесни работата с инструментите. Ще предположим, че имаме приложение в определена папка:

Папката Source е празна и ще бъде мястото, където ще съхраняваме текстовите файлове за нашето локално хранилище. Можем да щракнем с десния бутон върху бялото пространство в папката, за да отворим TortoiseGit контекстно меню и изберете клониране на хранилище.

В диалоговия прозорец, който се отваря, въведете URL адреса, който сте получили от вашия хостинг доставчик:

ВНИМАНИЕ

След това трябва да получите диалогов прозорец за успех, че хранилището е клонирано:

В резултат на клонирането вече ще имате скрита папка с име .git . Ето как git следи вашите ангажименти и промени във вашето локално хранилище.

Вече имаме работещо локално хранилище, което след това можем да използваме за съхраняване на нашите текстови файлове от Access. Ще трябва да конфигурираме OASIS-SVN, за да използваме това.

Конфигуриране на OASIS-SVN

Както споменахме по-горе, OASIS-SVN има съветник, който може да се използва, за да ни настрои, но ние искаме да направим това ръчно, за да сте запознати с това как работи OASIS-SVN и по този начин да можете да използвате съветника ефективно. Ще започнем, като отидем в Настройки меню в раздела на лентата OASIS-SVN.

Това ще отвори диалоговия прозорец. В момента трябва да направим само едно нещо; настройте пътя на източника. Като цяло намирам за по-удобно да използвам относителен път, а не абсолютен път, така че ще поставим \Source както е показано:

След като го поставите, трябва да поставите отметка в квадратчето винаги използвайте :

Това прави папката на хранилището относителна и по този начин ви позволява да премествате папката на проекта навсякъде, където пожелаете. Но внимавайте – ако копирате или преместите файла на Access извън тази папка, той не може да се поддържа под контрол на изходния код, защото OASIS-SVN тогава няма да има .oasis файл, от който OASIS-SVN се нуждае. Щракнете върху OK, за да затворите диалоговия прозорец, за да запазите промените в настройките. Ако погледнете в папката, сега ще видите .oasis файл за вашия ACCDB файл.

В.оазисът файлът е просто XML файл, който съдържа всички настройки на проекта и трябва да има същото име като ACCDB файла, така че OASIS-SVN да знае, че този ACCDB файл трябва да бъде под контрола на изходния код. По този начин, ако имате навика да преименувате своя ACCDB файл, ще трябва да прекъснете този навик. Ако съществуващият ви работен процес включва преименуване на файл, един подход, който намирам за удобен, е да използвате фиксирано име за копие за разработка (напр. SampleApplication Dev.accdb , може би), тогава, когато трябва да променя името, правя копие на този файл и предоставям правилното име. Трябва да се подчертае, че с него в контрола на изходния код, преименуването като средство за проследяване на версиите сега има по-малко смисъл, тъй като би трябвало да можете да го пресъздадете от историята на git, вместо да имате куп копия с различно име.

Конфигуриране на останалите настройки

В предишната стъпка настроихме само изходния файл, тъй като нямахме .oasis файл; ако сме направили други промени, може да не е запазена, но сега имаме такава, създадена в резултат на настройката на папката на проекта, можем да прегледаме останалите настройки. Вероятно е добра идея да помислите за наличието на шаблон .oasis файл, за да можете бързо да копирате и ръчно настройвате, за да имате еднаква настройка на проекта за различните си проекти на Access. Нека се върнем към Настройки бутон на лентата и започнете с първия раздел в диалоговия прозорец.

Панел Типове обекти

Тъй като вече не работим с ADP и не използваме оттеглените страници за достъп до данни, обикновено премахваме отметките от тях, за да сведем до минимум претрупването на диалоговия прозорец за импортиране/експортиране. Може също да ви е удобно да избирате автоматично автоматично променените, което изисква проследяване на времевата марка на обекта. Въпреки това, имайте предвид, че времевата марка на обекта не е напълно надеждна в Access. Ще обсъдим това повече в следващия раздел. Въпреки това е добър начин да помогнете да посочите дали може да сте забравили да зададете някакъв бездомен обект.

Панел с опции за таблица

Този панел ще изисква някои внимателни мисли и ще зависи от типа проекти, с които се занимавате. Правилото номер едно е, че вие ​​_не_ искате да контролирате изходния код данните във вашите таблици. Това няма смисъл, тъй като данните не са код. Това обаче не винаги е напълно вярно. Например, имаме редица таблици, които използваме като данни за конфигурация на приложението. По този начин в известен смисъл тези таблици са „код“, тъй като влияят върху това как ще работи приложението. Тъй като по-голямата част от нашите проекти са Access front-ends с backends на SQL Server, таблиците, които обикновено присъстват, са главно само конфигурационни таблици и по този начин подходящи за контрол на изходния код. Но ако имахме таблици с данни, те вероятно не би трябвало да бъдат включени. Това е мястото, където Разширени бутонът е полезен. Щракването върху това ще отвори този диалогов прозорец:

Като премахнете отметката от Експортиране на данни за всички таблици квадратчето за отметка в долната част, след това можете да изберете данните на таблиците, които искате да запазите под контрол на изходния код, с изключение на тези, които са само таблица с данни, а не част от изходния код на приложението.

Освен това обикновено не включваме ODBC свързани таблици, тъй като обикновено имаме рутинна програма за повторно свързване на таблиците, така че да го имаме в контрола на изходния код няма смисъл за нас. Въпреки това, наличието на таблица с конфигурация на приложението или може би дори само дефиницията за локална таблица е добра идея, тъй като бихме имали повредено приложение, ако изградим файл от git хранилище без дефиницията на тези таблици.

Екран с настройки

Вече видяхме това преди, когато създавахме .oasis файл. Сега, когато имаме файла, ще настроим останалите настройки. Ето нашата типична настройка.

Както споменах в началото, възможно е да напишете своя собствена рутина за импорт/експорт. Въпреки това, стойността на OASIS-SVN е, че можем да адресираме различни проблеми, които съществуват при запазването на текстови файлове на Access под изходен код. Например текстов файл на Access може да има типичните полета в горната част на своя файл:
Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form
Те са лоши за контрола на изходния код, защото могат да въведат ненужни промени и да замърсят историята на промените, които всъщност не са промени. Контролната сума може да се промени, въпреки че може да не сте променили нищо в самия формуляр. С OASIS-SVN можем да премахнем тези ненужни данни, като използваме опцията Санитизиране на експортираните файлове :
Version =21
VersionRequired =20
Begin Form
...
End Form
Може да сте забелязали жълта предупредителна икона за отчети. Причината за това е, че OASIS-SVN също ще премахне данните за принтера, което е известно лошо за контрола на изходния код. Когато отчетите използват принтера по подразбиране, това обикновено не е проблем. Въпреки това, не е необичайно да създавате отчети, които зависят от конкретен принтер. Например, може би имаме отчет, който прави етикет с баркод на специализиран принтер. В този отчет ще изберем конкретен принтер, а не принтер по подразбиране. Поставянето на отметка в това квадратче за отчети означава, че данните на принтера ще бъдат издухани. Ако вашият проект не зависи от конкретни настройки на принтера, може да ви е по-лесно да отметнете отчетите. В противен случай няма причини да не го отметнете за формуляри.

По подобни причини наистина обичаме да имаме файлове с разделен формуляр и Разделени файлове с отчети опцията е проверена. Обикновено Application.SaveAsText ще експортира един текстов файл за един обект на Access. Въпреки това, ако сте прочели текстовия файл, ще видите, че кодът на оформлението може да бъде ... досаден за четене. Отметката на тази опция означава, че получаваме 2 текстови файла на обект на Access; един да съдържа всички данни за оформлението, а другият действителния изходен код на VBA зад формуляра. Това прави прегледа на кода много по-лесен, тъй като можете да се съсредоточите върху промените във VBA и да разберете какво се е променило, което улеснява разбирането на какво се отнася промяната в оформлението.

Може да си спомните това от предишния раздел за Типове обекти панел, ние избрахме промененото, което изисква да запазим датата/часа на обекта като дата/час на файл. Това е отметнато и тук. Струва си да се отбележи, че Access не винаги надеждно отпечатва времевата марка при промяна на обектите. Ще обсъдим това отново в следващия раздел относно извършването на ангажименти.

Екран за интеграция

Обикновено искаме да гарантираме, че автоматичното коригиране винаги е изключено, но по-важна е опцията за използване на Ctrl+S като клавиш за експортиране. Това е много полезно и избягва проблема с времевата марка на обекта на Access. Това обаче изисква дисциплина за последователно използване на клавишната комбинация за запазване на промените. Всеки път, когато изпълнявате клавиатурата, ще видите този диалогов прозорец, показан за кратко:

Това гарантира, че вашето работно дърво на git се поддържа възможно най-близо в синхрон с вашия работещ ACCDB файл, докато работите през промените. Важно е да се подчертае, че не е нужно да се стеснявате да запазвате често – това не означава, че трябва да извършвате всяко записване, но като записвате често, вашето работно дърво ще отразява точно степента на промените ви, когато са готови да се ангажират. Ще обсъдим това подробно в следващия раздел.

Автоматично АКТУАЛИЗИРАНЕ преди импортиране и Автоматично COMMIT след експортиране може да изглежда като удобно нещо, но на практика сметнахме, че е много за предпочитане да правим това ръчно, особено когато експортираме с прекия път Ctrl+S, тъй като не е задължително да искаме да се ангажираме; запазваме само нашата незавършена работа, за да знаем какво се променя, когато действително сме готови да се ангажираме. Поради тази причина ги изоставяме.

.оазис Файл с настройки

След като щракнете върху OK в диалоговия прозорец за настройки, промените, които сте направили в различен панел, ще бъдат записани в .oasis файл в XML форма. Както споменахме, можете да го копирате и да направите шаблон, така че да имате бърз начин да конфигурирате друго приложение на Access. Вече сме готови да извършим действителен контрол на изходния код.

Експортиране и ангажиране

Както вече споменахме, тъй като работим с двоичен файл, трябва да експортираме всичко в текстово представяне, така че да могат да бъдат правилно управлявани от контрола на изходния код. За да направим това, трябва да експортираме обектите. Можете да използвате бутона за експортиране на OASIS-SVN, както е посочено.

Ще получите диалогов прозорец с всички типове обекти, изброени за експортиране. Тъй като това е първото ни експортиране, ще използваме Ctrl + A за да изберете всички за експортиране.

Щракнете върху OK, за да завършите експортирането. Ако всичко върви добре, ще получите съобщение, което го указва.

Ако погледнете в изходната папка, ще видите всички текстови файлове, представляващи различни обекти, които току-що експортирате. Имайте предвид, че конвенцията за именуване може да е различна в зависимост от това, което сте избрали в панела Настройки, както е показано в предишния раздел. Също така, тъй като избрахме да разделяме файлове, имаме и двете .def и .оформление файл за един обект на Access.

С обектите, експортирани като текстови файлове, сега трябва да запишем нашите промени. OASIS-SVN предоставя командите TortoiseGit директно от Access, както е показано.

Обикновено 4-те команди, които искате да използвате, са показани тук – другите команди са добри за използване, но не е нужно да се тревожим за това, докато не преминем към по-сложни git сценарии. Между другото, тези команди всъщност са същата команда, която са изложени от TortoiseGit чрез контекстното меню на Windows Explorer:

Освен това, подмножество от команди са достъпни чрез менюто с десния бутон на мишката в навигационния панел на Access:

По този начин имате няколко начина да извършвате работа или с OASIS-SVN, или с TortoiseGit директно от Access, или можете просто да използвате TortotiseGit директно от Windows Explorer. Обърнете внимание, че имате Commit във всички екранни снимки; което ще бъде следващата ни стъпка. Избирането му ще отвори диалогов прозорец на TortoiseGit:

Обикновено ще искате да изберете всички. Имайте предвид, че той проследява само текстовите файлове, които сме поставили в папката на проекта. Този момент си струва да се подчертае; ако не сте експортирали обект от Access, git не може да знае за него. Трябва да предоставите описателно съобщение за комит; колкото по-подробно, толкова по-добре. Ние също така предпочитаме да направим няколко малки комита, защото по този начин историята е по-лесна за разбиране. Не искате да правите комит веднъж седмично с 1000 промени; това би било невъзможно да се разбере. Искате ангажимент, след като завършите задача (например коригиране на конкретна грешка или въвеждане на функция), така че историята ви да е лесна за разбиране.

Тъй като свикнете да ангажирате работата си, може да искате да отбележите, че TortoiseGit ви дава 3 опции за ангажиране:

Отвържете е полезно, ако трябва да направите няколко комита, защото сте изпълнили 2 или повече задачи и искате да отделите комита за всяка задача. Вероятно е най-добре да не се налага да правите това и да се ангажирате веднага щом завършите задачата, но ако сте хванати от вълнение, просто проверявате само подмножество от файлове, които искате да зададете, и щракнете върху Recommit. TortoiseGit ще фиксира само тези подмножества файлове, след което ще нулира диалоговия прозорец за комитиране, за да можете да зададете другите подмножества файлове с отделно съобщение.

Commit &Push се използва често за комбиниране на commit и push. Важно е да запомните, че commits записва само във вашето локално git хранилище. Но започнахме с отдалечено хранилище. Не можете да споделяте промените в кода си с колегите си или да имате отдалечено архивиране на работата си, докато не изпратите вашите локални ангажименти към сървъра и за това е push. Ще обсъдим това подробно по-късно.

Когато се ангажирате, TortoiseGit ще ви предостави диалогов прозорец за напредъка и ще ви уведоми, ако е било успешно.

Приключване

Досега сте научили как да настроите git хранилище, да конфигурирате OASIS и да направите първия си комит. Това обаче едва надрасква повърхността. Пълната сила на git все още не е очевидна, докато не се захванете с разклоняване, четене на историята и разрешаване на конфликтите. Това обаче са строго git неща и имат по-малко общо нито с Access, нито с OASIS; всяко общо ръководство за git, което вече свързахме в началото на статията, ще бъде много полезно за разбирането как да управлявате git хранилище. Струва си да напомним, че TortoiseGit е просто тънка GUI обвивка върху git команди, така че дори урокът да говори за използване на bash shell, трябва да можете да правите същото чрез менюто на TortoiseGit със същото име. Имате въпроси? Питайте в коментарите!