5 tips voor effectievere applicatie-releases

Door Tim Bond, Productmanager

Low-code-ontwikkelingsteams besteden aanzienlijke tijd en energie aan het bepalen van de scope en het ontwikkelen van de volgende set functies voor hun low-code-applicaties. Het ontwikkelen van robuuste apps die de verwachte resultaten opleveren is uiterst belangrijk. Maar het proces van het verplaatsen van de applicatie van een ontwikkelomgeving, via een testomgeving, naar een productie- of live-omgeving is al te vaak een achtergedachte.

Het hebben van een goed doordacht en helder gecommuniceerd plan voor het vrijgeven van een applicatie naar een productieomgeving is het allerbelangrijkste onderdeel van een go-live. Hier zijn een aantal punten waar je over na moet denken voordat je een release uitvoert:

• Wanneer begint de release en hoe lang gaat dit duren?

  Werk samen met de belanghebbenden om een moment te bepalen waarop ze er zo min mogelijk last van hebben. De duur is moeilijk te voorspellen; hoe vaker je het doet, hoe beter je dit zult kunnen inschatten. Beloof minder dan je aankunt en presteer boven verwachting ten opzichte van je schatting.

• Hoe worden de eindgebruikers beïnvloed tijdens de release?

  Hoe goed releases en geplande downtime ook vooraf worden gecommuniceerd, je moet ervan uitgaan dat een gebruiker in de applicatie zal zijn als dat kan. Dit is misschien geen probleem, maar als dat wel zo is, kun je overwegen om de toegang tot de applicatie tijdens de onderhoudsperiode te verbieden.

• Wie is er verantwoordelijk voor elke stap van het releaseproces?

  Een gedetailleerd plan moet worden gedeeld met het team van personen dat de stappen uitvoert. Neem de tijd om het plan samen te bespreken en benadruk dat er geen domme vragen zijn als het gaat om duidelijkheid over het releaseplan. Zorg ervoor dat elk individueel lid de juiste toegangsrechten heeft om de stappen uit te voeren die aan hem/haar zijn toegewezen.

• Welke nieuwe verbindingen/integratiepunten met applicaties van derden worden er geïntroduceerd?

  De eerste keer dat een verbinding of integratie live gaat, zal er in het achterhoofd van het team altijd wat onzekerheid zijn. Een onjuiste API-sleutel of geblokkeerd netwerkverkeer kan roet in het eten gooien. Ontwikkelaars moeten er een punt van maken om dit bij het team aan te kaarten, zodat er op de juiste manier rekening kan worden gehouden met de nieuwe verbinding.

• Als de release niet succesvol is, wat is dan het terugdraaiplan?

  Dit is nooit het verwachte of gewenste resultaat, maar het vooraf hebben van een plan zal het team door een stressvolle situatie leiden.

Je krijgt maar één kans om een succesvolle livegang in één keer te bereiken. Ik stel voor om een test- of stagingrelease te gebruiken als generale repetitie voor de productie om eventuele problemen op te lossen.

Wat betreft de Jitterbit App Builder-applicatiereleases: uw ontwikkelaars stellen vanuit de ontwikkelomgeving een release samen, downloaden het releasebestand (dat we een LP-bestand noemen) en uploaden dit naar de doelomgeving om het daar te installeren. Er zijn een aantal veelvoorkomende risico’s die u goed moet controleren voordat u de release samenstelt en in de productieomgeving installeert:

• Tabelinstallatieopties:

  Meestal zijn er fysieke tabellen opgenomen in je release. Elke tabel heeft een instelling voor de installatie-optie die bepaalt hoe de in de tabel opgeslagen gegevens worden behandeld wanneer de release wordt gemaakt en vervolgens wordt geïnstalleerd in een doelomgeving. Dit is een krachtige functie, maar deze moet met voorzichtigheid worden gebruikt. Je wilt absoluut kwalitatieve productiegegevens niet overschrijven met alle gegevens die ontwikkelaars aanmaken. Je kunt meer te weten komen over deze opties op onze Documentatiepagina voor een releasepackage bouwen.

• Rollen:

  Toegang tot een pagina, evenals de ingebouwde functionaliteit voor het maken, bewerken en verwijderen van gegevens die aan een gebruiker worden getoond op een pagina, wordt gedetailleerd beheerd in de logische laag. Telkens wanneer een ontwikkelaar de rollen van een bedrijfsregel wijzigt of een nieuwe bedrijfsregel toevoekt aan een pagina, kan dit een onbedoeld effect hebben op het vermogen van een bepaalde gebruikersgroep om de pagina te bereiken. Het aanmaken van een testgebruiker voor elke gebruikersgroep en het uitvoeren van regressietests voor rollen is een uitstekende gewoonte vóór elke release naar productie. Dit helpt je om de gevreesde e-mail van je eindgebruiker met de tekst “Ik kan niet meer bij deze pagina” de dag na een release te voorkomen. Bekijk deze documentatiepagina voor meer informatie over privileges en rechten.

Controleer telkens wanneer je je Jitterbit App Builder-applicatie wilt vrijgeven de vrijgevingssjabloon grondig. Je mag alleen die onderdelen van de applicatie vrijgeven die zijn gewijzigd en die je daadwerkelijk in productie wilt nemen.

In je releasetemplate kun je kiezen uit deze verschillende componenten. Je kunt uiteraard een hele applicatie releasen die alle gegevensbronnen, logica en pagina's bevat. Of als je wijziging kleiner van opzet was, kun je slechts één enkele pagina of één enkele bedrijfsregel releasen en die kleinere componenten naar productie brengen, waarbij de rest van de applicatie ongewijzigd blijft. Deze flexibiliteit in de releaseproces stelt uw ontwikkelingsteam in staat om gemakkelijker te reageren op kritieke problemen die zich voordoen tijdens het werken aan de grotere verzoeken.

De applicatiecomponentfunctie vergroot de flexibiliteit, snelheid en controle over het software-implementatieproces, waardoor het een krachtige tool is in omgevingen die frequent updates en minimale downtime vereisen. De belangrijkste voordelen voor uw ontwikkelingsteams zijn:

• Modulaire updates:

  Hiermee kunnen specifieke componenten van een applicatie onafhankelijk worden bijgewerkt, waardoor code-afhankelijkheden worden verminderd.

• Minimale downtime:

  Alleen de gewijzigde componenten worden bijgewerkt, wat zorgt voor soepelere upgrades.

• Grotere ontwikkelingsbehendigheid:

  Teams kunnen snel updates of patches uitbrengen voor afzonderlijke componenten, wat de reactietijd verhoogt.

Lees meer over Jitterbit App Builder, of de een krachtige reeks AI-functies die binnenkort beschikbaar komt in App Builder 4.0.