Kako vraga naj verzioniram aplikacijo Access? Od mape s kopijami do gradnje iz commita

V mapi na omrežnem pogonu so Final.accdb, Final2.accdb, Final_ResPopravljen.accdb in, ker se je izkazalo, da ni bila res popravljena, še Final_ResPopravljen2.accdb. Če aplikacijo Access vzdržujete dlje od nekaj mesecev, takšno mapo poznate. Na prvi pogled je nered. V resnici je to nadzor različic – edini, ki ga ena sama binarna datoteka dopušča brez dodatnih orodij.

Okoli leta 2010 si je marsikateri razvijalec v Accessu zastavil isto vprašanje: kako vraga naj verzioniram aplikacijo, ki ima obrazce, poročila, poizvedbe in kodo v eni datoteki? S tem vprašanjem se je začela tudi pot, ki je pripeljala do Office SDK.

Ponedeljek zjutraj, kliče naročnik. Popusti na računih so narobe, »v petek je še delalo«. Vprašanje, ki ga ne izreče, je hujše: kaj ste spet spremenili? Odprete tri kopije drugo ob drugi in na oko primerjate lastnosti. Kolega je medtem v svoji kopiji spremenil obrazec. Eno od obeh sprememb bo nekdo pozneje prenesel ročno, ali pa se bo izgubila in tega nihče ne bo opazil. Kaj pa izdaja, ki jo ima naročnik? To je ACCDB, ki je bila tisti dan pač na vašem računalniku, prevedena v ACCDE – skupaj s preizkusnim obrazcem, staro povezavo in napol dokončanim modulom. Katera natanko, ne veste ne vi ne on.

Pri tem ne gre za disciplino. ACCDB je datoteka podatkovne zbirke in nobeno orodje za primerjavo vam ne pokaže, kateri objekt v njej se je spremenil. Težava je v obliki zapisa, ne v vas.

Ironija je očitna. Te aplikacije pogosto skrbijo, da je v računovodstvu, skladišču ali proizvodnji vsak korak sledljiv. Iz česa so sestavljene same, pa ne znajo povedati.

Na forumih boste o Accessu prebrali, da je škoda časa in da se ga splača znati le še takrat, ko nekaj že obstaja in je treba kaj popraviti. Ampak prav to je delo. Aplikacija obstaja, podjetje z njo dela vsak dan, in ko se kaj zalomi, pokličejo programerja. Tisti programer ste vi.

Preden gremo naprej, se ustavimo pri besedi »verzionirati«. V vsakdanjem delu z Accessom pogosto pomeni: shranjevati kopije datoteke ACCDB. Drugod v razvoju programske opreme pomeni: vsako spremembo vsakega dela beležiti posebej, jo primerjati, spojiti z drugimi in po potrebi preklicati. Med tema pomenoma je vsa pot od mape s kopijami do projekta.

Začnimo pošteno. Za Access 2010 je Microsoft brezplačno ponujal dodatek »Microsoft Access 2010 Source Code Control«. Dodatek je Access prek skupnega vmesnika MSSCCI povezal z Visual SourceSafom ali s katerim drugim sistemom za nadzor izvorne kode, ki je ta vmesnik podpiral. Poizvedbe, obrazce, poročila, makre in module je bilo mogoče prevzemati (check-out) in vračati (check-in) vsakega posebej. Team Foundation Server se je s programi, ki niso poznali Team Explorerja, povezal prek svojega ponudnika MSSCCI.

Kaj je bilo pri tem prav: enota nadzora različic je bil objekt, ne datoteka. Prevzem pa je preprečil, da bi isti obrazec hkrati spreminjala dva razvijalca. Za majhne ekipe z osrednjim strežnikom je bil takšen model zaklepanja tedaj običajna pot. Misel, da ima obrazec svojo zgodovino, so prevzela vsa poznejša orodja.

Potem je prišel Access 2013. V Microsoftovem seznamu ukinjenih funkcij od takrat piše, da Source Code Control za razvijalce v Accessu 2013 ni več na voljo kot dodatek. V stolpcu za nadomestilo piše: N/A.

Razvijalci, ki so svoj razvojni postopek zgradili na tej povezavi, so ob prehodu ostali brez nje. Naročnika to seveda ni zanimalo: on je hotel popravek do petka, ne razlage, zakaj je Microsoft ukinil dodatek. Prelomljena obljuba v pogodbenem smislu to ni bila, saj Microsoft ni nikoli zagotovil, da bo povezavo vzdrževal večno. Občutek pa je bil prav tak: platforma je pokazala, da nadzor različic sodi k razvoju, nato pa ga je vzela nazaj. Nauk, ki si ga je zapomnilo veliko razvijalcev: razvojnega postopka ne obešajte na dodatek, ki ga lahko izklopi nekdo drug.

Ostali sta dve metodi, ki ju Access pozna že dolgo. SaveAsText obrazec, poročilo, poizvedbo, makro ali modul zapiše kot besedilno datoteko, LoadFromText ga naloži nazaj. Razvijalci so ju dolga leta imeli za skriti in nedokumentirani metodi. Danes ima Microsoft Learn zanju kratki referenčni strani in nadzor različic izrecno navaja kot namen uporabe. Pri LoadFromText pa piše tudi, da metoda ni podprta, je pa med razvijalci zelo razširjena.

Na teh dveh metodah je zrasla cela generacija orodij. Najbolj znano je verjetno odprtokodno orodje msaccess-vcs-addin Adama Wallerja, ki je na GitHubu od leta 2015. Obrazce, poročila, poizvedbe, module, podatke tabel in teme izvozi kot besedilo in iz njih znova zgradi celotno podatkovno zbirko. Ivercy Philippa Stiefla nadaljuje vgrajeni pristop starega Source Code Control, za Access od različice 2007 do Microsoft 365, z vsakim sistemom, ki podpira MSSCCI, vse do Azure DevOps Serverja. Če danes začenjate z Accessom in Gitom, lahko izbirate med dvema zrelima rešitvama.

Z izvozom pa se začne drugi nesporazum: verzionirati datoteko ni isto kot verzionirati projekt.

• SaveAsText ne zajame tabel, podatkov, sklicev in lastnosti podatkovne zbirke. Iz samih besedil ne nastane aplikacija, ki bi delovala.
• Access ob vsakem shranjevanju na novo zapiše vrednosti, ki z vašo spremembo nimajo zveze. Obrazec, ki ste ga le odprli in shranili, se v primerjavi pokaže kot spremenjen. Če želite takšne vrednosti odstraniti, morate prej izmeriti, katere so res odveč.
• Besedilo mora tudi nazaj. Če spremenite izvorne datoteke, potrebujete podatkovno zbirko, ki vsebuje natanko te izvorne datoteke.

Naša pot je vodila prek treh predhodnikov, ki so v SDK pustili sledi. DATEC Access SDK, samostojno orodje, je objekte Access že vodil kot besedilo, z ukazno vrstico, MSBuildom, dodatkom in projektno datoteko .acproj. Orodje za gradnjo knjižnice Forms Object Library, skript PowerShell z opisom v access-app.json, je aplikacije te knjižnice gradilo iz besedilnih izvornih datotek. Dodatek WklExtensions.accda pa je v Accessu odpiral oblikovalnike knjižnice. Kdaj natanko je nastalo katero orodje, današnji repozitoriji ne dokazujejo. Zato zgodbo urejamo po težavah, ne po letnicah.

Office SDK je napisan na novo. Od DATEC Access SDK je prevzel oblike zapisa, kode pa ne. Projekte obeh orodij za gradnjo wkl-office migrate pretvori v enem koraku, stari projekt pa pri tem samo prebere. Oblikovalniki, ki jih je odpiral WklExtensions.accda, so danes na traku SDK.

Kaj se s tem spremeni, najbolje pokaže mapa. Prej, ena datoteka za vsako stanje:

\\streznik\Access\Stranke\
  Final.accdb
  Final2.accdb
  Final_ResPopravljen.accdb
  Final_ResPopravljen2.accdb

Danes od te mape do projekta vodi eno samo pogovorno okno dodatka za Access. Izhodišče je lahko kar zadnja kopija iz mape, Final_ResPopravljen2.accdb: če odprta podatkovna zbirka ne pripada nobenemu projektu, meni projektov SDK ponudi ukaz Nov projekt iz te podatkovne zbirke…, ki odpre to pogovorno okno. SDK ustvari mapo projekta in vanjo izvozi podatkovno zbirko, datoteka sama pa ostane nespremenjena. Če vas naročnik kdaj vpraša, iz česa ste začeli, jo imate še vedno.

Korak od mape s kopijami do projekta. Označene tabele svoje vrstice prenesejo v izvorne datoteke kot začetne podatke; tabel z delovnimi podatki uporabnikov, na primer naročil, raje ne označite. Opomba pod mapo projekta vnaprej pove, kar bi sicer opazili šele ob prvem odpiranju: dokler izhodna mapa ni zaupanja vredno mesto, Access podatkovne zbirke, zgrajene v njej, odpre z onemogočeno kodo.

Potem, ena datoteka za vsak objekt: projekt Stranke iz vadnice po prvem izvozu.

Stranke/
  Stranke.acproj                 projektna datoteka (XML za MSBuild)
  source/
    forms/frmStranke.form.txt    obrazec kot besedilo
    queries/  modules/  classes/  reports/
    tables/tblDrzave.table.json  shema tabele
    data/tblDrzave.jsonl         začetni podatki, vrstica za vsak zapis
    references.json
    application/properties.json
  build/                         zgrajeno, ni v repozitoriju
    Debug/Stranke.accdb
    Release/Stranke.accde

Vsaka vrzel s seznama zgoraj ima tu svoje mesto: tabele kot shema, začetni podatki kot vrstice, sklici in lastnosti podatkovne zbirke v svojih datotekah. ACCDB v mapi build/ ni več izvirnik, ampak rezultat. Vsak, ki je kdaj prevzel tujo aplikacijo Access, ve, koliko je vredno začeti iz repozitorija namesto iz kupa kopij.

Ko je aplikacija besedilo, jo lahko prebere vsako orodje, ki razume besedilo. git log pokaže, kdaj se je obrazec spremenil. V zahtevi za spajanje (pull request) je poizvedba besedilo, ki ga kolega pregleda, preden gre k naročniku. Urejevalnik pokaže kodo, ne da bi moral teči Access.

Za Visual Studio Code je govorilo to, kar je že imel: pogled za Git, terminal, opravila in seznam težav, kjer vas klik pripelje na pravo mesto. SDK uporablja natanko to. wkl-office new v projektu ustvari datoteko .vscode/tasks.json z opravili Build, Rebuild, Run, Run as Runtime, Check, Status, Export in Sync. Ctrl+Shift+B zgradi aplikacijo. Vsako opravilo pokliče wkl-office z možnostjo --format msbuild, zato je vsaka težava ena vrstica v obliki prevajalnika MSBuild, ki jo Visual Studio Code prebere sam.

Dejanski posnetek: projekt, ki ga je ustvaril wkl-office new, odprt v Visual Studio Code. Opravilo Check je zapisalo vrstico iz wkl-office check --format msbuild, pogled Problems jo prikaže, klik pa odpre datoteko pri navedeni vrstici.

Veliko zamisli ni naših in prav je, da to povemo. Projektna datoteka je XML za MSBuild kot v Visual Studiu, dotnet build pa .acproj zgradi kot vsak drug projekt. Konfiguraciji gradnje Debug in Release, ločitev konfiguracije od profila objave in strani z lastnostmi projekta so znane iz Visual Studia. Če ste delali v Delphiju, isti vzorec poznate iz upravitelja projektov: projektna datoteka, konfiguracije, gradnja brez klikanja.

Česa ni bilo mogoče prenesti: obrazce in poročila oblikujete v Accessu. Noben urejevalnik besedila ne nadomesti oblikovalnika obrazcev in SDK se tega niti ne loteva. Kodo, ki jo spremenite v Visual Studio Code, wkl-office sync prenese v odprto podatkovno zbirko. S tem obstajata dve strani, ki se lahko spreminjata, in pravilo, ki ne pozna izjem: objekt, ki je bil spremenjen v Accessu in v izvornih datotekah, se ne prepiše. Postopek se ustavi, dokler ne odločite, katera stran velja.

Tu se je pokazala naslednja šibka točka postopka. Razvijalec v Accessu preživi dan v oblikovalniku obrazcev in urejevalniku VBA. Če mora za vsak izvoz preklopiti v drug program, ga prej ali slej pozabi. Sprememba je potem spet le v datoteki ACCDB, izvorne datoteke niso več resnica, naročnik pa dobi izdajo brez popravka, ki ste mu ga obljubili.

Zato smo pogoste korake prenesli tja, kjer razvijalec dela. Dodatek SDK na traku programa Access doda zavihek Office SDK s skupinami Projekt, Viri, Gradnja, Izdaja in Orodja. Pod njim je delovno območje, podokno opravil v Accessu, ki je zasidrano spodaj kot plošča v Visual Studio Code. Njegovi zavihki so Projekt, Izhod, Težave, Spremembe in Terminal.

Dejanski posnetek iz Accessa z nemškim uporabniškim vmesnikom. Kar je bilo v Visual Studio Code opravilo, je tu ukaz na traku: zavihek Office SDK z odprtim menijem Build, pod njim pa delovno območje z izhodom, težavami in spremembami.

• Zavihek Spremembe za vsak objekt pokaže stanje med Accessom in izvorno datoteko, stanje v Gitu in naslednji korak. Od tam spremembe potrdite (commit); potisnete jih šele s posebnim ukazom.
• Terminal zažene lupino v mapi projekta, PowerShell 7 ali, če ga ni, Windows PowerShell. Če raje tipkate, vam zato ni treba zapustiti Accessa.
• V urejevalniku VBA se isto delovno območje pokaže kot okno. Ctrl+S spremenjene objekte izvozi v izvorne datoteke in nato preveri kodo.
• Zgradi in znova odpri najprej preveri stanje in gradnjo zavrne, dokler je v Accessu sprememba, ki je ni v izvornih datotekah. Gradnja teče v ločenem, skritem Accessu, vaš Access pa ostane odziven.

Zavihek Spremembe: modul basOne je bil spremenjen v Accessu, izvožen pa še ni. Zadnji stolpec pove, kaj je treba narediti naslednje. Dokler je ta vrstica tu, »Zgradi in znova odpri« ne zgradi ničesar – in stanje brez te spremembe ne more v izdajo.

Raziskovalca rešitev, kakršnega pozna Visual Studio, ni. Pregled nad projektom dajejo meni projekta z nazadnje uporabljenimi projekti, zavihek Projekt v delovnem območju in pogovorno okno Lastnosti projekta, ki je zasnovano kot strani z lastnostmi v Visual Studiu. Podrobnosti so na strani Uporaba dodatka za Access.

Tudi »gradnja« ima dva pomena. V marsikateri ekipi pomeni: vzemi najnovejšo datoteko in jo prevedi v ACCDE. V SDK pomeni: aplikacijo sestavi iz natanko določenega stanja izvornih datotek, korak za korakom in vsakič enako. Merodajen je repozitorij; ACCDB in ACCDE sta rezultata gradnje in nikoli ne gresta v commit.

Konfiguracija gradnje določa, kako se gradi: ali nastane ACCDE, v katerem načinu teče model aplikacije in s katerim profilom povezave se povežejo tabele. Profil izdaje določa, kaj gre komu. Visual Studio ju loči enako. Na strani o obeh pojmih je to razloženo na primeru dveh strank, od katerih ima vsaka svojo povezavo do podatkovne zbirke.

Lastnosti resničnega projekta: konfiguracija gradnje Administration ustvari ACCDE v načinu Administration. Nastavitev je zapisana v projektni datoteki, zato je pod nadzorom različic tako kot koda.

Kaj tu pomeni »ponovljivo«, raje povemo natančno. Iste izvorne datoteke, zgrajene z isto različico SDK, istim Accessom, istimi sklici in isto kodno stranjo, dajo iste objekte, tabele, podatke in nastavitve. Datoteka pa ni enaka do bajta, ker Access vsakemu naloženemu objektu dodeli nov GUID in shrani časovne žige.

Zakaj je ta razlika pomembna, pokaže spor, ki ga pozna vsak, ki dela za naročnike. Naročnik trdi, da popravka nima. Vi trdite, da ste mu ga poslali. Manifest izdaje za vsako datoteko hrani vrednost SHA-256: če se vrednost datoteke pri naročniku ujema, ima natanko to, kar ste izdali, če se ne, ima nekaj drugega. O tem se ni več treba prerekati. Vsako izdajo pa lahko z oznako (tag) povežete s commitom in jo kadar koli znova zgradite z istimi objekti, tabelami in nastavitvami. Ponovno zgrajena datoteka ima sicer druge vrednosti SHA-256, vsebina pa je ista. Tudi naročniku to nekaj pomeni: kar je prejel, je mogoče znova zgraditi iz commita, ne le iz datoteke na disku enega samega izvajalca.

Trije koraki se pogosto zlijejo v enega:

• Gradnja: wkl-office build -c Release iz commita izdela ACCDE.
• Priprava izdaje: wkl-office deliver za vsak profil sestavi, kar potrebujejo uporabniki: podatkovno zbirko, manifest z velikostjo in vrednostjo SHA-256 vsake datoteke, knjižnice WKL in zaganjalnik. wkl-office msi iz tega izdela namestitveni paket za oddelek IT.
• Razdeljevanje: na računalnike uporabnikov aplikacije ne prenese SDK, ampak Bootstrapper. O tem bo govoril poseben zapis.

Da lahko zabeležite, kateri commit je postal katera izdaja, ni le stvar reda. Proizvajalci programske opreme, ki spada na področje uporabe akta o kibernetski odpornosti (Uredba (EU) 2024/2847), morajo obravnavati in prijavljati nekatere ranljivosti in varnostne incidente; obveznosti prijavljanja veljajo od 11. septembra 2026. Ali aplikacija Access spada na to področje in kdo je njen proizvajalec, je odvisno od primera: od tega, ali je v okviru gospodarske dejavnosti dostopna na trgu, in od vloge dobavitelja. Kaj uredba v tem primeru zahteva, piše na strani Obveznosti založnika.

»Preizkušeno« je dolgo pomenilo: odpreš aplikacijo, malo poklikaš, nič se ne sesuje. Bolje kot nič, a ni ponovljivo. In nihče ob dveh zjutraj pred izdajo ne bo vsega še enkrat preklikal.

Vzemimo primer, ki izhaja iz preizkusa v dokumentaciji SDK. Recimo, da pred izdajo nekdo poenostavi brisanje naročil. Vprašanje »Izbrišem naročilo?« se še vedno pokaže, odgovor pa se ne upošteva več. S klikanjem tega ne opazite: kdor klika, odgovori z Da in izbriše se, kar naj bi se izbrisalo. Odgovora Ne pri klikanju nihče ne preizkusi. Prvi, ki bo napako opazil, bo naročnik – ko bo v skladišču manjkalo naročilo, pri katerem je uporabnik izrecno kliknil Ne. In klic bo spet prišel k vam.

Preizkus, ki ta primer zabeleži, na vprašanje odgovori z Ne in nato preveri, ali naročilo 42 še obstaja. Izpis je tak:

OK   Orders_Total: total of two lines
FAIL Orders_DeleteAsks: order 42 kept after No :: order 42 was deleted
1 OK, 1 FAIL (preizkusni postopki: 2)

Izhodna koda je 15: eno preverjanje ni uspelo. Če postopek CI preizkuse zažene pred wkl-office deliver, se tu ustavi in izdaja sploh ne nastane. Napaka ostane pri vas, preden pride do naročnika.

Kako to deluje? SDK vlogi zamenja. PowerShell zažene in oceni, VBA upravlja. Projektna datoteka navaja preizkusno funkcijo, ki vrne imena preizkusnih postopkov. Preizkusni postopek je javni Sub v standardnem modulu: obrazce odpira z DoCmd.OpenForm, kliče ukaze aplikacije in rezultate preverja z WklTest.Check. Pred vsakim MsgBox aplikacija vpraša WklTest.Answer. Zunaj preizkusa je odgovor prazen in pogovorno okno se pokaže kot vedno.

wkl-office test zgradi projekt in vsak preizkusni postopek posebej izvede v skritem Accessu, na kopiji podatkovne zbirke:

wkl-office test Orders.acproj
wkl-office test Orders.acproj -c Release -t accde --json

Izhodna koda 0 pomeni, da so vsa preverjanja uspela. Poleg kode 15 sta še 13, ko postopek preseže časovno omejitev, in 16, ko se Access med izvajanjem konča. Zraven nastane poročilo JUnit, ki ga prebere vsak običajen strežnik CI.

Nekaterih stvari test izrecno ne preverja: prave uporabe tipkovnice in miške, kot so vrstni red tabulatorja, fokus ali vleka in spust, in izvajanja v okolju Access Runtime. Access potrebuje tudi prijavljeno sejo Windows. Agent za gradnjo, ki teče kot storitev brez namizja, ne gradi; kako upravljate računalnik za gradnjo s prijavo, je naloga vašega sistema za gradnjo.

Del preverjanja gre celo brez Accessa. wkl-office check prebere izvorne datoteke, še preden se Access zažene. Tako je bilo videti na računalniku, na katerem je nastal ta zapis, na poskusnem projektu z nemškim imenom Kunden in z modulom, ki ima geslo v nizu za povezavo:

> wkl-office check Kunden.acproj
error [Sources] source/modules/basDaten.bas:5: A password (PWD=) is written into the source; it is readable for everybody who reads the repository. Let the application get it at run time.
Kunden: cannot be built (1 errors).

Izhodna koda je 2: izvorne datoteke niso veljavne. Brez tega modula se isti ukaz tam konča s kodo 3, ker na tem računalniku Accessa ni. Z obema odgovoroma skript ve, kaj storiti. Da je izpis v angleščini, je posledica računalnika: samostojno zagnana ukazna vrstica sledi jeziku sistema Windows, ta strežnik pa teče v angleščini. Kako preizkuse pripravite, opisuje stran Preizkušanje aplikacije.

Ob besedah »podpora umetne inteligence« veliko ljudi pomisli na orodje, ki napiše kodo VBA. Zanimivejše je drugo vprašanje: ali lahko orodje sodeluje v nadzorovanem razvojnem ciklu, ne da bi kdo izgubil nadzor?

• Že narejeno: vsak ukaz SDK teče v ukazni vrstici, konča se z opredeljeno izhodno kodo, z --json pa vrne objekt JSON. Z --format msbuild vrne vrstice s težavami, z datoteko in vrstico. wkl-office commit spremembe potrdi, ne potisne pa jih.
• Tehnično izvedljivo: agenti, kot sta OpenAI Codex in Claude Code, v mapi projekta izvajajo ukaze in berejo njihov izpis. Zato lahko kličejo check, build in test ter ovrednotijo izhodne kode tako kot strežnik CI. Posebna povezava za to ni potrebna, dokumentacija SDK pa tega ne opisuje kot funkcijo izdelka. Ker Access potrebuje sejo z namizjem, mora takšen agent teči tam, kjer teče Access.
• Odprto: agent bi lahko spremenil tudi besedilne izvorne datoteke obrazca. Ali je rezultat v Accessu videti in deluje prav, ne preveri ne check ne spajanje brez sporov. Spojeni obrazec je treba preizkusiti v Accessu – in to mora storiti človek.
• Ni obljubljeno: samostojen razvoj brez človeka. Tu ne napovedujemo nobene funkcije za agente.

Smiseln cikel je videti takole, zadnji korak pa ostane pri človeku – pri tistem, ki bo izdajo zagovarjal pred naročnikom:

Final_ResPopravljen2.accdb v projektu s SDK ne obstaja več. Aplikacija je repozitorij, ACCDB pa rezultat gradnje, ki ga lahko kdor koli znova izdela iz commita. Access ostaja to, kar je vedno bil: oblikovalnik, izvajalno okolje in dom kode VBA.

Vseh omejitev SDK ni odpravil. Gradnja in preizkusi potrebujejo nameščen Access v prijavljeni seji. Obrazci še vedno nastajajo v oblikovalniku. Spajanje brez sporov ne nadomesti preizkusa v Accessu. Trenutno je podprt Windows 11 z Accessom iz Microsoft 365 v 32- ali 64-bitni različici, Access od 2016 do 2021 pa ne. Kaj je v trenutni izdaji podprto, piše na strani izdelka. Kako začeti z lastno podatkovno zbirko, pokaže vadnica.

Access je lahko temelj poslovno kritičnih aplikacij. Naloga ni, da ga zamenjamo, ampak da okoli njega postavimo razvojni postopek, ki ga je mogoče preveriti in ponoviti.

Na koncu vprašanje, ki ga raje postavimo odkrito, kot da bi nanj odgovorili sami: ali je danes še sprejemljivo, da je izdaja poslovno kritične aplikacije Access odvisna od tega, katero datoteko je imel razvijalec nazadnje odprto? In kdo bo to razložil naročniku, ko gre kaj narobe?

Vemo, da marsikdo odgovori z da: aplikacija brez težav teče petnajst let, en sam človek jo pozna do zadnjega modula, denarja za prenovo ni. Mi mislimo drugače. Če se ne strinjate, nam pišite – takrat še posebej.

Ali aplikacijo Access naročniku še vedno predajate kot datoteko in na vprašanje »Katera različica teče pri naročniku?« ne morete odgovoriti s commitom? Potem je prvi korak pogovor o eni od vaših aplikacij: kako danes nastaja, kako jo preizkušate in izdajate ter ali ji ustreza pot prek izvorne kode in gradnje. K uporabi Office SDK vas to ne zavezuje.

Office SDK: stanje, zahteve in dogovor za pogovor