5 tips for mer effektive applikasjonsutgivelser

Av Tim Bond, Product Manager

Utviklingsteam med lav kode bruker en betydelig mengde tid og energi på å kartlegge og utvikle det neste settet med funksjoner for sine lavkodeapplikasjoner. Å utvikle robuste apper som leverer de forventede resultatene er av ytterste viktighet. Men prosessen med å flytte applikasjonen fra et utviklingsmiljø, gjennom et testmiljø og inn i et produksjons- eller live-miljø er for ofte en ettertanke.

Å ha en veletablert og godt kommunisert plan for utgivelse av en applikasjon til et produksjonsmiljø er den viktigste enkeltdelen av en start. Her er noen ting du bør tenke gjennom før du gjør en utgivelse:

• Når skal utgivelsen starte, og hvor lang tid vil det ta?

  Samarbeid med interessentene for å identifisere et tidspunkt da de vil bli minimalt påvirket. Varigheten er vanskelig å forutsi - jo mer du gjør det, jo bedre vil du være i stand til å anslå dette. Underløfter og overlever på anslaget ditt.

• Hvordan vil sluttbrukerne bli påvirket under utgivelsen?

  Uansett hvor godt du kommuniserer utgivelser og planlagt nedetid på forhånd, må du anta at en bruker vil være i applikasjonen hvis de kan være det. 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 utgivelsesprosessen?

  En detaljert plan bør sosialiseres med teamet av personer som utfører trinnene. Ta deg tid til å gjennomgå planen sammen, og understreke at det ikke er noen dumme spørsmål når det kommer til klarhet i utgivelsesplanen. Sørg for at hver enkelt person har riktig tilgang til å utføre trinnene han/hun er tildelt.

• Hvilke nye koblinger/integrasjonspunkter til tredjepartsapplikasjoner introduseres?

  Første gang en tilkobling eller integrering går live, vil det være litt usikkerhet i bakhodet til laget. En feil API-nøkkel eller blokkert nettverkstrafikk kan kaste en skiftenøkkel i planen. Utviklere bør gjøre det et poeng å kalle dette ut for teamet slik at den nye forbindelsen kan planlegges på riktig måte.

• Hvis utgivelsen ikke lykkes, hva er backout-planen?

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

Du får bare én sjanse til å ha en vellykket live-start på første forsøk. Jeg foreslår at du bruker en test- eller iscenesettelsesutgivelse som en tørrkjøring for produksjonen for å løse eventuelle problemer.

Når det kommer til Jitterbit App Builder applikasjonsutgivelser, oppretter utviklerne en utgivelse fra utviklingsmiljøet, laster ned utgivelsesfilen (vi kaller det en LP-fil), og laster den opp til målmiljøet som skal installeres. Det er et par vanlige risikoer du bør dobbeltsjekke før du oppretter utgivelsen og installerer den i produksjon:

• Alternativer for tabellinstallasjon:

  Oftere enn ikke kommer du til å ha fysiske tabeller inkludert i utgivelsen. Hver tabell har en installasjonsalternativinnstilling som bestemmer hvordan dataene som er lagret i tabellen 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 vil definitivt ikke erstatte kvalitetsproduksjonsdata med alle datautviklerne lager. Du kan finne ut mer om disse alternativene på vår Bygg en dokumentasjonsside for utgivelsespakke.

• Roller:

  Tilgang til en side, så vel som de opprinnelige mulighetene for å opprette/redigere/slette data som vises til en bruker på en side, kontrolleres 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 evne til å komme til siden. Å opprette en testbruker for hver brukergruppe og regresjonstesting for roller er en god praksis før enhver utgivelse i produksjon. Dette vil hjelpe deg å unngå den fryktede "Jeg kan ikke komme til denne siden lenger" fra sluttbrukeren dagen etter en utgivelse. Sjekk ut denne dokumentasjonssiden for mer informasjon om privilegier og tillatelser.

Hver gang du skal slippe ut din Jitterbit App Builder søknad, granske utgivelsesmalen. Du bør bare slippe komponentene i applikasjonen som har endret seg og som du vil frigi til produksjon.

I utgivelsesmalen kan du velge disse forskjellige komponentene. Du kan selvfølgelig gi ut en hel applikasjon som inkluderer alle datakilder, logikk og sider. Eller hvis endringen var i mindre skala, kunne du frigi bare en enkelt side eller enkelt forretningsregel og frigi de mindre komponentene til produksjon, og la resten av applikasjonen være som den er. Denne fleksibiliteten i utgivelsesprosess lar utviklingsteamet ditt lettere svare på eventuelle kritiske problemer som dukker opp mens du jobber med større forespørsler.

Applikasjonskomponentfunksjonen forbedrer fleksibilitet, hastighet og kontroll over programvaredistribusjonsprosessen, 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:

• Modulære oppdateringer:

  Lar spesifikke komponenter i en applikasjon oppdateres uavhengig, noe som reduserer kodeavhengighetene.

• Minimert nedetid:

  Bare de endrede komponentene oppdateres, noe som muliggjør jevnere oppgraderinger.

• Større utviklingssmidighet:

  Team kan gi ut oppdateringer eller patcher raskt for individuelle komponenter, noe som øker responstiden.

Lær mer om Jitterbit App BuilderEller kraftig pakke med AI-funksjoner kommer snart til App Builder 4.0.