Kun je eindelijk echte versiebeheer gebruiken met een FileMaker-systeem?

Als je ooit een FileMaker-oplossing met meer dan één ontwikkelaar hebt beheerd, weet je van de ellende. Twee ontwikkelaars openen hetzelfde bestand, beide wijzigen dezelfde script, en één van hen verliest zijn wijzigingen wanneer het bestand wordt opgeslagen. Er is geen diff, geen blame, geen pull request — alleen een binair bestand dat wel of niet jouw wijziging bevat. Vergelijk dat met een webontwikkelaar die een pull request kan openen, precies kan zien welke 4 regels in een JavaScript-functie zijn gewijzigd, een collega ervan kan laten reviewen, en automatische tests kan uitvoeren voordat het wordt gemerged. FileMaker-teams hebben meestal zonder al dat moeten leven.

FileMaker 2026 verandert de praktische realiteit hier door het veel gemakkelijker te maken om de structuur en scripts van een oplossing als platte XML buiten FileMaker zelf te bewerken. Dit klinkt als een klein, technisch detail. In de praktijk is het het ontbrekende stuk dat FileMaker-teams eindelijk in staat stelt om aan te sluiten op dezelfde version control, code review en CI/CD-workflows die elk ander softwareteam als vanzelfsprekend beschouwt.

Waarom is version control altijd moeilijk geweest in FileMaker?

Een FileMaker-bestand (.fmp12) is een binaire container. Het bevat je gegevens, je schema, je layouts, je scripts en je value lists allemaal in één bestand. Dat is geweldig voor eenvoud bij inzetting — één bestand, één ding om een back-up van te maken — maar het is verschrikkelijk voor het volgen van wijzigingen in de loop van de tijd.

Git, Subversion en elk ander versiebeheersysteem zijn gebouwd rond het vergelijken van tekstbestanden regel voor regel. Ze kunnen je vertellen "deze functie is gewijzigd van retourneer X naar retourneer Y." Ze kunnen twee binaire .fmp12-bestanden niet zinvol vergelijken. Dus FileMaker-teams hadden historisch twee slechte opties:

• Geen echte version control — alleen bestanden een naam geven als Solution_v12_FINAL_reallyfinal.fmp12 en hopen dat niemand de verkeerde overschrijft.
• Hulpmiddelen van derden (zoals de Data Migration Tool gecombineerd met handmatige wijzigingslogboeken, of producten zoals Git-integraties van de FileMaker-gemeenschap) die diffing benaderen door scripts als tekst te exporteren, maar met echte friction en gedeeltelijke dekking — layouts en schema waren vaak onbereikbaar.

Hoe dan ook, code review — een tweede ontwikkelaar die een voorgestelde wijziging daadwerkelijk leest voordat deze live gaat — was zeldzaam. De meeste bugs werden in QA-testing onderschept (als je geluk had) of door een klant die iets kapot rapporteerde in productie (als je geen geluk had).

Wat verandert FileMaker 2026 eigenlijk?

FileMaker 2026 maakt het veel gemakkelijker om de structuur van een oplossing — scripts, layout-objecten en gerelateerde metadata — als XML-bestanden te exporteren die buiten de .fmp12-container leven. In plaats van één ondoorzichtig binair bestand krijg je een map met leesbare, gestructureerde tekstbestanden die aan de werkelijke objecten in je oplossing zijn gekoppeld.

Deze enkele verschuiving ontsluit drie dingen die ontwikkelaars op andere platforms al jaren hebben:

1. Echte diffs. Je kunt zien dat de If-voorwaarde van een script is gewijzigd van controleren op Status = "Open" naar Status ≠ "Closed" — niet alleen dat "het bestand is gewijzigd."
2. Echte code review. Een pull request kan precies laten zien wat een ontwikkelaar heeft gewijzigd, en een reviewer kan goedkeuren of wijzigingen aanvragen voordat het in de gedeelde oplossing wordt gemerged.
3. Echte automatisering. Omdat de XML gewoon tekst is, kan deze in Git worden ingecheckt, gescand door scripts en gebruikt als invoer voor geautomatiseerde bouw- of testpijplijnen — de bouwstenen van CI/CD.

Hoe zou dit eigenlijk werken in een Git-workflow?

Hier is een realistisch patroon dat een FileMaker-team zou kunnen opzetten:

1. Exporteren. Na het aanbrengen van wijzigingen in FileMaker exporteert een ontwikkelaar de betreffende scripts/layouts als XML in een aangewezen map in de project-repository.
2. Commit. Die XML wordt in Git ingecheckt met een zinvol bericht — "Fix invoice rounding logic in CalculateTotal script" — net als elke andere codewijziging.
3. Pull request. De ontwikkelaar opent een pull request. Een teamgenoot beoordeelt de werkelijke diff van de XML, ziet dat een afrondingsfunctie van Round naar Truncate is gewijzigd, en vraagt ernaar voordat hij goedkeurt.
4. Merge en opnieuw importeren. Zodra het is goedgekeurd, wordt de wijziging in de hoofdbranch gemerged, en wordt de XML opnieuw geïmporteerd (of wordt de onderliggende .fmp12-update toegepast) op het gedeelde ontwikkelingsbestand.
5. Geautomatiseerde controles. Een CI-pijplijn kan lichte validatie uitvoeren op elke pull request — controleren op naamgevingsnormaloverschrijdingen, zwakke scripts of ontbrekende opmerkingen — voordat een menselijke reviewer er zelfs naar kijkt.

Dat is een echt ander manier van werken dan "degene die het bestand nu open heeft, wint."

Betekent dit dat FileMaker-ontwikkeling precies hetzelfde wordt als webontwikkeling?

Niet helemaal, en het is de moeite waard om eerlijk te zijn over de grenzen.

• Gegevens worden niet op deze manier versiebeheerd. Dit gaat over structuur — scripts, layouts, schema — niet over je records. Je gegevens bevinden zich nog steeds in het .fmp12-bestand (of je gescheiden gegevensbron) en hebben hun eigen back-up- en migratiefase nodig.
• Mergen is niet altijd triviaal. Twee ontwikkelaars die parallel dezelfde script bewerken, vereist voorzichtigheid. XML maakt conflicten zichtbaar — het doen ze niet verdwijnen. Je hebt nog steeds duidelijke teamconventies nodig over wie eigenaar is van welke module of scriptgroep tijdens actieve ontwikkeling.
• Je hebt nog steeds een FileMaker-bewuste pijplijn nodig. Een generieke CI-runner weet niet hoe een FileMaker-oplossing moet worden "gebouwd" zoals het weet hoe je Java moet compileren. Teams die dit aannemen, hebben aangepaste hulpmiddelen nodig — scripts die weten hoe XML consistent moet worden geïmporteerd/geëxporteerd — dit is exact het soort integratiewerk dat een FileMaker-ontwikkelings­partner eenmaal zou instellen, in plaats van iets wat elke klant opnieuw uitvindt.

Wat kun je eigenlijk doen als je vandaag een FileMaker-systeem draait?

Je hoeft je workflow niet op de dag waarop dit wordt uitgebracht volledig te reorganiseren. Maar het is de moeite waard om voor te plannen, vooral als:

• Meer dan één ontwikkelaar werkt actief in dezelfde oplossing.
• Je incidenten hebt gehad waarbij een wijziging iets in productie brak en niemand kon zeggen wat precies is gewijzigd of waarom.
• Je voorbereidt om buitenlandse ontwikkelaars of een bureau in te voeren en een veiliger manier wilt om hun wijzigingen vóór de inzetting te controleren.
• Je al Git gebruikt voor andere onderdelen van je stack (een bijbehorende web-app, een API-laag, scripts) en wilt dat je FileMaker-laag in dezelfde discipline past.

Een korte checklist om je voor te bereiden:

• Bevestig welke FileMaker-versie je team draait en of een upgradepad naar 2026 dit jaar realistisch is.
• Identificeer je riskantste scripts — degenen die facturering, salarisbeheer of klantgegevens aanraken — als eerste kandidaten voor gestructureerde versiebeheer.
• Stel een Git-repository in (zelfs een eenvoudige privé) specifiek voor geëxporteerde XML, gescheiden van je back-ups van gegevensbesten.
• Ga als team akkoord met een lichte pull-request-gewoonte: geen directe wijzigingen in gedeelde scripts zonder een tweede paar ogen.
• Praat met je FileMaker-ontwikkelaar of partner over het bouwen van de export/import-hulpmiddelen die dit bindt — dit is het deel dat echte setup vergt, niet alleen het inschakelen van een functie.

Veelgestelde vragen

Vervangt dit regelmatige back-ups van mijn FileMaker-bestand? Nee. XML-export/versiebeheer dekt structuur — scripts, layouts, schema — niet je live gegevens. Je hebt nog steeds je normale back-up- en noodherstelplan nodig voor het .fmp12-bestand of je gegevensbron.

Kan ik GitHub of GitLab rechtstreeks gebruiken? Ja — zodra de structuur van je oplossing als XML is geëxporteerd, zijn het alleen tekstbestanden zoals elke andere codebase, dus standaard Git-hosting werkt prima.

Moet ik mijn hele oplossing herbouwen om hiervan te profiteren? Nee. Je kunt het stap voor stap aannemen, te beginnen met de scripts of modules die het meest gevoelig zijn voor conflicten of bugs, en vandaar uitbreiden.

Is dit alleen nuttig voor grote teams? Het helpt het meest waar meerdere mensen dezelfde oplossing aanraken, maar zelfs een solo-ontwikkelaar profiteert ervan om een echte wijzigingsgeschiedenis te hebben en de mogelijkheid om een specifieke scriptwijziging terug te draaien in plaats van een hele bestandsversie.

Waar laat dit je achter?

Echte versiebeheer is altijd een stille, langdurige hiaat in FileMaker-ontwikkeling geweest in vergelijking met andere platforms — niet omdat FileMaker-ontwikkelaars het niet interesseerde, maar omdat de hulpmiddelen echt niet waren. De XML-gebaseerde structuurexport van FileMaker 2026 sluit een betekenisvol deel van die hiaat, maar het omzetten in een werkende CI/CD-pijplijn vergt nog steeds doelbewuste setup: repository-structuur, export/import-hulpmiddelen en teamconventies die aansluiten bij hoe je bedrijf daadwerkelijk wijzigingen verstuurt.

Als je een aangepaste FileMaker-oplossing draait en het probleem "welke versie is de echte" herkent, is dit een goed moment om met een ontwikkelings­partner te gaan zitten en uit te stippelen hoe een Git-gebaseerde workflow eruit zou zien voor je specifieke systeem — of dat nu betekent dat je een bestaande FileMaker-oplossing strakker maakt, deze via API's met andere tools verbindt, of de ondersteunende scripts bouwt die versiebeheer en code review een dagelijkse gewoonte maken in plaats van een mooi idee. Loggix werkt met FileMaker-systemen, aangepaste webapplicaties en de integraties ertussen, en kan je helpen uitzoeken waar gestructureerd versiebeheer eigenlijk het eerst rendement zou opleveren.