5 tips for mer effektive applikasjonslanseringer

Av Tim Bond, Produktleder

Utviklingsteam for lavkode bruker betydelig med tid og energi på å definere omfanget og utvikle det neste settet med funksjoner for lavkodeapplikasjonene sine. Å utvikle robuste applikasjoner som leverer de forventede resultatene, er av ytterste viktighet. Men prosessen med å flytte applikasjonen fra et utviklingsmiljø, via et testmiljø, og inn i et produksjons- eller livemiljø, blir altfor ofte en ettertanker.

Å ha en godt etablert og godt kommunisert plan for å lansere en applikasjon til et produksjonsmiljø er den aller viktigste delen av en lansering. Her er noen elementer du bør tenke gjennom før du utfører en lansering:

• Når starter lanseringen, og hvor lang tid vil den ta?

  Arbeid sammen med interessentene for å finne et tidspunkt der de vil bli minst mulig påvirket. Varigheten er vanskelig å anslå – jo mer du gjør det, jo bedre vil du bli til å estimere dette. Lov mindre enn du kan holde, og lever mer enn du lover.

• Hvordan vil sluttbrukerne bli påvirket under lanseringen?

  Uansett hvor godt du kommuniserer oppdateringer og planlagt nedetid på forhånd, må du ta høydet for at en bruker vil være i applikasjonen hvis de kan. Dette er kanskje ikke et problem, men hvis det er det, kan du vurdere å forby tilgang til applikasjonen i vedlikeholdsperioden.

• Hvem er ansvarlig for hvert trinn i lanseringឱ្យ- / utgivelsesprosessen?

  En detaljert plan bør deles med teamet som skal utføre trinnene. Ta deg tid til å gå gjennom planen sammen, og understrek at det ikke finnes noen dumme spørsmål når det gjelder å skape klarhet rundt lanseringsplanen. Forsikre deg om at hver enkelt person har riktig tilgang til å utføre de trinnene han/hun er tildelt.

• Hvilke nye tilkoblinger/integrasjonspunkter til tredjepartsapplikasjoner blir innført?

  Den første gangen en tilkobling eller integrasjon settes i drift, vil det alltid være en viss usikkerhet i bakhodet på teamet. En feil API-nøkkel eller blokkert nettverkstrafikk kan sette en kjepp i hjulet. Utviklere bør sørge for å gjøre teamet oppmerksom på dette, slik at den nye tilkoblingen kan planlegges på riktig måte.

• Hvis lanseringen ikke lykkes, hva er da beredskapsplanen?

  Dette er aldri det forventede eller ønskede utfallet, men å ha en plan på forhånd vil veilede teamet under en stressende situasjon.

Man har bare én sjanse til å få en vellykket driftsettelse ved første forsøk. Jeg anbefaler å bruke en test- eller staging-utgivelse som en prøvekjøring for produksjonsmiljøet for å avdekke eventuelle problemer.

Når det gjelder utgivelser av Jitterbit App Builder-applikasjoner, oppretter utviklerne en utgivelse fra utviklingsmiljøet, laster ned utgivelsesfilen (vi kaller den en LP-fil) og laster den opp til målmiljøet for installasjon. Det finnes et par vanlige risikoer du bør sjekke nøye før du oppretter utgivelsen og installerer den i produksjonsmiljøet:

• Tabellinstallasjonsalternativer:

  I de fleste tilfeller vil utgivelsen din inneholde fysiske tabeller. Hver tabell har en innstilling for installasjonsalternativ som bestemmer hvordan dataene som er lagret i tabellen skal håndteres når utgivelsen opprettes og deretter installeres i et målmiljø. Dette er en kraftig funksjon, men den bør brukes med forsiktighet. Du ønsker absolutt ikke å erstatte kvalitetsdata fra produksjonsmiljøet med alle dataene utviklerne oppretter. Du kan finne ut mer om disse alternativene på vår Lag en dokumentasjonsside for en utgivelsespakke.

• Roller:

  Tilgang til en side, i tillegg til de innebygde funksjonene for å opprette, redigere og slette data som vises til en bruker på en side, styres detaljert i det logiske laget. Hver gang en utvikler endrer rollene til en forretningsregel eller introduserer en ny forretningsregel på en side, kan det ha en utilsiktet effekt på en bestemt brukergruppes mulighet til å nå siden. Å opprette en testbruker for hver brukergruppe og utføre regresjonstesting av roller er en god praksis før en utgivelse til produksjon. Dette vil hjelpe deg med å unngå den fryktede “jeg kommer ikke til denne siden lenger”-e-posten fra sluttbrukeren din dagen etter en utgivelse. Sjekk ut denne dokumentasjonssiden for mer informasjon om privilegier og tillatelser.

Hver gang du skal publisere Jitterbit App Builder-applikasjonen, må du gå nøye gjennom publiseringsmalen. Du bør kun publisere de komponentene i applikasjonen som har blitt endret og som du ønsker å publisere til produksjonsmiljøet.

I utgivelsesmalen din kan du velge mellom disse ulike komponentene. Du kan selvfølgelig distribuere en hel applikasjon som inkluderer alle datakilder, logikk og sider. Eller hvis endringen din var av mindre omfang, kan du distribuere bare én enkelt side eller én enkelt forretningsregel og distribuere disse mindre komponentene til produksjonsmiljøet, mens resten av applikasjonen forblir uendret. Denne fleksibiliteten i utgivelsesprosess gjør det enklere for utviklingsteamet å håndtere eventuelle kritiske problemer som oppstår mens de jobber med de større oppdragene.

Funksjonen i applikasjonskomponenten øker fleksibiliteten, hastigheten og kontrollen over programvareutrullingsprosessen, noe som gjør den til et kraftig verktøy i miljøer som krever hyppige oppdateringer og minimal nedetid. De viktigste fordelene for utviklingsteamene dine er:

• Oppdateringer av modulene:

  Gjør det mulig å oppdatere bestemte komponenter i et program hver for seg, noe som reduserer avhengighetene i koden.

• Minimert driftsstans:

  Bare de endrede komponentene oppdateres, noe som gir jevnere oppgraderinger.

• Større fleksibilitet i utviklingsarbeidet:

  Teamene kan raskt slippe oppdateringer eller feilrettinger for enkeltkomponenter, noe som forbedrer responstiden.

Lær mer om Jitterbit App Builder, eller den En kraftig pakke med AI-funksjoner kommer snart til App Builder 4.0.