5 tips til mere effektive applikationsudgivelser

Af Tim Bond, Producent

Low-code udviklingsteams bruger en betydelig mængde tid og energi på at afgrænse og udvikle det næste sæt funktioner til deres low-code applikationer. At udvikle robuste apps, der leverer de forventede resultater, er af allerstørste vigtighed. Men processen med at flytte applikationen fra et udviklingsmiljø, gennem et testmiljø og ind i et produktions- eller livemiljø er alt for ofte en eftertanke.

At have en veldefineret og velfungerende plan for frigivelse af en applikation til et produktionsmiljø er den absolut vigtigste del af en go-live. Her er et par ting, du bør overveje, før du foretager en frigivelse:

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

  Arbejd med interessenterne for at identificere et tidspunkt, hvor de vil blive mindst 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. Undervurder og overgå dine estimater.

• Hvordan vil slutbrugerne blive påvirket under frigørelsen?

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

• Hvem er ansvarlig for hver del af frigørelsesprocessen?

  En detaljeret plan bør socialiseres med det team af mennesker, der udfører trinene. Brug tid på at gennemgå planen sammen, og understreg, at der ikke findes dumme spørgsmål, når det kommer til klarhed over frigørelsesplanen. Sørg for, at hver enkelt person har den korrekte adgang til at udføre de trin, han/hun er tildelt.

• Hvilke nye forbindelser/integrationspunkter til tredjepartsapplikationer introduceres?

  Første gang en forbindelse eller integration går live, vil der være en smule usikkerhed i teamets baghoved. En forkert API-nøgle eller blokkeret netværkstrafik kan spolere planen. Udviklere bør gøre en dyd ud af at nævne dette for teamet, så den nye forbindelse kan planlægges hensigtsmæssigt.

• Hvis frigørelsen ikke er succesfuld, hvad er så tilbagetrækningsplanen?

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

Du får kun én chance for at få en succesfuld go-live i første forsøg. Jeg foreslår at bruge en test- eller staging-udgivelse som en generalprøve til produktion for at løse eventuelle problemer.

Når det gælder Jitterbit App Builder-applikationsudgivelser, opretter jeres udviklere en udgivelse fra udviklingsmiljøet, downloader udgivelsesfilen (som vi kalder en LP-fil) og uploader den til målmiljøet, hvor den skal installeres. Der er et par typiske risici, som I bør tjekke grundigt, inden I opretter udgivelsen og installerer den i produktionsmiljøet:

• Installation af tabelmuligheder:

  I de fleste tilfælde vil du have fysiske tabeller inkluderet i din udgivelse. Hver tabel har en installationsindstilling, der bestemmer, hvordan dataene i tabellen håndteres, når udgivelsen oprettes og efterfølgende installeres i et målmiljø. Dette er en kraftfuld funktion, men den bør bruges med forsigtighed. Du ønsker bestemt ikke at erstatte kvalitetsdata fra produktionen med alle de data, udviklere opretter. Du kan finde flere oplysninger om disse indstillinger på vores Dokumentationsside for udgivelsespakke.

• Roller:

  Adgang til en side, såvel som de indbyggede opret/rediger/slet-funktioner for data, der vises til en bruger på en side, styres granulært i det logiske lag. Hver gang en udvikler ændrer rollerne for en forretningsregel eller introducerer en ny forretningsregel til en side, kan det have en utilsigtet effekt på en bestemt brugergruppes evne til at få adgang til siden. At oprette en testbruger for hver brugergruppe og udføre regressionsprøvning for roller er en god praksis før enhver udgivelse til produktion. Dette vil hjælpe dig med at undgå den frygtede e-mail fra din slutbruger dagen efter en udgivelse: “Jeg kan ikke komme til denne side længere”. Se denne dokumentationsside for yderligere information om privilegier og tilladelser.

Hver gang du skal frigive din Jitterbit App Builder-applikation, skal du nøje gennemgå frigivelsesskabelonen. Du bør kun frigive de komponenter i applikationen, der er blevet ændret, og som du ønsker at frigive til produktion.

I din udgivelseskabelon kan du vælge disse forskellige komponenter. Du kan naturligvis udgive en hel applikation, som vil indeholde alle datakilder, logik og sider. Eller hvis din ændring var i mindre skala, kunne du udgive blot en enkelt side eller en enkelt forretningsregel og udgive disse mindre komponenter til produktion, og lade resten af applikationen være som den er. Denne fleksibilitet i frigivelsesproces giver dit udviklingsteam mulighed for lettere at reagere på kritiske problemer, der opstår, mens de arbejder på større anmodninger.

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

• Modulære opdateringer:

  Tillader specifikke komponenter af en applikation at blive opdateret uafhængigt og reducerer kodeafhængigheder.

• Minimeret nedetid:

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

• Større udviklingsagilitet:

  Hold kan hurtigt udgive opdateringer eller rettelser til individuelle komponenter, hvilket øger responstiden.

Lær mere om Jitterbit App Builder, eller den En række kraftfulde AI-funktioner kommer snart til App Builder 4.0.