Filiali¶

Panoramica¶

La visualizzazione dei rami offre una panoramica dei vari rami che compongono un archivio.

Fasi¶

Odoo.sh offre tre fasi diverse per i rami: produzione, staging e sviluppo.

È possibile modificare la fase di un ramo trascinandolo e rilasciandolo all’interno della sezione desiderata.

Produzione¶

Si tratta del ramo che contiene il codice utilizzato per l’esecuzione del database di produzione. È possibile avere un solo ramo di produzione.

Quando esegui un nuovo commit in questo ramo, il server di produzione viene aggiornato con il codice della nuova revisione per poi essere riavviato.

Se le modifiche richiedono l’aggiornamento di un modulo, come una modifica in una vista modulo e vuoi che venga eseguito automaticamente, aumenta il numero della versione del modulo nel manifesto (__manifest__.py). In seguito, la piattaforma si occuperà di eseguire l’aggiornamento durante il quale l’istanza sarà temporaneamente non disponivile per motivi di manutenzione.

Il metodo equivale a eseguire un aggiornamento del modulo tramite il menu delle app o attraverso l’opzione -u della riga di comando.

Nel caso in cui le modifiche nel commit impediscano al server di riavviarsi oppure se l’aggiornamento dei moduli fallisce, il server verrà ripristinato automaticamente alla revisione del codice precedente e il database verrà ripristinato alla versione precedente l’aggiornamento. Avrai ancora accesso al registro dell’aggiornamento che non è andato a buon fine così da poter risolvere il problema.

I dati demo non vengono caricati in quanto non vengono utilizzati in un database di produzione. I test di unità non vengono eseguiti perché aumenterebbero il tempo di non disponibilità del database di produzione durante gli aggiornamenti.

I partner che utilizzato progetti di prova devono essere consapevoli del fatto che il loro ramo di produzione, così come i rami di staging, verranno reimpostati automaticamente alla fase di sviluppo dopo 30 giorni.

Staging¶

I rami di staging servono a testare le nuove funzionalità utilizzando i dati di produzione senza compromettere il database di produzione corrente con record di prova. Verranno creati database che sono duplicati neutralizzati del database di produzione.

La neutralizzazione include:

• la disabilitazione delle azioni programmate. Se vuoi provarle, puoi attivare manualmente le azioni o riabilitarle. Tieni presente che la piattaforma le eseguirà in maniera meno frequente se nessuno utilizza il database, al fine di risparmiare risorse.

• La disabilitazione delle e-mail in uscita intercettandole con un mailcatcher. Viene fornita anche una interfaccia oer visualizzare le e-mail inviate dal tuo database. In questo modo, non devi preoccuparti dell’invio di e-mail di prova ai tuoi contatti.

• La configurazione di fornitori di servizi di pagamento e di spedizione in modalità test.

• Disabilitare servizi IAP

L’ultimo database verrà conservato a vita, quelli più vecchi appartenenti allo stesso ramo potrebbero essere cestinati per fare spazio ai nuovi. Sarà valido per 3 mesi dopo i quali dovrai ricostruire il ramo. Se modifichi le impostazioni o le viste nei database, assicurati di documentare le modifiche o scriverle nei moduli del ramo utilizzando file dati XML sovrascrivendo le configurazioni o le viste predefinite.

In Odoo, i unit test non vengono eseguiti perché si basano su dati di prova che non vengono caricati nel database di produzione, Nel futuro, se Odoo supporterà l’esecuzione di unit test senza utilizzare dati di prova, Odoo.sh valuterà la possibilità di eseguire i test su database di staging.

Sviluppo¶

I rami di sviluppo creano nuovi database utilizzando dati di prova per eseguire unit test. I moduli installati sono quelli inclusi nei rami. È possibile modificare l’elenco dei moduli da installare dalle Impostazioni di progetto.

Al momento dell’esecuzione di un commit in uno dei rami, verrà avviato un nuovo server con un database creato da capo e la nuova revisione del ramo. I dati di prova vengono caricati e in seguito vengono eseguiti unit test in maniera predefinita. Il processo permette di verificare che le modifiche non compromettano nessuna delle funzionalità testate. Se lo desideri, è possibile disabilitare i test o consentire test specifici da eseguire con tag personalizzati dalle impostazioni del ramo.

Le e-mail, simili a i rami di staging, non vengono inviate ma sono intercettate da un mailcatcher e le azioni programmate non vengono eseguite quando il database non è in uso.

I database creati per i rami di sviluppo saranno attivi per 3 giorni all’incirca. Dopodiché, possono essere eliminati per fare spazio a nuovi database senza preavviso.

Unificare i rami¶

È possibile unire i rami facilmente, trascinandoli e rilasciandoli.

Al fine di testare le modifiche dei rami di sviluppo con i dati di produzione, è possibile:

• unire il ramo di sviluppo con il ramo di staging, trascinandolo e rilasciandolo nel ramo di staging desiderato.

• Trascinare e rilasciare il ramo di sviluppo nella sezione titolo staging per renderlo un ramo.

Quando le ultime modifiche saranno pronte per la produzione, è possibile trascinare e rilasciare il ramo di staging nel ramo di produzione per unirli e distribuire le nuove funzionalità in produzione.

Se sei abbastanza coraggioso, puoi unire i rami di sviluppo con il ramo di produzione. Significa saltare la convalida delle modifiche con i dati di oroduzione attraverso un ramo di staging.

Puoi unire i rami di sviluppo e i rami di staging tra loro.

Per unire i rami, ovviamente è anche possibile utilizzare git merge direttamente nella stazione di lavoro. Odoo.sh riceverà una notifica quando le nuove revisioni verranno integrate nei rami.

L’unione di un ramo di staging con un ramo di produzione comporta solo l’unione del codice sorgente: qualsiasi modifica relativa alle impostazioni realizzata nei database di staging non viene trasferita al database di produzione.

Se le impostazioni del test cambiano nei rami di staging e vuoi che vengano applicate in produzione, puoi:

• scrivere le modifiche relative alle impostazioni in un file dati XML che sostituiranno le impostazioni o le viste predefinite nei rami. In seguito, la versione del modulo aumenterà nel manifesto (__manifest__.py) per attivare l’aggiornamento del modulo al momento dell’unione del ramo di staging con il ramo di produzione. Questa è la pratica più adatta per ottenere una migliore scalabilità degli sviluppi in quanto utilizzerai le funzionalità di versionamento Git per tutte le modifiche relative alle impostazioni e quindi otterrai tracciabilità delle modifiche apportate.

• Trasferire manualmente le modifiche dal database di staging a quello di produzione tramite la funzione copia/incolla.

Schede¶

Storia¶

Una panoramica della cronologia del ramo:

• i messaggi dei commit e i rispettivi autori;

• i vari eventi collegati alla piattaforma, come le modifiche di fase, le importazioni dei database, il ripristino di backup.

Nell’angolo in alto a destra, viene visualizzato lo stato di ogni evento. Può fornire informazioni su operazioni in corso sul database (installazione, aggiornamento, importazione backup…) o i risultati (feedback test, importazione backup riuscita…). Quando un’operazione avviene con successo, è possibile accedere al database grazie al pulsante connessione.

E-mail¶

Questa scheda contiene il mailcatcher e mostra una panoramica delle e-mail inviate al tuo database. Il mailcatcher è disponibile per i rami di sviluppo e staging in quanto le e-mail del database di produzione vengono davvero inviate e non solo intercettate.

Shell¶

Accesso all’interprete dei comandi (shell) nel contenitore. È possibile eseguire comandi linux di base (ls, top) e aprire una shell nel database digitando psql.

Puoi aprire più schede e trascinarle e rilasciarle per organizzare il layout come preferisci, ad esempio una accanto all’altra.

Redattore¶

Ambiente di sviluppo integrato online (IDE) per modificare il codice sorgente. È possibile aprire terminali, console Python e anche console Odoo Shell.

Puoi aprire più schede e trascinarle e rilasciarle per organizzare il layout come preferisci, ad esempio una accanto all’altra.

Monitoraggio¶

Il presente link contiene varie metriche di monitoraggio per il build attuale.

È possibile ingrandire, modificare l’intervallo di tempo o selezionare una metrica specifica per ogni grafico. Le annotazioni nei grafici ti aiutano a individuare i cambiamenti nel build (importazione database, esecuzione git, ecc.).

Log¶

Un visualizzatore per dare un’occhiata ai registri del server.

Sono disponibili vari registri:

• install.log: i registri relativi all’installazione del database. Nel ramo di sviluppo, sono inclusi i registri dei test.

• pip.log: i registri dell’installazione delle dipendenze Python.

• odoo.log: i registri per il server in esecuzione.

• update.log: i registri per gli aggiornamenti del database.

• pg_long_queries.log: i registri delle query psql che richiedono un periodo di tempo insolito.

Se vengono aggiunte nuove righe ai registri,

È possibile mettere in pausa il recupero dei registri facendo clic sul pulsante corrispondente nell’angolo in alto a destra della vista. Il recupero viene interrotto automaticamente dopo 5 minuti. È possibile riavviarlo utilizzando il pulsante di avvio.

Backup¶

Elenco dei backup disponibili per il download e il ripristino, la possibilità di eseguire un backup manuale e importare un database.

Odoo.sh esegue backup giornalieri del database di produzione e nello specifico: 7 al giorno, 4 a settimana e 3 mensili. Ogni backup include il dump del database, il filestore (allegati, campi binari), registri e sessioni.

Per i database di staging e sviluppo il backup non viene eseguito. Ciononostante, hai la possibilità di ripristinare un backup del database di produzione nei rami di staging, a scopo di test o per recuperare manualmente dati che sono stati eliminati accidentalmente dal database di produzione stesso.

L’elenco contiene i backup salvati nel server che ospita il tuo database di produzione. Il server conserva solo backup di un mese: 7 giornalieri e 4 settimanali.

I server dedicati al backup conservano gli stessi backup e 3 backup mensili aggiuntivi. Per ripristinare o scaricare uno di questi, contattaci all’indirizzo.

Se unisci un commit che aggiorna la versione di uno o più moduli (in __manifest__.py) o le dipendenze python collegate (in requirements.txt), Odoo.sh eseguirà un backup in automatico (contrassegnate dal tipo di aggiornamento nell’elenco) perché il contenitore verrà modificato dall’installazione di nuovi pacchetti pip o il database verrà modificato con l’aggiornamento del modulo attivato in seguito. In questi due casi, realizziamo un backup in quanto potrebbero verificarsi problemi.

Se unisci un commit che modifica solamente una parte del codice, senza apportare le modifiche citate in precedenza, Odoo.sh non effettuerà nessun backup perché né il contenitore né il database verranno modificati quindi la piattaforma lo ritiene un comportamento abbastanza sicuro. Come ulteriore precauzione, puoi eseguire un backup manualmente prima di apportare notevoli modifiche alle risorse di produzione in caso qualcosa vada storto (i backup manuali sono disponibili per una settimana circa). Per evitare l’abuso, limitiamo i backup manuali a 5 al giorno.

La funzionalità Importa database accetta archivi database nei formati forniti da:

• il gestore standard di database Odoo (disponibile per server Odoo on-premise su /web/database/manager)

• Il gestore online di database Odoo.

• Il pulsante di download del backup Odoo.sh nella finestra «Backup».

• Il pulsante di download del dump Odoo.sh nella Vista build.

Aggiorna¶

Disponibile per i rami di produzione e staging per progetti validi.

Impostazioni¶

Qui puoi trovare un paio di impostazioni che si applicano solo al ramo selezionato.

Comportamento a seguito di un nuovo commit

Per i rami di sviluppo e di staging, è possibile modificare il comportamento del ramo dopo aver ricevuto un nuovo commit. Per impostazione predefinita, un ramo di sviluppo porterà alla creazione di un nuovo build e un ramo di staging aggiornerà il build precedente (vedi Fase di produzione). Si tratta di una pratica utile se la funzionalità sulla quale stai lavorando richiede una configurazione particolare, per evitare di doverla configurare manualmente per ogni commit. Se scegli un nuovo build per un ramo di staging, ogni volta che viene eseguito un commit verrà creata una nuova copia dal build di produzione. Un ramo che passa da staging a sviluppo verrà impostato automaticamente su «Non fare nulla».

Installazione dei moduli

Scegli i moduli da installare automaticamente per i build di sviluppo.

• Installa solo i miei moduli installerà solo i moduli del ramo. Si tratta di un’impostazione predefinita. I moduli secondari sono esclusi.

• Installazione completa (tutti i moduli) installerà i moduli del ramo, i moduli inclusi nei moduli secondari e tutti i moduli standard di Odoo. Durante l’esecuzione dell’installazione completa, il gruppo di test è disabilitato.

• Installa un elenco di moduli installerà solo i moduli specificati nell’inserimento in basso all’opzione. I nomi corrispondono ai nomi tecnici dei moduli e devono essere separati da virgole.

Se i test sono abilitati, l’insieme di moduli standard Odoo può impiegare fino ad 1 ora. L’impostazione si applica solo ai build di sviluppo. I build di staging duplicano il build di produzione e il build di produzione installa solo la base.

Gruppo di test

Per i rami di sviluppo, puoi scegliere di abilitare o disabilitare il gruppo di test, abilitato per impostazione predefinita. Se abilitato, puoi limitarlo specificando i tag del test.

Versione Odoo

Solo per i rami di sviluppo, è possibile modificare la versione di Odoo se vuoi testare il codice aggiornato o sviluppare funzionalità mentre il database di produzione è in fase di aggiornamento.

Inoltre, per ogni versione hai due opzioni relative all’aggiornamento del codice.

• Puoi scegliere di beneficiare delle ultime correzioni di bug, sicurezza e prestazioni automatiche. Le fonti del server Odoo verranno aggiornate settimanalmente. Questa è «l’ultima» opzione.

• Puoi scegliere di fissare le fonti Odoo in una revisione specifica selezionandole dall’elenco delle date. Le revisioni scadranno dopo 3 mesi. Riceverai una notifica via e-mail quando la data di scadenza sarà vicina e se non agisci verrai portato automaticamente all’utlima revisione.

Domini personalizzati

Qui puoi configurare domini aggiuntivi per il ramo selezionato. È possibile aggiungere altri domini <name>.odoo.com o i tuoi domini personalizzati. Nell’ultimo caso, è necessario:

• essere proprietario o acquistare il nome di dominio;

• aggiungere il nome di dominio all’elenco;

• configurare il nome di dominio con un record CNAME impostato come nome di dominio del database di produzione dal gestore dei nomi di dominio del registrar.

Ad esempio, per associare www.mycompany.com al tuo database mycompany.odoo.com:

• in Odoo.sh, aggiungi www.mycompany.com tra i domini personalizati dalle impostazioni di progetto,

• nel gestore dei nomi di dominio (ad es. godaddy.com, gandi.net, ovh.com) imposta un record CNAME per www.mycompany.com con mycompany.odoo.com come valore.

I domini semplici (ad es. mycompany.com) non sono accettati:

• possono essere configurati solo utilizzando record A;

• i record A accettano solo indirizzi IP come valori;

• l’indirizzo IP del tuo database può cambiare a seguito di un aggiornamento, del fallimento dell’hardware o del desiderio di ospitare il database in un altro Paese o continente.

Di conseguenza, i domini semplici possono smettere di funzionare a causa delle modifiche apportate all’indirizzo IP.

Inoltre, se vorresti far funzionare sia mycompany.com che www.mycompany.com con il tuo database, il fatto che il primo rimandi al secondo, fa parte delle migliori pratiche SEO (consulta la pagina Fornire la versione di un URL per raggiunger un documento) per avere un URL dominante. Di conseguenza, puoi configurare solo mycompany.com per il reindirizzamento verso www.mycompany.com. La maggior parte dei gestori di dominio hanno la funzionalitò per configurare il reindirizzamento, nota come reindirizzamento web.

HTTPS/SSL

Se il reindirizzamento viene configurato correttamente, la piattaforma genererà, nel giro di un’ora, un certificato SSL in automatico con Let’s Encrypt e il tuo dominio sarà accessibile attraverso HTTPS.

Dato che non è possibile attualmente configurare le tue certificazioni SSL sulla piattaforma Odoo.sh, stiamo considerando di sviluppare la funzionalità se la richiesta è notevole.

Conformità SPF e DKIM

In case the domain of your users email addresses use SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail), don’t forget to authorize Odoo as a sending host in your domain name settings to increase the deliverability of your outgoing emails. The configuration steps are explained in the documentation about SPF and DKIM.

Comandi shell¶

Nell’angolo in alto a destra della vista, sono disponibili vari comandi shell.

Ogni comando può essere copiato negli appunti e utilizzato in un terminale e alcuni di loro possono essere utilizzati direttamente su Odoo.sh facendo clic sul pulsante run. In questo caso una finestra popup richiederà all’utente di definire eventuali segnaposto come <URL>, <PATH>, …

Clonare¶

Scarica l’archivio Git.

$ git clone --recurse-submodules --branch master git@github.com:odoo/odoo.git

Clona l’archivio odoo/odoo.

• --recurse-submodules: scarica i moduli secondari del tuo archivio. Vengono scaricati anche i moduli secondari inclusi nei moduli secondari.

• --branch: verifica un ramo specifico dell’archiviso, in questo caso master.

Il pulsante run non è disponibile per questo comando, in quanto è progettato per essere utilizzato sui tuoi dispositivi.

Fork¶

Crea un nuovo ramo basato sul ramo attuale.

$ git checkout -b feature-1 master

Crea un nuovo ramo chiamato feature-1 basato sul ramo master e in seguito lo verifica.

$ git push -u origin feature-1

Carica il nuovo ramo feature-1 nell’archivio remoto.

Accorpa¶

Unisce il ramo attuale con un altro ramo.

$ git merge staging-1

Unisce il ramo staging-1 al ramo attuale.

$ git push -u origin master

Carica le modifiche appena aggiunte nel ramo master nell’archivio remoto.

SSH¶

Imposta¶

Per utilizzare SSH, è necessario configurare la chiave pubblica SHH del tuo profilo (se non è stato già fatto). Per farlo, segui questi step:

1. genera una nuova chiave SSH;

2. copia la chiave SSH negli appunti (vale solo per il primo step);

3. incolla il contenuto copiato nelle chiavi SSH del tuo profilo e fai clic su «Aggiungi»

   

4. La chiave dovrebbe apparire in basso

   

Connessione¶

Per connetterti ai build utilizzando ssh, utilizza il seguente comando in un terminale:

$ ssh <build_id>@<domain>

Troverai una scelta rapida per il comando nella scheda SSH nell’angolo in alto a destra.

Se disponi dei diritti di accesso corretti per il progetto, ti sarà garantito l’accesso ssh al build.

Modulo secondario¶

Aggiungi un ramo da un altro archivio nel tuo ramo corrente come modulo secondario.

I moduli secondari consentono di utilizzare moduli da altri archivi nei progetti.

La funzione dei moduli secondari è descritta in dettaglio nel capitolo Moduli secondari della documentazione.

$ git submodule add -b master <URL> <PATH>

Aggiunge il ramo master dell’archivio <URL> come modulo secondario nel percorso <PATH> nel ramo corrente.

$ git commit -a

Conferma tutti i cambiamenti attuali.

$ git push -u origin master

Carica le modifiche appena aggiunte nel ramo master nell’archivio remoto.

Elimina¶

Elimina un ramo dall’archivio.

$ git push origin :master

Elimina il ramo nell’archivio remoto.

$ git branch -D master

Elimina il ramo dalla copia locale dell’archivio.