5 vinkkiä tehokkaampiin sovellusjulkaisuihin

Kirjoittanut Tim Bond, Tuotepäällikkö

Vähäkoodisen kehityksen tiimit käyttävät huomattavan määrän aikaa ja energiaa vähäkoodisten sovellustensa seuraavan ominaisuusjoukon rajaamiseen ja kehittämiseen. Sellaisten vankeiden sovellusten kehittäminen, jotka tuottavat odotetut tulokset, on äärimmäisen tärkeää. Sovelluksen siirtäminen kehitysympäristöstä testausympäristön kautta tuotanto- tai live-ympäristöön on kuitenkin aivan liian usein jälkiajatus.

Hyvin vakiinnutettu ja selkeästi viestitty suunnitelma sovelluksen julkaisemisesta tuotantoympäristöön on käyttöönoton tärkein yksittäinen osa. Tässä on muutama asia, jotka sinun tulisi miettiä läpi ennen minkäänlaista julkaisua:

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

  Tee yhteistyötä sidosryhmien kanssa sellaisen ajankohdan löytämiseksi, jolloin heihin kohdistuu mahdollisimman vähän haittaa. Kestoa on vaikea ennustaa – mitä enemmän teet sitä, sitä paremmin pystyt arvioimaan sen. Lupaile arviossasi liian vähän ja ylitä odotukset.

• Miten loppukäyttäjiin vaikutetaan julkaisun aikana?

  Oli miten hyvin tahansa viestinyt julkaisuista ja suunnitelluista käyttökatkoista etukäteen, on oletettava, että käyttäjä on sovelluksessa, jos vain voi. Tämä ei välttämättä ole ongelma, mutta jos se on, saatat harkita pääsyn estämistä sovellukseen huoltojakson aikana.

• Kuka on vastuussa julkaisuprosessin jokaisesta vaiheesta?

  Yksityiskohtainen suunnitelma tulisi jakaa niiden ihmisten tiimille, jotka suorittavat vaiheet. Varatkaa aikaa suunnitelman läpikäymiseen yhdessä ja korostakaa, että tyhmiä kysymyksiä ei ole, kun kyse on julkaisusuunnitelman selkeydestä. Varmistakaa, että jokaisella henkilöllä on oikeat käyttöoikeudet suorittaa hänelle määrätyt vaiheet.

• Mitä uusia yhteyttä tai integraatiopisteitä kolmannen osapuolen sovelluksiin ollaan ottamassa käyttöön?

  Kun yhteys tai integraatio viedään tuotantoon ensimmäistä kertaa, tiimin mielessä on aina pieni epävarmuus. Väärä API-avain tai estetty verkkoliikenne voi sotkea suunnitelmat. Kehittäjien tulisi tehdä asiasta selväksi tiimille, jotta uusi yhteys voidaan ottaa asianmukaisesti huomioon suunnittelussa.

• Jos julkaisu ei onnistu, mikä on palautussuunnitelma?

  Tämä ei ole koskaan odotettu eikä toivottu lopputulos, mutta ennakkosuunnitelma ohjaa tiimiä stressaavassa tilanteessa.

Sinulla on vain yksi mahdollisuus onnistuneeseen käyttöönottoon heti ensimmäisellä kerralla. Suosittelen käyttämään testi- tai esituotantojulkaisua tuotannon kenraaliharjoituksena mahdollisten ongelmien ratkaisemiseksi.

Kun kyseessä ovat Jitterbit App Builder-sovellusten julkaisut, kehittäjät luovat julkaisun kehitysympäristössä, lataavat julkaisutiedoston (jota kutsumme LP-tiedostoksi) ja siirtävät sen kohdeympäristöön asennettavaksi. On olemassa muutamia yleisiä riskejä, jotka sinun tulisi tarkistaa huolellisesti ennen julkaisun luomista ja sen asentamista tuotantoympäristöön:

• Pöydän asennusvaihtoehdot:

  Useammin kuin useammin julkaisuusi sisältyy fyysisiä tauluja. Jokaisella taululla on asennusasetus, joka määrittää, miten tauluun tallennettua dataa käsitellään, kun julkaisu luodaan ja asennetaan kohdeympäristöön. Tämä on tehokas ominaisuus, mutta sitä tulisi käyttää varoen. Et todellakaan halua korvata laadukasta tuotantodataa kaikella sillä datalla, jota kehittäjät luovat. Voit lukea lisää näistä vaihtoehdoista osoitteessa Rakenna julkaisupaketin dokumentaatiosivu.

• Roolit:

  Pääsy sivulle sekä sivulla näytettävien tietojen omat luonti-, muokkaus- ja poistotoiminnot on määritelty tarkasti loogisella tasolla. Aina kun kehittäjä muokkaa liikennesäännön rooleja tai ottaa käyttöön uuden liikennesäännön sivulla, 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 erinomainen käytäntö ennen tuotantoon julkaisua. Tämä auttaa välttämään loppukäyttäjältä tulevan pelätyn “en pääse enää tälle sivulle” -sähköpostin julkaisua seuraavana päivänä. Tutustu tämä ohjesivu lisätietoja käyttöoikeuksista ja luvista.

Aina kun olet julkaisemassa Jitterbit App Builder-sovellustasi, tarkista julkaisumalli huolellisesti. Sinun tulisi julkaista vain ne sovelluksen osat, joihin on tehty muutoksia ja jotka haluat viedä tuotantoympäristöön.

Julkaisupohjassasi voit valita nämä eri komponentit. Voit tietysti julkaista koko sovelluksen, joka sisältää kaikki tietolähteet, logiikan ja sivut. Tai jos muutoksesi oli pienemmässä mittakaavassa, voit julkaista pelkän yksittäisen sivun tai yksittäisen liiketoimintasäännön ja siirtää nämä pienemmät komponentit tuotantoon jättäen muun sovelluksen ennalleen. Tämä joustavuus julkaisuprosessi mahdollistaa kehitystiimillenne helpomman reagoimisen kaikkiin kriittisiin ongelmiin, joita ilmenee suurempien pyyntöjen parissa työskentelyn aikana.

Sovelluskomponenttiominaisuus parantaa ohjelmiston käyttöönottofon prosessin joustavuutta, nopeutta ja hallintaa, mikä tekee siitä tehokkaan työkalun ympäristöissä, jotka vaativat toistuvia päivityksiä ja minimaalista käyttökatkoa. Keskeiset edut kehitystiimeillesi ovat:

• Modulaariset päivitykset:

  Mahdollistaa sovelluksen tiettyjen osien päivittämisen itsenäisesti, mikä vähentää koodin riippuvuuksia.

• Minimoitu käyttökatko:

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

• Parempi kehityksen ketteryys:

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

Lisätietoja Jitterbit App Builder, tai tehokas tekoälyominaisuuksien kokonaisuus tulossa pian App Builder 4.0:aan.