Low-code ontwikkelteams besteden veel tijd en energie aan het bepalen en ontwikkelen van de volgende set features voor hun low-code applicaties. Het ontwikkelen van robuuste apps die de verwachte resultaten leveren, is van het grootste belang. Maar het proces van het verplaatsen van de applicatie van een ontwikkelomgeving, via een testomgeving, naar een productie- of live-omgeving is te vaak een bijzaak.
Een goed vastgesteld en goed gecommuniceerd plan hebben voor het vrijgeven van een applicatie naar een productieomgeving is het allerbelangrijkste onderdeel van een go-live. Hier zijn een paar dingen waar u over na moet denken voordat u een release uitvoert:
-
Wanneer begint de release en hoe lang duurt het?
Werk samen met de stakeholders om een moment te bepalen waarop ze minimaal worden beïnvloed. De duur is moeilijk te voorspellen: hoe vaker u het doet, hoe beter u dit kunt inschatten. Beloof minder en lever meer dan verwacht op uw schatting.
-
Welke gevolgen heeft de release voor eindgebruikers?
Ongeacht hoe goed u releases en geplande downtime van tevoren communiceert, moet u ervan uitgaan dat een gebruiker in de applicatie zit als dat mogelijk is. Dit is misschien geen probleem, maar als dat wel zo is, kunt u overwegen om de toegang tot de applicatie te verbieden tijdens de onderhoudsperiode.
-
Wie is verantwoordelijk voor welke stap in het releaseproces?
Een gedetailleerd plan moet worden gedeeld met het team van mensen dat de stappen uitvoert. Neem de tijd om het plan samen te bekijken en benadruk dat er geen domme vragen zijn als het gaat om duidelijkheid over het releaseplan. Zorg ervoor dat elk individu de juiste toegang heeft om de stappen uit te voeren die aan hem/haar zijn toegewezen.
-
Welke nieuwe verbindingen/integratiepunten met applicaties van derden worden geïntroduceerd?
De eerste keer dat een verbinding of integratie live gaat, zal er wat onzekerheid in het achterhoofd van het team zitten. Een onjuiste API-sleutel of geblokkeerd netwerkverkeer kan roet in het eten gooien. Ontwikkelaars moeten dit punt maken voor het team, zodat de nieuwe verbinding op de juiste manier kan worden gepland.
-
Wat is het back-upplan als de release niet succesvol is?
Dit is nooit de verwachte of gewenste uitkomst, maar door vooraf een plan te hebben, kan het team door een stressvolle situatie heen.
Je krijgt maar één kans om bij de eerste poging een succesvolle go-live te hebben. Ik raad aan om een test- of stagingrelease te gebruiken als een dry run voor productie om eventuele problemen op te lossen.
Als het om de Jitterbit gaat App Builder applicatie releases, uw ontwikkelaars maken een release van de ontwikkelomgeving, downloaden het releasebestand (we noemen het een LP-bestand) en uploaden het naar de doelomgeving om te worden geïnstalleerd. Er zijn een paar veelvoorkomende risico's die u dubbel moet controleren voordat u de release maakt en installeert in productie:
-
Opties voor tabelinstallatie:
Meestal heb je fysieke tabellen in je release. Elke tabel heeft een installatieoptie-instelling die bepaalt hoe de gegevens die in de tabel zijn opgeslagen, worden verwerkt wanneer de release wordt gemaakt en vervolgens wordt geïnstalleerd in een doelomgeving. Dit is een krachtige mogelijkheid, maar moet voorzichtig worden gebruikt. Je wilt absoluut geen kwaliteitsproductiegegevens vervangen door alle gegevens die ontwikkelaars maken. Je kunt meer te weten komen over deze opties op onze Maak een documentatiepagina voor een releasepakket.
-
Rollen:
Toegang tot een pagina, evenals de native create/edit/delete-mogelijkheden van gegevens die aan een gebruiker op een pagina worden getoond, worden gedetailleerd beheerd in de logische laag. Elke keer dat een ontwikkelaar de rollen van een bedrijfsregel wijzigt of een nieuwe bedrijfsregel introduceert op een pagina, kan dit een onbedoeld effect hebben op het vermogen van een bepaalde gebruikersgroep om de pagina te bereiken. Het maken van een testgebruiker voor elke gebruikersgroep en regressietesten voor rollen is een goede gewoonte vóór elke release in productie. Dit zal u helpen de gevreesde e-mail "Ik kan deze pagina niet meer bereiken" van uw eindgebruiker de dag na een release te vermijden. Bekijk deze documentatiepagina voor meer informatie over rechten en machtigingen.
Elke keer dat je je Jitterbit wilt vrijgeven App Builder applicatie, bekijk de release template. U moet alleen de componenten van de applicatie vrijgeven die zijn gewijzigd en die u wilt vrijgeven aan productie.
In uw releasetemplate kunt u deze verschillende componenten kiezen. U kunt natuurlijk een volledige applicatie vrijgeven die alle gegevensbronnen, logica en pagina's bevat. Of als uw wijziging op een kleinere schaal was, kunt u slechts één pagina of één bedrijfsregel vrijgeven en die kleinere componenten vrijgeven aan productie, terwijl de rest van de applicatie blijft zoals het is. Deze flexibiliteit in de vrijgaveproces zorgt ervoor dat uw ontwikkelteam gemakkelijker kan reageren op kritieke problemen die zich voordoen tijdens het werken aan grotere aanvragen.
De applicatiecomponentfunctie verbetert de flexibiliteit, snelheid en controle over het software-implementatieproces, waardoor het een krachtig hulpmiddel is in omgevingen die frequente updates en minimale downtime vereisen. De belangrijkste voordelen voor uw ontwikkelteams zijn:
-
Modulaire updates:
Hiermee kunnen specifieke componenten van een applicatie onafhankelijk van elkaar worden bijgewerkt, waardoor de codeafhankelijkheden worden verminderd.
-
Minimale uitvaltijd:
Alleen de gewijzigde componenten worden bijgewerkt, waardoor upgrades soepeler verlopen.
-
Grotere ontwikkelingsflexibiliteit:
Teams kunnen snel updates of patches voor afzonderlijke componenten vrijgeven, waardoor de reactietijd wordt verkort.
Lees verder over Jitterbit App BuilderOf de krachtige reeks AI-functies binnenkort beschikbaar App Builder 4.0.
