5 vinkkiä tehokkaampiin sovellusten julkaisuihin

Kirjailija: Tim Bond, Tuotepäällikkö

Matalakoodin kehitystiimit käyttävät paljon aikaa ja energiaa seuraavan ominaisuuksien määrittämiseen ja kehittämiseen alhaisen koodin sovelluksilleen. On äärimmäisen tärkeää kehittää kestäviä sovelluksia, jotka tuottavat odotetut tulokset. Mutta prosessi, jossa sovellus siirretään kehitysympäristöstä testiympäristön kautta tuotanto- tai live-ympäristöön, on liian usein jälkiajattelu.

Vakiintunut ja hyvin kommunikoitu suunnitelma sovelluksen julkaisusta tuotantoympäristöön on tärkein yksittäinen osa käyttöönottoa. Tässä on muutamia asioita, jotka sinun tulee harkita ennen julkaisua:

• Milloin julkaisu alkaa ja kuinka kauan se kestää?

  Työskentele sidosryhmien kanssa löytääksesi ajankohta, jolloin heihin kohdistuu mahdollisimman vähän vaikutusta. Kestoa on vaikea ennustaa – mitä enemmän teet sen, sitä paremmin pystyt arvioimaan tämän. Alilupaus ja ylitoimitus arviossasi.

• Miten julkaisu vaikuttaa loppukäyttäjiin?

  Riippumatta siitä, kuinka hyvin kommunikoit julkaisuista ja suunnitelluista seisokeista etukäteen, sinun on oletettava, että käyttäjä on sovelluksessa, jos hän voi olla. Tämä ei ehkä ole ongelma, mutta jos on, voit estää sovelluksen käytön huoltojakson aikana.

• Kuka on vastuussa jokaisesta julkaisuprosessin vaiheesta?

  Yksityiskohtainen suunnitelma tulisi olla tekemisissä vaiheita suorittavan ryhmän kanssa. Käytä aikaa suunnitelman tarkistamiseen yhdessä ja korosta, ettei julkaisusuunnitelman selkeyttämisessä ole tyhmiä kysymyksiä. Varmista, että jokaisella henkilöllä on oikeat oikeudet suorittaa hänelle määrätyt vaiheet.

• Mitä uusia yhteyksiä/integraatiopisteitä kolmansien osapuolien sovelluksiin otetaan käyttöön?

  Kun yhteys tai integraatio otetaan käyttöön ensimmäistä kertaa, joukkueen takana on pieni epävarmuus. Väärä API-avain tai estetty verkkoliikenne voi aiheuttaa jakoavaimen suunnitelman. Kehittäjien tulee ottaa tämä esiin tiimille, jotta uusi yhteys voidaan suunnitella asianmukaisesti.

• Jos julkaisu ei onnistu, mikä on peruutussuunnitelma?

  Tämä ei ole koskaan odotettu tai toivottu lopputulos, mutta etukäteen tehty suunnitelma ohjaa tiimiä stressaavan tilanteen aikana.

Saat vain yhden mahdollisuuden menestyä ensimmäisellä kerralla. Suosittelen testi- tai vaihejulkaisun käyttöä kuivaajona tuotannossa mahdollisten ongelmien ratkaisemiseksi.

Kun on kyse Jitterbitistä App Builder sovellusjulkaisut, kehittäjäsi luovat julkaisun kehitysympäristöstä, lataavat julkaisutiedoston (kutsumme sitä LP-tiedostoksi) ja lataavat sen asennettavaan kohdeympäristöön. On olemassa pari yleistä riskiä, ​​jotka sinun tulee tarkistaa ennen kuin luot julkaisun ja asennat sen tuotantoon:

• Taulukon asennusvaihtoehdot:

  Useimmiten sinulla on fyysisiä taulukoita mukana julkaisussasi. Jokaisessa taulukossa on asennusasetus, joka määrittää, kuinka taulukkoon tallennettuja tietoja käsitellään, kun julkaisu luodaan ja myöhemmin asennetaan kohdeympäristöön. Tämä on voimakas ominaisuus, mutta sitä tulee käyttää varoen. Et todellakaan halua korvata laadukasta tuotantodataa kaikella kehittäjien luomalla tiedolla. Näistä vaihtoehdoista voit lukea lisää sivuiltamme Luo julkaisupaketin dokumentaatiosivu.

• roolit:

  Pääsy sivulle sekä käyttäjälle sivulla näytettyjen tietojen alkuperäiset luonti-/muokkaus-/poisto-ominaisuudet ohjataan tarkasti loogisessa kerroksessa. Aina kun kehittäjä muuttaa liiketoimintasäännön rooleja tai ottaa käyttöön uuden liiketoimintasäännön sivulle, sillä voi olla tahaton vaikutus tietyn käyttäjäryhmän kykyyn päästä sivulle. Testikäyttäjän luominen jokaiselle käyttäjäryhmälle ja roolien regressiotestaus on hyvä käytäntö ennen tuotantoon julkaisua. Tämä auttaa sinua välttämään pelätyn "en pääse tälle sivulle enää" -sähköpostin loppukäyttäjältäsi julkaisun jälkeisenä päivänä. Tarkistaa tällä dokumentaatiosivulla saadaksesi lisätietoja oikeuksista ja käyttöoikeuksista.

Joka kerta kun menet vapauttamaan Jitterbit App Builder sovellus, tutustu julkaisumalliin. Sinun tulee vapauttaa vain ne sovelluksen komponentit, jotka ovat muuttuneet ja jotka haluat julkaista tuotantoon.

Voit valita nämä eri komponentit julkaisumallissasi. Voit tietysti julkaista kokonaisen sovelluksen, joka sisältää kaikki tietolähteet, logiikan ja sivut. Tai jos muutoksesi oli pienemmässä mittakaavassa, voit vapauttaa vain yhden sivun tai yksittäisen liiketoimintasäännön ja vapauttaa pienemmät komponentit tuotantoon jättäen muun sovelluksen ennalleen. Tämä joustavuus vapauttamisprosessi avulla kehitystiimisi voi vastata helpommin kriittisiin ongelmiin, joita ilmenee työskennellessään suurempien pyyntöjen parissa.

Sovelluskomponenttiominaisuus parantaa ohjelmiston käyttöönottoprosessin joustavuutta, nopeutta ja hallintaa, mikä tekee siitä tehokkaan työkalun ympäristöissä, jotka vaativat usein päivityksiä ja minimaalisia seisokkeja. Kehitystiimillesi tärkeimmät edut ovat:

• Modulaariset päivitykset:

  Mahdollistaa sovelluksen tiettyjen komponenttien päivittämisen itsenäisesti, mikä vähentää koodiriippuvuutta.

• Minimoitu seisokkiaika:

  Vain muuttuneet komponentit päivitetään, mikä mahdollistaa sujuvammat päivitykset.

• Parempi kehitysketteryys:

  Tiimit voivat julkaista päivityksiä tai korjauksia nopeasti yksittäisille komponenteille, mikä nopeuttaa vasteaikaa.

Lisätietoja Jitterbit App Builder, Tai tehokas sarja tekoälyominaisuuksia tulossa pian App Builder 4.0.