Upgrade van Test naar Produktie

[Wouter Rijnbende]

AlgemeenHoe we een 'normale' Upgrade moeten aanvragen, downloaden en uitvoeren staat beschreven in topic http://ha1.heartprofit.nl/profit/index.php?topic=27646.0.
Dit topic gaat dieper in op de situatie bij aanwezigheid van de module Profit-Base-Test.
Zoals we in bovenstaand genoemd topic hebben kunnen lezen hebben we bij de aanwezigheid van module Profit-Base-Test niet alleen Testbestanden en Produktiebestanden, maar is (kan) ook de programmatuur in de Test anders zijn dan in Produktie. We hebben dan niet meer alleen Test- en Produktiebestanden, maar meer een Test- en Produktieomgeving.

Andere ProcedureModule Profit-Base-Test wordt vnl. ingezet bij grotere en/of formelere implementaties, waarbij de klant zélf wil bepalen of de nieuwe funktionaliteit die met een Upgrade mee komt niet storend zijn voor hun bedrijfsspecifieke processen. Bedenk dat een Upgrade nieuwe funktionaliteit kan bevatten, welke we misschien eerst zélf willen testen alvorens de Upgrade wordt uitgevoerd. In theorie kan een Upgrade ook nieuwe 'bugs' bevatten, en zou u graag eerst willen testen of het toevoegen van orders, of inlezen van EDI gegevens nog werkt als u een Upgrade heeft uitgevoerd. Bedenk ook dat bij grotere maatwerk projekten zo af en toe de boel totaal op z'n kop kan worden gezet en soms ontwerpen als 'praatplaat' zijn opgezet om in praktijk te kunnen testen op het beoogde effekt. Dit soort zaken zijn mogelijk met de module Profit-Base-Test.

Bij Profit-Base-Test komt het er op neer dat Upgrades, afkomstig van Heart, (éérst) worden uitgevoerd in de Testomgeving. Daarna kunt U in die testomgeving testen wat u wilt, tot u ook van mening bent dat alle nieuwe funktionaliteit werkt en niet tot problemen leidt voor de dagelijkse handelingen die u in Profit uitvoert. Pas als u tevreden bent met die versie kunt u besluiten de versie zoals die aktief is in die Testomgeving over te zetten naar "Produktie". Dit kan in theorie direkt na uitvoering van een Upgrade in Test zijn, het kan ook een dag, een week, of soms zelfs maanden later zijn. U bepaalt!

Als we een Upgrade van Test- naar Produktie doen, gaan we met alle programmatuur zoals u die tot nu toe in Test heeft kunnen testen over naar Produktie; de Produktieomgeving wordt a.h.w. gelijk gemaakt aan de versie zoals die op dát moment aktief is in de Testomgeving. Welke versie dat is, doet er op dat moment niet toe; we hoéven niet specifiek iedere Upgrade over te zetten naar Produktie! en mogen ook Upgrades overslaan bij het doorzetten.

Een voorbeeld:
Op enig moment is de Produktieomgeving gelijk aan de Testomgeving en hebben we in beide bestandensets een versie aktief van oktober 2017 (stel Upgrade volgnummer 135).
Begin december vragen we een nieuwe upgrade aan (nr 136) en voeren deze uit in de Testomgeving. Uiteindelijk blijken we in december wat minder tijd te hebben om te testen dan gehoopt, wordt het januari, en willen we toch graag wat aanpassingen. In januari vragen we een nieuwe Upgrade aan (nr 137) en voeren deze uit (wederom in de Testomgeving). Dit geheel testen we, vinden we akkoord, en willen we omzetten naar Produktie. Op dat moment gaan we in Produktie in een stap van versie 135 naar versie 137.

Let op: Bij het overzetten van een Upgrade van Test- naar Produktie kunnen we alleen "alles" overzetten. Het is niet mogelijk om in januari te zeggen dat we de status van december willen overzetten naar Produktie. Het is alles, of niets. In Test zitten we nu op versie 137, en dié gaat over naar Produktie.

Merk op dat het overzetten van Test- naar Produktie intern helemaal niets af weet van Upgrades. Zo hoeft ook niet iedere wijziging op uw systeem met een Upgrade meekomen. Stel dat u nèt een Upgrade heeft uitgevoerd en ergens in het pakket een Geblokkeerde Funktie krijgt, dan kunnen wij in veel gevallen simpelweg volstaan door dat probleem op te lossen en enkel dié funktie (handmatig) op uw systeem te plaatsen, zonder dat iemand daarvoor uit Profit uit. Ook dit soort funkties zullen mee naar Produktie moeten.


ADS of native VFP DatabaseMet ingang van maart 2018 is de procedure voor het uitvoeren van de Upgrade in de ADS versie van Profit precies hetzelfde als in de VFP versie van Profit.

Hebben we geen Profit-Base-Test, dan voeren we de Upgrade uit in de Produktiebestanden en doen we daarna een Database Upgrade in de Testbestanden;
hebben we wél  Profit-Base-Test dan voeren we de Upgrade uit in de Testbestanden en zetten we op enig moment Test- over naar Produktie.

Tóch is er nog een groot verschil, en die wordt bepaald door de onderliggende database engine.

In het verleden hebben we ervoor gekozen om weliswaar Test- en Produktiebestanden te hebben, maar gold dit niet voor de Systeembestanden (SY en AP tabellen). Die keuze had op zich net zo veel voor- als nadelen.

Een paar voordelen:
* Als we een Gebruiker toevoegen, was deze meteen in Test- maar ook in Produktie bekend.
* Als we een Printerdriver wijzigden, konden we er meteen in Test mee testen.
* Als we een Variabele (Faktuur) Layout wijzigden, zagen we meteen het effekt op onze echte Faktuur in produktie.

Nadelen (welke soms ook als voordeel genoemd zijn):
* Een Gebruiker weet dat hij Test mag testen; hij past een Printerdriver aan, maakt een fout daarin, en meteen komt de Faktuur in de Produktie (live) omgeving er ook niet meer uit.
* Datzelfde geldt voor aanpassingen aan bijv. Variabele Layouts; die per direkt in de live bestandenset aktief worden.

Een heel groot nadeel van één set Systeembestanden is het feit dat we bij aanwezigheid van Profit-Base-Test eigenlijk een geheel gescheiden Test-/Produktie omgeving hadden, maar dat dit niet voor SY gold. Wilden we "Test" upgraden dan moest ook iedereen in Produktie eruit, immers, Systeembestanden waren altijd wel door een Gebruiker in Produktie in gebruik. In ADS is dit anders. Daar werken we formeel met een 'Data Dictionary' en 'tabellen' die daarbij horen. Iedere dataset hoort daarin 'compleet' te zijn, en een tabel kunnen we niet 'delen' over meerdere Data Dictionaries heen. Derhalve hebben we in ADS ook de Systeembestanden gescheiden voor Test- en Produktie! (hiervoor moeten de SY bestanden wel eerst worden geupload naar ADS).

Nb: 'kunnen' is dan een groot woord, want technisch krijgen we het wel voor elkaar, maar 'het hoort niet'. Bedenk dat we een Data Dictionary in ADS differentieel kunnen backuppen (ieder uur backuppen we alleen wat we gewijzigd hebben) en als die Data Dictionary geen 'Systeembestanden' bevat, zouden die niet gebackupped worden. Bedenk ook dat het uitvoeren van SQL Queries lastiger wordt als we data willen lezen uit een tabel die formeel niet aan de Data Dictionary gekoppeld is.

Ofwel:
VFP versie? -> dan altijd native VFP database = één set Systeembestanden voor zowel Test- als Produktie
ADS, maar SY tabellen niet over naar ADS -> dan ook native VFP database v.w.b. SY = één set Systeembestanden voor zowel Test- als Produktie
ADS én SY tabellen over naar ADS -> dan ADS Database = separate set Systeembestanden voor Test- en Produktie

V.w.b. het uitvoeren van Upgrades is konkreet het verschil dat we in ADS (zodra we met onze Systeemtabellen over zijn naar ADS) een Upgrade kunnen uitvoeren in de Testomgeving, terwijl de Gebruikers in Produktie gewoon door kunnen blijven werken.




1. Uitvoeren Upgrade van Heart naar TestomgevingDe eerste stap bij het uitvoeren van een Upgrade is het uitvoeren van de Upgrade van Heart. De methode voor deze Upgrade is niet veel anders dan het stappenplan zoals beschreven in http://ha1.heartprofit.nl/profit/index.php?topic=27646.msg46400#msg46400, hooguit moeten we de Upgrade van Heart nu in de Testbestanden uitvoeren waar we dit zonder Profit-Base-Test in de Produktiebestanden zouden doen.

Database-Upgrade in de andere bestandenset
Als de Upgrade is uitgevoerd (in Test) zijn we klaar.
We hoeven daarna niet meer om te schakelen naar de Produktiebestanden om daar een Database-Upgrade te doen, sterker nog, we kúnnen i.g.v. Profit-Base-Test niet omschakelen naar Produktie (die versie zullen we met een separate snelkoppeling op onze desktop moeten opstarten).  "Produktie" wordt aangepast als we Test- naar Produktie overzetten.

Kortom:
- we vragen een upgrade aan
- zodra Heart deze op de website heeft klaargezet downloaden we deze
- we voeren de upgrade uit in de Testomgeving
- we geven Profit weer vrij voor gebruik


2. Uitvoeren Upgrade van Test- naar Produktieomgeving

• Als we een Upgrade gaan overzetten van Test- naar Produktie, zullen wél alle Gebruikers uit Profit moeten. Zowel uit de Testbestanden als uit de Produktiebestanden. Allereerst moeten we er dus voor zorgen dat alle gebruikers uit Profit zijn. Desgewenst kan vanuit het scherm Raadplegen Gebruikers (Hoofdmenu-9-2-1) middels Shift-F6 een overzicht worden opgevraagd van de IP adressen waarop nog een Heart-Profit sessie draait. In een tekst bestandje worden de IP adressen getoond, voorafgegaan met het Userid welke op dat werkstation de Profitsessie open heeft staan. Wordt er geen Userid getoond, dan staat de gebruiker nog in het inlogscherm, en heeft ze geen Userid ingevuld.
  
  
  
  
  Iedereen, behalve u zelf uiteraard, zal Profit moeten afsluiten.
  
  
• Vergewis u zelf er van dat er voldoende diskruimte beschikbaar is om de Upgrade uit te kunnen voeren. Diskruimte kost tegenwoordig amper nog geld, en kijken we naar de grootte van het pakket Heart-Profit zelf, dan betreft dit hooguit enkele tientallen MB's. De Database zelf kan echter wel groot zijn en hangt af van hoe lang u al met Profit werkt, en bijv. hoeveel orders u op een dag maakt. Van iedere tabel die tijdens de Upgrade gemuteerd wordt, zal ook een backup worden gemaakt 'just in case'. In het ergste geval zal de grootte van uw database (inclusief de backupfiles) verdubbeld worden. Ach, eigenlijk kijkt bijna niemand meer naar diskruimte omdat we er toch voldoende van hebben, maar, start bijv. geen Upgrade op als uw database 20 GB data betreft, en er nog maar 1 GB aan diskruimte vrij is.
  
  
• Ga naar Menu "Upgrade Beheer" en start de Upgrade Test- naar Produktieomgeving op. T.t.v. het schrijven van deze tekst vindt U deze funktie via Hoofdmenu,9,9,8,2.
  
  
  
  
  Nb: Merk op dat de versie van de Systeemprogrammatuur in de Produktieomgeving ouder is dan maart 2018, er een iets anders tekst in dit menu kan staan bij menu-optie #2. U dient dan alsnog gewoon menuoptie #2 te selekteren. De upgrade waar u dan mee bezig bent zal ook een nieuwe Systeemprocedure aktiveren, en bij de eerst volgende Upgrade is het menu dan wel aangepast.
  
  
• Er volgt een iets ander Upgrade scherm als bij een normale Upgrade; deze funktie (SYUGTPUV) is separaat autoriseerbaar. Op deze manier bepaalt U wie er allemaal binnen uw bedrijf een Upgrade mag overzetten van Test- naar Produktie.
  
  
  
  
  
• Vul de rubriek "UBK files wissen" met Ja of Nee. "Ja" zal na de aanpassing van de struktuur van een tabel direkt de aangemaakte backupfile verwijderen. "Nee" laat deze backupfile staan. Defaultwaarde is "Nee", maar zodra diskruimte een rol gaat spelen is het mogelijk deze rubriek met "Ja" te vullen.
  Druk vervolgens op F1.
  
  
• Er volgt een melding die u vraagt het starten van de Upgrade te bevestigen.
  
  
  
  Druk op F1.
  
  
• Voor de zekerheid volgt er dan nog een tweede melding.
  
  
  
  Druk wederom op F1 om verder te gaan.
  
  
• Daarna begint het Upgrade proces. Tijdens dit proces worden diverse stappen doorlopen. Tijdelijke bestanden, Reorganisatie Programmatuur worden als eerste doorgekopieerd naar Produktie. Daarna vindt er (in Produktie) een Database Upgrade plaats. Als die stap klaar is wordt de resterende programmatuur gekopieerd. Het proces waar de Upgrade het langst mee bezig zal zijn is de Database Upgrade. Voorafgaand aan de Database Upgrade zal de Upgrade ook kontroleren of alle bestanden zijn vrijgegeven. Mocht dat niet het geval zijn, dan volgt er een foutmelding. U dient er daarna eerst voor te zorgen dat er geen gebruikers in Profit zitten, daarna zal de Upgrade opnieuw moeten worden opgestart.
  
  
• Zodra de Upgrade eenmaal gestart is, zal Profit formeel worden geblokkeerd voor opstarten. Dit, om te voorkomen dat áls u eenmaal alle gebruikers uit Profit heeft weten te krijgen, zij niet opnieuw Profit in kunnen terwijl u bezig bent met het uitvoeren van de Upgrade.
  
  
• Als de Upgrade klaar is, zal ze eindigen met een melding als:
  
  
  
  
  òf
  
  
  
  
  
  Na [Enter] zal Profit worden afgesloten, wordt eventueel resterende programmatuur gekopiëerd die het aktieve werkstation zelf in gebruik heeft (zoals de Classes) en zal Profit automatisch opnieuw worden opgestart. Merk op dat dit even een paar tellen kan duren. Na deze (automatische) herstart van Profit dient u opnieuw in te loggen. Let op dat u daarvoor hetzelfde Userid gebruikt als waarmee de Upgrade eerder werd opgestart. Het kan zijn dat na bevestigen van het wachtwoord er nog allerlei teksten onder aan het scherm verschijnen. Dit zal informatie kunnen zijn uit automatische konversies, die na het opnieuw opstarten van Profit automatisch worden uitgevoerd. Konversies zijn soms aan de orde, maar lang niet altijd. Als er konversies aan de orde waren en ze zijn uitgevoerd, volgt er een melding "Konversies uitgevoerd".
  
  
• Bij het afsluiten van Profit volgt een melding:
  
  
  
  Zodra de Upgrade wordt gestart is Profit (voor de overige werkstations) geblokkeerd voor opstarten. Middels F5 kunnen we deze blokkade opheffen, waarna Profit weer is vrijgegeven voor gebruik. We kunnen Profit ook afsluiten met Escape; dan blijft Profit voor de overige gebruikers geblokkeerd maar niet voor dit werkstation. Dit kan handig zijn als u bijv. na de upgrade nog iets wilt reorganiseren, en nog even niet wilt dat de gebruikers allemaal weer in het systeem kunnen.
  
  

Foutmeldingen:

Deze melding kan alleen voorkomen in de ADS versie van Heart-Profit. Zoals eerder uitgelegd geldt dat we dan te maken kunnen hebben met een separate bestandenset voor de Systeemdatabase. Als we maar één set Systeembestanden hadden, dan gold dat als we in Test een Upgrade hadden gedaan, we in Produktie al meteen de Releasenotes konden zien van de Upgrade die in Test was uitgevoerd. Eigenlijk helemaal fout, immers, de Upgrade hoefde nog niet overgezet te zijn naar Produktie, en toch zagen we daar die Releasenotes al staan. Helaas, we hadden maar één bestandenset voor SY. In ADS hebben we er dus twee. Dit houdt ook in dat als we een Upgrade overzetten van Test- naar Produktie,  Profit de Releasenotes (de data) zal moeten doorkopiëren naar Produktie; we willen immers ook in Produktie onze Releasenotes kunnen opvragen. Dit 'doorkopiëren' is dan alleen aan de orde als de Systeemtabellen ADS tabellen zijn.

Omdat ADS is opgezet als een soort 'hybride' systeem, waarbij we per tabel kunnen aangeven of deze wel/niet over is naar ADS, krijgen we nu te maken met een situatie waarbij er ineens meerdere kombinaties kunnen ontstaan.

Een tabel is VFP in Test, en VFP in Produktie.
Een tabel is ADS in Test, maar VFP in Produktie.
Een tabel is VFP in Test, maar ADS in Produktie.
Een tabel is ADS in Test en ADS in Produktie.

Dit zouden 4 afzonderlijke situaties zijn die door de Upgrade zouden moeten worden afgevangen. Kost niet alleen tijd om te maken, maar ook tijd om uit te leggen aan de Gebruiker. En... de situaties kúnnen weliswaar optreden, maar in praktijk zal het bijna niet aan de orde zijn. De Upgrade beperkt zich tot de situaties waarbij de betreffende tabellen òf in beide bestandensets VFP tabellen zijn òf in beide bestandensets ADS tabellen zijn. Het per tabel instellen of deze VFP of ADS is, is oorspronkelijk enkel bedoeld om alvast met een beperkt aantal tabellen in ADS te kunnen testen; uiteindelijk zal het doel zijn om zo snel mogelijk met alle tabellen over te stappen op ADS, waarna de genoemde kombinaties in praktijk niet meer zullen voorkomen.

Zodra een tabel in de ene bestandenset ADS is en in de ander VFP (of andersom) volgt deze melding.

Als deze melding volgt kan de Upgrade niet worden uitgevoerd. De tabel zal (in de andere bestandenset) óók naar ADS moeten worden ge-upload.
(of weer van ADS terug moeten worden gezet naar een VFP tabel).

ADS - Automatische Upload nieuwe tabellen naar ADSIn ADS kunnen we per tabel aangeven of deze wel/niet over is naar ADS. Zolang een tabel niet wordt geupload naar ADS zal Profit v.w.b. die tabel de native VFP tabel aansturen. Dit systeem is ontwikkeld om alvast met een paar tabellen over te kunnen gaan naar ADS om tijdens een implementatie van ADS alvast wat te kunnen testen, zonder direkt met alle tabellen over te gaan naar ADS. Uiteindelijk is het doel dat de ADS database de VFP database vervangt en dat we met alle tabellen overgaan naar ADS.

Bij aanvang van de Upgrade in ADS zal Profit kontroleren of u met alle tabellen over bent naar ADS. Indien dat het geval is, zullen ook eventueel nieuwe tabellen die met een Upgrade mee komen automatisch naar ADS worden geupload, zodat ook ná de Upgrade de status blijft "uw bent met alle tabellen over naar ADS". Als er (bij aanvang van uw Upgrade) ook maar één tabel is die niet is overgezet naar ADS, dan zullen ook de nieuwe tabellen die met een Upgrade meekomen niet naar ADS worden geupload. Die worden dan toegevoegd aan het rijtje tabellen welke nog "met de VFP DBF" werken.