5 consigli per rilasci di applicazioni più efficaci

Di Tim Bond, Product Manager

I team di sviluppo low-code dedicano una quantità considerevole di tempo ed energia alla definizione dell'ambito e allo sviluppo del set successivo di funzionalità per le loro applicazioni low-code. Sviluppare app robuste che diano i risultati attesi è della massima importanza. Ma il processo di trasferimento dell'applicazione da un ambiente di sviluppo, attraverso un ambiente di test, a un ambiente di produzione o attivo è troppo spesso un aspetto secondario.

Avere un piano ben definito e ben comunicato per il rilascio di un'applicazione in un ambiente di produzione è la parte singola più importante di un go-live. Ecco alcuni elementi a cui dovresti pensare prima di effettuare qualsiasi rilascio:

• Quando avrà inizio il rilascio e quanto tempo ci vorrà?

  Lavora con gli stakeholder per individuare un momento in cui subiranno il minor impatto possibile. La durata è difficile da prevedere: più lo fai, meglio sarai in grado di stimarla. Prometti meno e offri di più rispetto alle tue stime.

• In che modo gli utenti finali saranno influenzati durante il rilascio?

  Non importa quanto bene comunichi in anticipo le versioni e i tempi di inattività pianificati, devi dare per scontato che un utente sarà nell'applicazione se può esserlo. Questo potrebbe non essere un problema, ma se lo è, potresti prendere in considerazione l'idea di vietare l'accesso all'applicazione durante il periodo di manutenzione.

• Chi è responsabile di ogni fase del processo di rilascio?

  Un piano dettagliato dovrebbe essere condiviso con il team di persone che eseguono le fasi. Prendetevi il tempo per rivedere il piano insieme e sottolineate che non ci sono domande stupide quando si tratta di fare chiarezza sul piano di rilascio. Assicuratevi che ogni singolo individuo abbia il corretto accesso per eseguire i passaggi che gli sono stati assegnati.

• Quali nuovi collegamenti/punti di integrazione con applicazioni di terze parti vengono introdotti?

  La prima volta che una connessione o un'integrazione viene messa online, ci sarà sempre un po' di incertezza nella mente del team. Una chiave API errata o del traffico di rete bloccato potrebbero mandare all'aria i piani. Gli sviluppatori dovrebbero fare in modo di evidenziarlo al team, affinché la nuova connessione possa essere pianificata adeguatamente.

• Se il rilascio non va a buon fine, qual è il piano di rollback?

  Questo non è mai il risultato previsto né desiderato, ma avere un piano in anticipo guiderà il team durante una situazione stressante.

Hai solo una possibilità di avere un go-live di successo al primo tentativo. Suggerisco di usare una release di test o di staging come prova generale per la produzione per risolvere qualsiasi problema.

Per quanto riguarda le versioni dell'applicazione Jitterbit App Builder, i vostri sviluppatori creano una versione dall'ambiente di sviluppo, scaricano il file di rilascio (che chiamiamo file LP) e lo caricano nell'ambiente di destinazione per l'installazione. Esistono alcuni rischi comuni che dovreste verificare attentamente prima di creare la versione e installarla in produzione:

• Opzioni di installazione del tavolo:

  Il più delle volte, la release includerà tabelle fisiche. Ciascuna tabella dispone di un'impostazione di opzione di installazione che determina come vengono gestiti i dati memorizzati nella tabella quando la release viene creata e successivamente installata in un ambiente di destinazione. Si tratta di una funzionalità potente, che tuttavia va utilizzata con cautela. È assolutamente sconsigliato sostituire i dati di produzione di qualità con tutti i dati creati dagli sviluppatori. Potete trovare ulteriori informazioni su queste opzioni sul nostro Crea una pagina di documentazione per il pacchetto di rilascio.

• Ruoli:

  L'accesso a una pagina, così come le funzionalità native di creazione/modifica/eliminazione dei dati mostrati a un utente su una pagina, è controllato in modo granulare nel livello logico. Ogni volta che uno sviluppatore modifica i ruoli di una regola aziendale o introduce una nuova regola aziendale in una pagina, ciò potrebbe avere un effetto imprevisto sulla capacità di un determinato gruppo di utenti di accedere alla pagina. Creare un utente di test per ciascun gruppo di utenti ed eseguire test di regressione per i ruoli è un'ottima pratica prima di qualsiasi rilascio in produzione. Questo vi aiuterà a evitare la temuta email “Non riesco più ad accedere a questa pagina” da parte dell'utente finale il giorno dopo un rilascio. Dai un'occhiata questa pagina di documentazione per ulteriori informazioni su privilegi e autorizzazioni.

Ogni volta che si procede al rilascio dell'applicazione Jitterbit App Builder, è necessario esaminare attentamente il modello di rilascio. È necessario rilasciare solo i componenti dell'applicazione che sono stati modificati e che si desidera mettere in produzione.

Nel tuo modello di rilascio, puoi scegliere questi diversi componenti. Puoi, ovviamente, rilasciare un'applicazione intera che includerà tutte le origini dati, la logica e le pagine. Oppure, se la tua modifica è stata su scala ridotta, potresti rilasciare solo una singola pagina o una singola regola aziendale e rilasciare quei componenti più piccoli in produzione, lasciando il resto dell'applicazione così com'è. Questa flessibilità nel processo di rilascio consente al vostro team di sviluppo di rispondere più facilmente a qualsiasi problema critico che si presenta durante il lavoro sulle richieste più grandi.

La funzionalità dei componenti applicativi migliora la flessibilità, la velocità e il controllo sul processo di distribuzione del software, rendendola uno strumento potente in ambienti che richiedono aggiornamenti frequenti e tempi di inattività minimi. I principali vantaggi per i vostri team di sviluppo sono:

• Aggiornamenti Modulari:

  Consente di aggiornare componenti specifici di un'applicazione in modo indipendente, riducendo le dipendenze del codice.

• Tempo di inattività ridotto al minimo:

  Vengono aggiornati solo i componenti modificati, consentendo aggiornamenti più fluidi.

• Maggiore agilità di sviluppo:

  I team possono rilasciare rapidamente aggiornamenti o patch per i singoli componenti, migliorando i tempi di risposta.

Scopri di più Jitterbit App Builder, o il una potente suite di funzionalità basate sull'intelligenza artificiale in arrivo su App Builder 4.0.