5 tips för mer effektiva programversioner

Av Tim Bond, Produktchef

Utvecklingsteam med låg kod lägger ner mycket tid och energi på att avgränsa och utveckla nästa uppsättning funktioner för sina lågkodsprogram. Att utveckla robusta appar som ger de förväntade resultaten är av yttersta vikt. Men processen att flytta applikationen från en utvecklingsmiljö, genom en testmiljö och till en produktions- eller livemiljö är alltför ofta en eftertanke.

Att ha en väletablerad och väl kommunicerad plan för att släppa en applikation till en produktionsmiljö är den enskilt viktigaste delen av en go-live. Här är några saker du bör tänka igenom innan du gör någon release:

• När kommer releasen att starta och hur lång tid tar det?

  Arbeta med intressenterna för att identifiera en tidpunkt då de kommer att påverkas minimalt. Varaktigheten är svår att förutsäga – ju mer du gör det, desto bättre kommer du att kunna uppskatta detta. Underlöfte och överleverera enligt din uppskattning.

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

  Oavsett hur väl du kommunicerar releaser och planerade driftstopp i förväg, måste du anta att en användare kommer att finnas i applikationen om de kan vara det. Detta kanske inte är ett problem, men om det är det kan du överväga att förbjuda åtkomst till applikationen under underhållsperioden.

• Vem är ansvarig för varje steg i releaseprocessen?

  En detaljerad plan bör socialiseras med teamet av personer som utför stegen. Ta dig tid att se över planen tillsammans och betona att det inte finns några dumma frågor när det kommer till tydlighet i releaseplanen. Se till att varje individ har rätt åtkomst för att utföra de steg han/hon är tilldelad att göra.

• Vilka nya anslutningar/integreringspunkter till tredjepartsapplikationer introduceras?

  Första gången en anslutning eller integration går live kommer det att finnas lite osäkerhet i bakhuvudet. En felaktig API-nyckel eller blockerad nätverkstrafik kan kasta en skiftnyckel i planen. Utvecklare bör göra det till en punkt att kalla ut detta för teamet så att den nya anslutningen kan planeras på lämpligt sätt.

• Om releasen inte lyckas, vad är backout-planen?

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

Du får bara en chans att få en framgångsrik live-sändning vid första försöket. Jag föreslår att du använder en test- eller iscensättningsversion som en torrkörning för produktionen för att lösa eventuella problem.

När det kommer till Jitterbit App Builder applikationsversioner skapar dina utvecklare en release från utvecklingsmiljön, laddar ner releasefilen (vi kallar det en LP-fil) och laddar upp den till målmiljön som ska installeras. Det finns ett par vanliga risker som du bör dubbelkolla innan du skapar versionen och installerar den i produktion:

• Alternativ för tabellinstallation:

  Oftare än inte kommer du att ha fysiska tabeller inkluderade i din release. Varje tabell har en installationsalternativinställning som bestämmer hur data som lagras i tabellen hanteras när versionen skapas och sedan 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 datautvecklare som skapar. Du kan ta reda på mer om dessa alternativ på vår Bygg en dokumentationssida för releasepaket.

• roller:

  Åtkomst till en sida, såväl som de inbyggda möjligheterna att skapa/redigera/ta bort data som visas för en användare på en sida, styrs granulärt i det logiska lagret. Varje gång en utvecklare ändrar rollerna för en affärsregel eller introducerar en ny affärsregel på en sida, kan det ha en oavsiktlig effekt på en viss användargrupps förmåga att komma till sidan. Att skapa en testanvändare för varje användargrupp och regressionstestning för roller är en bra praxis innan någon release i produktion. Detta hjälper dig att undvika det fruktade "Jag kan inte komma till den här sidan längre" från din slutanvändare dagen efter en release. Checka ut denna dokumentationssida för mer information om privilegier och behörigheter.

Varje gång du går för att släppa din Jitterbit App Builder ansökan, granska releasemallen. Du ska bara släppa de komponenter i applikationen som har ändrats och som du vill släppa till produktion.

I din releasemall kan du välja dessa olika komponenter. Du kan naturligtvis släppa en hel applikation som innehåller alla datakällor, logik och sidor. Eller om din ändring var i mindre skala, kunde du bara släppa en enda sida eller en enda affärsregel och släppa de mindre komponenterna till produktion, och låta resten av programmet vara som det är. Denna flexibilitet i släppprocessen gör det möjligt för ditt utvecklingsteam att lättare svara på alla kritiska problem som dyker upp när du arbetar med större förfrågningar.

Applikationskomponentens funktion förbättrar 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 med för dina utvecklingsteam är:

• Modulära uppdateringar:

  Tillåter att specifika komponenter i en applikation uppdateras oberoende, vilket minskar kodberoendet.

• Minimerad driftstopp:

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

• Större utvecklingsförmåga:

  Team kan släppa uppdateringar eller patchar snabbt för enskilda komponenter, vilket ökar svarstiden.

Läs mer om Jitterbit App Builder, Eller kraftfull svit med AI-funktioner kommer snart App Builder 4.0.