|
Title: Upgrade van Test naar Produktie Post by: Wouter Rijnbende on March 06, 2018, 10:35:39 am Algemeen Hoe 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 Procedure Module 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 Database Met 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 Testomgeving De 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
Foutmeldingen: (http://www.heartprofit.com/www/transfer/graphics/rnotes/2018/syugtpuv180306d.png) 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 ADS In 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. |