"Online" of "Offline" development?

[Peter Wagemans]

De tijd dat we alleen maar veldjes konden aanmaken als de database lokaal stond, is gelukkig lang voorbij. De structuur ( het schema ) van een file kan sinds FileMaker Pro 7 aangepast worden terwijl de bestanden gehost worden door een server.

Een database aanpassen terwijl andere mensen ermee werken kan nogal wat problemen veroorzaken. Een paar voorbeelden:

• Een aangepaste layout bewaren zorgt voor grote verwarring voor diegenen die net aan het werken zijn op die layout, doordat velden plots verspringen of zelfs verdwijnen, en tabbladen zichzelf naar de default tab resetten.
• Een aangepast script zorgt ervoor dat de flow van 1 of een combinatie van scripts fout gaat voor diegenen die dat script net aan het uitvoeren waren.
• Door aan de velddefinities te werken, worden alle auto-enter seriele nummers geblokkeerd, waardoor zowel manuele als scriptmatige aanmaak van records niet meer mogelijk is door gebruikers, en scripts helemaal fout lopen, met zelfs dataverlies als gevolg.

Er valt dus wel één en ander te zeggen voor "offline" development, hoewel "online" development veel gemakkelijker is.

Er komt heel wat bij kijken als je offline wil werken en dan achteraf alle actuele gegevens wil overhalen. De kans dat het daar mis gaat, is zelfs substantieel.  Dus deze keuze is niet zo voor de hand liggend.

Ik ben benieuwd hoe jullie hiermee omgaan. Als FileMaker developer ontwikkel ik in verschillende omgevingen. Sommige klanten hebben maar een paar gebruikers, en we verwittigen iedereen dat er aan de database gewerkt wordt. Soms is er development-omgeving en een productie-omgeving, en heel soms zelfs een test-omgeving bij de corporate klanten. Soms is er zelfs geen server. Daarom is deze peiling "multiple choice".

Ik nodig jullie ook uit om te reageren, en elke reactie is waardevol.

[menno]

Ik gebruik alle manieren, die je hier hebt voorgesteld, plus bij een aantal klanten gebruik ik het data-separation model.

In die datastructuur wijzigt bijna nooit iets, er worden vrijwel uitsluitend tabellen en kolommen toegevoegd. De slimme boel zit in aparte interface-bestanden voor de gebruikers en wat andere bestanden die allemaal geen data bevatten. Denk aan de gebruikers-interface, een afdrukbestand, een overzichten bestand, koppeling met transporteurs etc. etc. zit allemaal in aparte bestanden, zonder data. De instellingen en de data zitten in 2 aparte bestanden, eentje met de bedrijfsdata en een met alle instellingen, accounts, keuzelijsten etc. etc.

Het mooie hiervan is dat ik zowel online als offline kan ontwikkelen. Heel af en toe online om te spelen met de live-gegeven, maar meestal offline om van alles uit te halen en diepgaand te testen. Een enkele keer moet er iets in de structuur gebreuren en dat gebeurt dan wanneer er niemand aan het werk is of wanneer er slechts weinig gebruikers zijn (heb ook 24/7 klanten, dan ontkom je daar niet aan)

Het resultaat zet ik dan letterlijk in 1 of 2 minuutjes neer op de server: server down en simpelweg de periferieke bestand(en) vervangen. Server weer starten. De klant is nooit langer dan 5 minuten uit de lucht geweest. De laatste conversie van de data-bestanden is geweest bij de overstap van FM11 naar FM12.

[peterS]

Ik ontwikkel alleen op een aparte dev server. Dan gaat het naar een test omgeving bij de klant, daarna naar productie server.
Bij uitzondering en haastklussen waarbij geen verandering in de data file nodig is, doe ik een upload van een UI file buiten kantooruren, direct naar productie (maar dit is altijd in overleg met de klant).

Data separation model, met uitgebreide scripts om data van de live server of laatste backup te importeren naar een nieuwe versie als er een verandering in de data file was.  (stamt nog uit de tijd van voor FMDatamigration).

Als ik nu iets nieuws bouw (nieuwe FMP files), dan zonder enige twijfel met FMDatamigration. Noodzaak van data separation wordt hierdoor ook minder.

 

[Marsau]

Onderhoudsmatige, kleine ingrepen met kleine foutkans of waarbij een eventuele fout weinig consequenties heeft, doe ik veelal gewoon live. 

Meer substantiële ingrepen, nieuwe functionaliteit werk ik uit in een development omgeving. Soms ook wel eens geheel offline omwille van snelheid en performance, maar vind het prettig om bij langduriger development werk ook over robuuste backups te kunnen beschikken. 

Als de operatie het kan hebben, kan je overwegen om bepaalde, meer complexe  ontwikkelwerkstukjes ook direct live uit te voeren. De ontwikkelsnelheid is dan ongeëvenaard. Door directe terugkoppeling van gebruikers kan je heel snel fouten repareren of het ontwerp bijsturen, zonder dat je een aparte testfase nodig hebt. 

Vroeger gebruikte ik scripts om een systeem te legen en opnieuw vanuit een live-systeem te vullen. Dat is nooit een vlekkeloos beheersbaar proces gebleken. Het koste ook erg veel tijd. Migratie is redelijk pijnloos geworden met de migratie-tool, al blijft het gehannes met externe containers. 

 

[Peter Wagemans]

18 minuten geleden zei Marsau:

Migratie is redelijk pijnloos geworden met de migratie-tool, al blijft het gehannes met externe containers. 

Hoe bedoel je? Managed containers? Waar ervaar je problemen?

[Marsau]

Ja, sorry. Ik bedoel containers met externe opslag. 

[Peter Wagemans]

Initieel dus wel wat reactie, een week later is er weinig meer gebeurd.

Zoals ik verwachtte, wordt onze "deployment" strategie in veel gevallen bepaald door de situatie. Er hebben dus verschillende mensen voor meer dan 1 antwoord gekozen.

FMDatamigration is wat technischer, en ik denk dat de drempel hoog is voor sommige mensen, om hiernaar over stappen vanuit een "import migratie".

De keuzes zijn wat gespreid, met import en FmDatamigration op kop. Maar het aantal mensen die geantwoord hebben is eigenlijk laag. Met zo weinig antwoorden, is er eigenlijk te weinig om meer te doen dan wat gissingen te maken.

[Ari]

Ik gebruik sinds kort de 360works Deploy tool en dat werkt als een zonnetje..

https://360works.com/filemaker-deploy-versions/

[jw]

Ik werk meestal online. Maar dan betreft het meestal kleine aanpassingen. Ik zorg dat de meeste functionaliteit via scripts verloopt. Zo kan ik dan namelijk scripts dupliceren, aanpassen, testen en over het originele script heen plakken. Ik maak overigens een script per onderwerp of per tabel. Een script bevat dan ook een hele reeks functies die ik via een parameter aanstuur.

Vaak maak ik een kopie van de database op de server en test daarin dan de nieuwe scripts uit.

Maar ik heb ook oplossingen voor het overzetten van alle data ( alle tabellen dus ) met een druk op de knop. Met keuzelijstjes doe ik weinig en ik hernoem velden zo min mogelijk.