5 tips för mer effektiva applikationslanseringar

Av Tim Bond, Produktchef

Lågkodsavdelningar ägnar en avsevärd mängd tid och energi åt att planera och utveckla nästa uppsättning funktioner för sina lågkodsapplikationer. Att utveckla robusta appar som levererar förväntade resultat är av yttersta vikt. Men processen att flytta applikationen från en utvecklingsmiljö, genom en testmiljö och in i en produktions- eller livermiljö är alltför ofta en eftertanke.

Att ha en väl etablerad och väl kommunicerad plan för att släppa en applikation till en produktionsmiljö är den enskilt viktigaste delen av en lanseringsfas. Här är några punkter du bör fundera igenom innan du gör någon lansering:

• När kommer releasen att starta, och hur lång tid kommer den att ta?

  Arbeta tillsammans med intressenterna för att identifiera en tidpunkt då de påverkas så lite som möjligt. Tidsåtgången är svår att förutsäga – ju mer du gör det, desto bättre kommer du att kunna uppskatta den. Lova mindre och leverera mer än vad din uppskattning visar.

• Hur kommer slutanvändarna att påverkas under lanseringen?

  Oavsett hur bra du kommunicerar releaser och planerad skiftid i förväg måste du utgå från att en användare kommer att befinna sig i applikationen om de kan det. Det här kanske inte är ett problem, men om det är det kan du överväga att förbjuda åtkomst till applikationen under underhållsperioden.

• Vem ansvarar för varje steg i utgivningsprocessen?

  En detaljerad plan bör förankras hos det team som ska utföra stegen. Ta er tid att gå igenom planeringen tillsammans och betona att det inte finns några dumma frågor när det gäller att skapa klarhet kring lanseringsplanen. Se till att varje individ har rätt behörighet för att utföra de moment som han/hon har tilldelats.

• Vilka nya anslutningar/integrationspunkter till tredjepartsapplikationer introduceras?

  Första gången en anslutning eller integration ska lanseras finns det en liten osäkerhet i bakhuvudet på teamet. En felaktig API-nyckel eller blockerad nätverkstrafik kan grusa planerna. Utvecklare bör göra det till en poäng att uppmärksamma detta för teamet så att den nya anslutningen kan planeras in på ett lämpligt sätt.

• Om releasen inte lyckas, vad är återställningsplanen?

  Detta är aldrig det förväntade eller önskade resultatet, men att ha en plan i förväg kommer att vägleda teamet under en stressig situation.

Du får bara en chans att lyckas med lanseringen vid det första försökta. Jag föreslår att du använder en test- eller staging-release som ett genrep inför produktionen för att lösa eventuella problem.

När det gäller Jitterbit App Builder-applikationsutgåvor skapar era utvecklare en utgåva från utvecklingsmiljön, laddar ner utgåvefilen (vi kallar den en LP-fil) och laddar upp den till målmiljön för installation. Det finns ett par vanliga risker som ni bör kontrollera noga innan ni skapar utgåvan och installerar den i produktionsmiljön:

• Alternativ för bordsinstallation:

  Oftast kommer du att ha fysiska tabeller inkluderade i din release. Varje tabell har en inställning för installationsalternativ som avgör hur data som lagras i tabellen hanteras när releasen skapas, och därefter installeras, i en målmiljö. Detta är en kraftfull funktion, men den bör användas med försiktighet. Du vill definitivt inte ersätta kvalitetsproduktionsdata med all data som utvecklare skapar. Du kan ta reda på mer om dessa alternativen på vår Bygg en dokumentationssida för lanseringspaket.

• Roller:

  Åtkomst till en sida, samt de inbyggda funktionerna för att skapa, redigera och ta bort data som visas för en användare på en sida, styrs på ett detaljerat sätt i det logiska lagret. Varje gång en utvecklare ändrar roller i en affärsregel eller introducerar en ny affärsregel på en sida, kan det få oavsedda konsekvenser för en viss användargrupps möjlighet att nå sidan. Att skapa en testanvändare för varje användargrupp och göra regressionstester för roller är en utmärkt rutin före varje lansering i produktion. Detta hjälper dig att undvika det befarade e-postmeddelandet från slutanvändaren dagen efter en lansering med texten “Jag kommer inte åt den här sidan längre”. Kolla in den här dokumentationssidan för mer information om privilegier och behörigheter.

Varje gång du ska släppa din Jitterbit App Builder-applikation bör du noggrant granska släppmallen. Du bör endast släppa de delar av applikationen som har ändrats och som du vill släppa till produktion.

I din release-mall kan du välja mellan dessa olika komponenter. Du kan naturligtvis släppa en hel applikation som inkluderar alla datakällor, logik och sidor. Eller om din ändring var i mindre skala, kan du släppa bara en enskild sida eller en enskild affärsregel och släppa dessa mindre komponenter till produktion, och lämna resten av applikationen som den är. Denna flexibilitet i lanseringprocess gör det enklare för ert utvecklingsteam att hantera kritiska problem som uppstår under arbetet med de större ärendena.

Funktionen för programkomponenter ökar flexibiliteten, hastigheten och kontrollen över programvarudistributionsprocessen, vilket gör den till ett kraftfullt verktyg i miljöer som kräver frekventa uppdateringar och minimal stilleståndstid. De viktigaste fördelarna för dina utvecklingsteam är:

• Modulära uppdateringar:

  Gör att specifika delar av en applikation kan uppdateras oberoende av varandra, vilket minskar kodberoenden.

• Minimerad dötid:

  Endast de ändrade komponenterna uppdateras, vilket möjliggör smidigare uppgraderingar.

• Större utvecklingsflexibilitet:

  Team kan snabbt släppa uppdateringar eller buggfixar för enskilda komponenter, vilket förbättrar svarstiden.

Läs mer om Jitterbit App Builder, eller En kraftfull uppsättning AI-funktioner kommer snart till App Builder 4.0.