5 tips til mere effektive applikationsudgivelser

Af Tim Bond, Product Manager

Udviklingsteams med lav kode bruger en betydelig mængde tid og energi på at afgrænse og udvikle det næste sæt funktioner til deres lavkode-applikationer. Udvikling af robuste apps, der leverer de forventede resultater, er af yderste vigtighed. Men processen med at flytte applikationen fra et udviklingsmiljø, gennem et testmiljø og ind i et produktions- eller live-miljø er for ofte en eftertanke.

At have en veletableret og velkommunikeret plan for frigivelse af en applikation til et produktionsmiljø er den vigtigste enkeltdel af en go-live. Her er et par ting, du bør tænke igennem, før du udgiver nogen:

• Hvornår starter udgivelsen, og hvor lang tid tager det?

  Arbejd sammen med interessenterne for at identificere et tidspunkt, hvor de vil blive minimalt påvirket. Varigheden er svær at forudsige - jo mere du gør det, jo bedre vil du være i stand til at estimere dette. Underløfter og overlever på dit estimat.

• Hvordan vil slutbrugerne blive påvirket under udgivelsen?

  Uanset hvor godt du kommunikerer udgivelser og planlagt nedetid på forhånd, må du antage, at en bruger vil være i applikationen, hvis de kan være det. Dette er muligvis ikke et problem, men hvis det er, kan du overveje at forbyde adgang til applikationen i vedligeholdelsesperioden.

• Hvem er ansvarlig for hvert trin i udgivelsesprocessen?

  En detaljeret plan bør socialiseres med det team af mennesker, der udfører trinene. Tag dig tid til at gennemgå planen sammen, og understrege, at der ikke er nogen dumme spørgsmål, når det kommer til klarhed om udgivelsesplanen. Sørg for, at hver enkelt person har den korrekte adgang til at udføre de trin, han/hun har fået tildelt.

• Hvilke nye forbindelser/integrationspunkter til tredjepartsapplikationer bliver introduceret?

  Første gang en forbindelse eller integration går live, vil der være lidt usikkerhed i baghovedet på holdet. En forkert API-nøgle eller blokeret netværkstrafik kan kaste en skruenøgle i planen. Udviklere bør gøre det til et punkt at kalde dette ud for teamet, så den nye forbindelse kan planlægges korrekt.

• Hvis udgivelsen ikke lykkes, hvad er backout-planen?

  Dette er aldrig det forventede eller ønskede resultat, men at have en plan på forhånd vil guide holdet i en stressende situation.

Du får kun én chance for at få en succesfuld live i første forsøg. Jeg foreslår, at du bruger en test- eller iscenesættelsesudgivelse som et tørløb til produktionen for at løse eventuelle problemer.

Når det kommer til Jitterbit App Builder applikationsudgivelser, opretter dine udviklere en udgivelse fra udviklingsmiljøet, downloader udgivelsesfilen (vi kalder den en LP-fil) og uploader den til målmiljøet, der skal installeres. Der er et par almindelige risici, du bør dobbelttjekke, før du opretter udgivelsen og installerer den i produktionen:

• Indstillinger for tabelinstallation:

  Oftere end ikke, vil du have fysiske tabeller inkluderet i din udgivelse. Hver tabel har en installationsindstilling, som bestemmer, hvordan de data, der er lagret i tabellen, håndteres, når udgivelsen oprettes og efterfølgende installeres i et målmiljø. Dette er en kraftfuld egenskab, men den skal bruges med forsigtighed. Du ønsker bestemt ikke at erstatte kvalitetsproduktionsdata med alle de data, udviklere opretter. Du kan finde ud af mere om disse muligheder på vores Byg en udgivelsespakkedokumentationsside.

• Roller:

  Adgang til en side, såvel som de indbyggede muligheder for oprettelse/redigering/sletning af data, der vises til en bruger på en side, styres granuleret i det logiske lag. Hver gang en udvikler ændrer rollerne for en forretningsregel eller introducerer en ny forretningsregel på en side, kan det have en utilsigtet effekt på en bestemt brugergruppes mulighed for at komme til siden. Oprettelse af en testbruger for hver brugergruppe og regressionstest for roller er en god praksis før enhver frigivelse i produktion. Dette vil hjælpe dig med at undgå den frygtede "Jeg kan ikke komme til denne side mere" e-mail fra din slutbruger dagen efter en udgivelse. Tjek ud denne dokumentationsside for mere information om privilegier og tilladelser.

Hver gang du går for at frigive din Jitterbit App Builder applikation, skal du granske udgivelsesskabelonen. Du bør kun frigive de komponenter i applikationen, der er ændret, og som du vil frigive til produktion.

I din udgivelsesskabelon kan du vælge disse forskellige komponenter. Du kan selvfølgelig frigive en hel applikation, der vil inkludere alle datakilder, logik og sider. Eller hvis din ændring var i mindre skala, kunne du frigive kun en enkelt side eller en enkelt forretningsregel og frigive de mindre komponenter til produktion, så resten af ​​applikationen forbliver som den er. Denne fleksibilitet i frigivelsesproces giver dit udviklingsteam lettere mulighed for at reagere på kritiske problemer, der dukker op, mens du arbejder på de større anmodninger.

Applikationskomponentfunktionen forbedrer fleksibilitet, hastighed og kontrol over softwareimplementeringsprocessen, hvilket gør den til et kraftfuldt værktøj i miljøer, der kræver hyppige opdateringer og minimal nedetid. De vigtigste fordele ved dine udviklingsteams er:

• Modulære opdateringer:

  Tillader, at specifikke komponenter i en applikation opdateres uafhængigt, hvilket reducerer kodeafhængighed.

• Minimeret nedetid:

  Kun de ændrede komponenter opdateres, hvilket muliggør smidigere opgraderinger.

• Større udviklingsvenlighed:

  Teams kan frigive opdateringer eller patches hurtigt til individuelle komponenter, hvilket øger responstiden.

Lær mere om Jitterbit App BuilderEller kraftfuld suite af AI-funktioner kommer snart til App Builder 4.0.