5 suggerimenti per rilasci di applicazioni più efficaci

Di Tim Bond, Product Manager

I team di sviluppo low-code dedicano una notevole quantità di tempo ed energia alla definizione dell'ambito e allo sviluppo del prossimo set di funzionalità per le loro applicazioni low-code. Sviluppare app robuste che forniscano i risultati attesi è della massima importanza. Ma il processo di spostamento dell'applicazione da un ambiente di sviluppo, attraverso un ambiente di test e in un ambiente di produzione o live è troppo spesso un ripensamento.

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

• Quando inizierà la distribuzione e quanto tempo ci vorrà?

  Collabora con gli stakeholder per identificare un momento in cui saranno minimamente impattati. La durata è difficile da prevedere: più lo fai, meglio sarai in grado di stimarla. Prometti poco e mantieni più del dovuto rispetto alla tua stima.

• Quale sarà l'impatto del rilascio sugli utenti finali?

  Non importa quanto bene comunichi le release e i tempi di inattività pianificati in anticipo, devi dare per scontato che un utente sarà nell'applicazione se può esserlo. Questo potrebbe non essere un problema, ma se lo fosse, potresti prendere in considerazione di proibire 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 stanno eseguendo i passaggi. Prendetevi del tempo per rivedere il piano insieme e sottolineate che non ci sono domande stupide quando si tratta di chiarezza sul piano di rilascio. Assicuratevi che ogni individuo abbia l'accesso corretto per eseguire i passaggi che gli sono stati assegnati.

• Quali nuovi punti di connessione/integrazione con applicazioni di terze parti verranno introdotti?

  La prima volta che una connessione o un'integrazione viene attivata, ci sarà un po' di incertezza nella mente del team. Una chiave API errata o un traffico di rete bloccato potrebbero mettere i bastoni tra le ruote al piano. Gli sviluppatori dovrebbero fare in modo di segnalarlo al team in modo che la nuova connessione possa essere pianificata in modo appropriato.

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

  Questo non è mai il risultato atteso o desiderato, ma avere un piano in anticipo guiderà il team durante una situazione di stress.

Hai una sola possibilità di avere un go-live di successo al primo tentativo. Ti consiglio di usare un test o una release di staging come prova generale per la produzione per risolvere eventuali problemi.

Quando si tratta di Jitterbit App Builder release dell'applicazione, i tuoi sviluppatori creano una release dall'ambiente di sviluppo, scaricano il file di release (lo chiamiamo file LP) e lo caricano nell'ambiente di destinazione per essere installato. Ci sono un paio di rischi comuni che dovresti controllare due volte prima di creare la release e installarla in produzione:

• Opzioni di installazione della tabella:

  Il più delle volte, avrai tabelle fisiche incluse nella tua release. Ogni tabella ha un'impostazione di opzione di installazione che determina come i dati archiviati nella tabella vengono gestiti quando la release viene creata e successivamente installata in un ambiente di destinazione. Questa è una capacità potente, ma dovrebbe essere usata con cautela. Sicuramente non vuoi sostituire i dati di produzione di qualità con tutti i dati creati dagli sviluppatori. Puoi scoprire di più su queste opzioni sul nostro Creare una pagina di documentazione del pacchetto di rilascio.

• ruoli:

  L'accesso a una pagina, così come le capacità native di creazione/modifica/eliminazione dei dati mostrati a un utente su una pagina, sono controllate 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 indesiderato sulla capacità di un particolare gruppo di utenti di accedere alla pagina. Creare un utente di prova per ogni gruppo di utenti e testare la regressione per i ruoli è un'ottima pratica prima di qualsiasi rilascio in produzione. Ciò ti aiuterà a evitare la temuta e-mail "Non riesco più ad accedere a questa pagina" dal tuo utente finale il giorno dopo un rilascio. Dai un'occhiata a questa pagina di documentazione per maggiori informazioni su privilegi e permessi.

Ogni volta che vai a rilasciare il tuo Jitterbit App Builder applicazione, esamina attentamente il modello di rilascio. Dovresti rilasciare solo i componenti dell'applicazione che sono cambiati e che vuoi rilasciare in produzione.

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

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

• Aggiornamenti modulari:

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

• Tempi di inattività ridotti al minimo:

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

• Maggiore agilità di sviluppo:

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

Scopri di più sui jitterbit App Buildero potente suite di funzionalità AI in arrivo a breve App Builder 4.0.