Branches¶
Overzicht¶
De vertakkingenweergave geeft je een overzicht van de verschillende vertakkingen die jouw repository heeft.
Fases¶
Odoo.sh biedt drie verschillende fasen voor jouw branches: productie, staging en ontwikkeling.
Je kunt de fase van een vertakking wijzigen door deze naar de titel van de fasesectie te slepen en neer te zetten.
Productie¶
Dit is de vertakking die de code bevat waarop jouw productiedatabase draait. Er kan slechts één productietak zijn.
Wanneer je een nieuwe commit in deze branch pusht, wordt jouw productieserver bijgewerkt met de code van de nieuwe revisie en vervolgens opnieuw opgestart.
Als jouw wijzigingen de update van een module vereisen, zoals een wijziging in een formulierweergave, en je wilt dat deze automatisch wordt uitgevoerd, verhoogt je het versienummer van de module in het manifest (__manifest__.py). Het platform zorgt er vervolgens voor dat de update wordt uitgevoerd, waarbij de instance vanwege onderhoudsredenen tijdelijk niet beschikbaar zal zijn.
Deze methode is gelijk aan het uitvoeren van een upgrade van de module via het Apps-menu, of via de -je-schakelaar van de opdrachtregel.
In het geval dat de wijzigingen in de commit voorkomen dat de server opnieuw opstart, of als de module-update mislukt, wordt de server automatisch teruggezet naar de vorige succesvolle coderevisie en wordt de database teruggedraaid zoals deze was vóór de update. Je hebt nog steeds toegang tot het logboek van de mislukte update, zodat je deze kunt oplossen.
De demogegevens worden niet geladen, omdat deze niet bedoeld zijn voor gebruik in een productiedatabase. De unit-tests worden niet uitgevoerd, omdat dit de onbeschikbaarheid van de productiedatabase tijdens de updates zou verlengen.
Partners die proefprojecten gebruiken, moeten zich ervan bewust zijn dat hun productietak, samen met alle staging-takken, na 30 dagen automatisch teruggezet wordt naar de ontwikkelingsfase.
Staging¶
Staging branches zijn bedoeld om jouw nieuwe functies te testen met behulp van de productiegegevens zonder de daadwerkelijke productiedatabase met testrecords in gevaar te brengen. Ze zullen databases creëren die geneutraliseerde duplicaten zijn van de productiedatabase.
De neutralisatie omvat:
Geplande acties uitschakelen. Als je ze wilt testen, kunt je hun actie handmatig activeren of opnieuw inschakelen. Houd er rekening mee dat het platform ze minder vaak activeert als niemand de database gebruikt om bronnen te besparen.
Het uitschakelen van uitgaande e-mails door deze te onderscheppen met een mailcatcher. Een :ref:`interface om te bekijken<odoosh-gettingstarted-branches-tabs-mails> ` de e-mails die door jouw database zijn verzonden, worden verstrekt. Zo hoeft je zich geen zorgen te maken over het versturen van testmails naar jouw contacten.
Betalingsproviders en verzendproviders in testmodus zetten.
IAP-services jeitschakelen
De nieuwste database zal voor onbepaalde tijd in leven worden gehouden, oudere databases uit dezelfde branche kunnen afval worden verzameld om ruimte te maken voor nieuwe. De geldigheidsduur is 3 maanden, daarna wordt van je verwacht dat je het filiaal weer opbouwt. Als je configuraties uitvoert of wijzigingen bekijkt in deze databases, zorg er dan voor dat je deze documenteert of rechtstreeks in de modules van het filiaal schrijft, waarbij je XML-gegevensbestanden gebruikt die de standaardconfiguratie of -views overschrijven.
De unit-tests worden niet uitgevoerd omdat ze in Odoo momenteel afhankelijk zijn van de demogegevens, die niet in de productiedatabase zijn geladen. Als Odoo het in de toekomst ondersteunt om de unit-tests uit te voeren zonder de demogegevens, zal Odoo.sh overwegen om de tests uit te voeren op staging-databases.
Ontwikkeling¶
Ontwikkelingstakken creëren nieuwe databases met behulp van de demogegevens om de unit-tests uit te voeren. De geïnstalleerde modules zijn de modules die in jouw filialen aanwezig zijn. Je kunt deze lijst met te installeren modules wijzigen in jouw :ref:`projectinstellingen<odoosh-gettingstarted-settings-modules-installation> `.
Wanneer je een nieuwe commit in een van deze branches pusht, wordt er een nieuwe server gestart, met een database die helemaal opnieuw is gemaakt en de nieuwe revisie van de branch. De demogegevens worden geladen en de unittests worden standaard uitgevoerd. Dit verifieert dat jouw wijzigingen geen van de door hen geteste functies verbreken. Als je wilt, kunt je de tests uitschakelen of toestaan dat specifieke tests worden uitgevoerd met aangepaste tags in de :ref:`branch’s instellingen<odoosh-gettingstarted-branches-tabs-settings> `.
Net als bij staging branches worden de e-mails niet verzonden maar onderschept door een mailcatcher en worden geplande acties niet geactiveerd zolang de database niet in gebruik is.
De databases die voor ontwikkelingstakken zijn gemaakt, zijn bedoeld voor een levensduur van ongeveer drie dagen. Daarna kunnen ze automatisch worden verzameld om ruimte te maken voor nieuwe databases, zonder voorafgaande kennisgeving.
Het samenvoegen van jouw vestigingen¶
Je kunt je takken eenvoudig samenvoegen door ze in elkaar te slepen en neer te zetten.
Wanneer je de wijzigingen van jouw ontwikkelingstakken wilt testen met de productiegegevens, kunt je:
voeg de ontwikkelingstak samen met je staging branch, door deze naar de gewenste staging branch te slepen en neer te zetten,
sleep de ontwikkelingsvertakking naar de titel van de stagingsectie, zodat deze een stagingvertakking wordt.
Wanneer jouw laatste wijzigingen klaar zijn voor productie, kunt je jouw staging branch naar jouw productie branch slepen en neerzetten om jouw nieuwste functies samen te voegen en in productie te implementeren.
Als je moedig genoeg bent, kun je je ontwikkelingstakken ook samenvoegen met je productietak. Het betekent alleen dat je de validatie van jouw wijzigingen met de productiegegevens via een staging-branch overslaat.
Je kunt jouw ontwikkelingstakken in elkaar samenvoegen, en jouw staging-takken in elkaar.
Natuurlijk kun je git merge ook rechtstreeks op je werkstation gebruiken om je branches samen te voegen. Odoo.sh wordt op de hoogte gesteld wanneer er nieuwe revisies in jouw branches zijn gepusht.
Het samenvoegen van een staging-branch in de productietak voegt alleen de broncode samen: eventuele configuratiewijzigingen die je in de staging-databases hebt aangebracht, worden niet doorgegeven aan de productiedatabase.
Als je configuratiewijzigingen in faseringsvertakkingen test en wilt dat deze in de productie worden toegepast, moet je het volgende doen:
schrijf de configuratiewijzigingen in XML-gegevensbestanden die de standaardconfiguratie of views in jouw branches overschrijven, en verhoog vervolgens de versie van jouw module in zijn manifest (__manifest__.py) om de update van de module te activeren wanneer je jouw staging branch samenvoegt jouw productietak. Dit is de beste praktijk voor een betere schaalbaarheid van jouw ontwikkelingen, aangezien je de Git-versiebeheerfuncties voor al jouw configuratiewijzigingen zult gebruiken en daardoor traceerbaarheid voor jouw wijzigingen heeft.
geef ze handmatig door van jouw staging naar jouw productiedatabase, door ze te kopiëren/plakken.
Tabbladen¶
Geschiedenis¶
Een overzicht van jouw filiaalgeschiedenis:
De berichten van de commits en hun auteurs,
De verschillende gebeurtenissen die aan het platform zijn gekoppeld, zoals fasewijzigingen, database-importen en back-upherstel.
Voor elke gebeurtenis wordt rechtsboven een status weergegeven. Het kan informatie geven over de lopende bewerking op de database (installatie, update, back-upimport, …) of het resultaat ervan (testfeedback, succesvolle back-upimport, …). Wanneer een operatie succesvol is, kunt je via de knop connect toegang krijgen tot de database.
E-mails¶
Dit tabblad bevat de postvanger. Het toont een overzicht van de e-mails die door jouw database zijn verzonden. De mailcatcher is beschikbaar voor jouw ontwikkelings- en stagingbranches, omdat de e-mails van jouw productiedatabase daadwerkelijk worden verzonden in plaats van onderschept.
Schelp¶
Een shell-toegang tot jouw container. Je kunt standaard Linux-commando’s uitvoeren (ls, top) en een shell in je database openen door psql te typen.
Je kunt meerdere tabbladen openen en deze slepen en neerzetten om de indeling naar wens in te delen, bijvoorbeeld naast elkaar.
Notitie
Langlopende shell-instances zijn niet gegarandeerd. Inactieve shells kunnen op elk moment worden losgekoppeld om bronnen vrij te maken.
Editor¶
Een online geïntegreerde ontwikkelomgeving (IDE) om de broncode te bewerken. Je kunt ook terminals, Python-consoles en zelfs Odoo Shell-consoles openen.
Je kunt meerdere tabbladen openen en deze slepen en neerzetten om de indeling naar wens in te delen, bijvoorbeeld naast elkaar.
Monitoring¶
Deze link bevat verschillende monitoringstatistieken van de huidige build.
Je kunt zoomen, het tijdsbereik wijzigen of een specifieke metriek in elke grafiek selecteren. In de grafieken helpen annotaties je om verband te houden met wijzigingen in de build (database-import, git push, enz…).
Logs¶
Een viewer om jouw serverlogboeken te bekijken.
Er zijn verschillende logboeken beschikbaar:
install.log: De logboeken van de database-installatie. In een ontwikkeltak worden de logs van de tests opgenomen.
pip.log: de logboeken van de installatie van Python-afhankelijkheden.
odoo.log: De logs van de actieve server.
update.log: De logboeken van de database-updates.
pg_long_queries.log: De logboeken van psql-query’s die ongebruikelijk veel tijd in beslag nemen.
Als er nieuwe regels in de logs worden toegevoegd, worden deze automatisch weergegeven. Als je naar beneden scrollt, scrollt de browser automatisch elke keer dat er een nieuwe regel wordt toegevoegd.
Je kunt het ophalen van de logboeken onderbreken door op de overeenkomstige knop in de rechterbovenhoek van de weergave te klikken. Het ophalen wordt na 5 minuten automatisch gestopt. Je kunt het opnieuw starten met behulp van de afspeelknop.
Back-ups¶
Een lijst met de back-ups die beschikbaar zijn om te downloaden en te herstellen, de mogelijkheid om een handmatige back-up uit te voeren en een database te importeren.
Odoo.sh maakt dagelijks back-ups van de productiedatabase. Het houdt 7 dagelijkse, 4 wekelijkse en 3 maandelijkse back-ups bij. Elke back-up omvat de databasedump, de filestore (bijlagen, binaire velden), logs en sessies.
Er wordt geen back-up gemaakt van staging- en ontwikkelingsdatabases. Niettemin heeft je de mogelijkheid om voor testdoeleinden een back-up van de productiedatabase in jouw stagingvestigingen terug te zetten, of om handmatig gegevens te herstellen die per ongeluk uit de productiedatabase zijn verwijderd.
De lijst bevat de back-ups die worden bewaard op de server waarop jouw productiedatabase wordt gehost. Deze server bewaart slechts één maand back-ups: 7 dagelijkse en 4 wekelijkse back-ups.
Toegewijde back-upservers bewaren dezelfde back-ups, evenals 3 extra maandelijkse back-ups. Om een van deze maandelijkse back-ups te herstellen of te downloaden, neemt je contact met ons op.
Als je een commit samenvoegt waarbij je de versie van één of meerdere modules bijwerkt (in __manifest__.py), of hun gekoppelde Python-afhankelijkheden (in requirements.txt), dan voert Odoo.sh automatisch een back-up uit (gemarkeerd met het type Update in de lijst), aangezien óf de container zal worden gewijzigd door de installatie van nieuwe pip-pakketten, óf de database zelf zal worden gewijzigd nadat de module-update daarna wordt geactiveerd. In deze twee gevallen maken we een back-up, omdat hierdoor mogelijk dingen kapot kunnen gaan.
Als je een commit samenvoegt die alleen wat code verandert zonder de bovengenoemde wijzigingen, dan wordt er geen back-up gemaakt door Odoo.sh, omdat noch de container, noch de database wordt gewijzigd, dus het platform beschouwt dit als veilig genoeg. Als extra voorzorgsmaatregel kunt je uiteraard handmatig een back-up maken voordat je grote wijzigingen aanbrengt in jouw productiebronnen, voor het geval er iets misgaat (die handmatige back-ups zijn ongeveer een week beschikbaar). Om misbruik te voorkomen beperken wij het handmatig maken van back-ups tot 5 per dag.
De functie database importeren accepteert databasearchieven in het formaat dat wordt aangeboden door:
Bijwerken¶
Beschikbaar voor productie- en staging-vestigingen voor geldige projecten.
Zie ook
Instellingen¶
Hier vindt je een aantal instellingen die alleen van toepassing zijn op de momenteel geselecteerde vestiging.
Gedrag bij nieuwe commit
Voor ontwikkelings- en faseringsvertakkingen kunt je het gedrag van de vertakking wijzigen na ontvangst van een nieuwe commit. Standaard zal een ontwikkelingsvertakking een nieuwe build maken en een staging-vertakking zal de vorige build bijwerken (zie de Production Stage). Dit is vooral handig als de functie waaraan je werkt een bepaalde configuratie of configuratie vereist, om te voorkomen dat je deze bij elke commit handmatig opnieuw moet instellen. Als je een nieuwe build voor een staging branch kiest, zal deze elke keer dat een commit wordt gepusht een nieuwe kopie van de productiebuild maken. Een branch die teruggezet wordt van staging naar development wordt automatisch op ‘Niets doen’ gezet.
Modules installatie
Kies de modules die je automatisch wilt installeren voor jouw ontwikkelingsbuilds.
Installeer alleen mijn modules installeert alleen de modules van de branch. Dit is de standaardoptie. De :ref:`submodules<odoosh-advanced-submodules> ‘ zijn uitgesloten.
Volledige installatie (alle modules) installeert de modules van de vestiging, de modules in de submodules en alle standaardmodules van Odoo. Wanneer je de volledige installatie uitvoert, is de testsuite uitgeschakeld.
Installeer een lijst met modules installeert de modules die zijn opgegeven in de invoer net onder deze optie. De namen zijn de technische namen van de modules en moeten door komma’s worden gescheiden.
Als de tests zijn ingeschakeld, kan de standaard Odoo-modulesuite tot 1 uur duren. Deze instelling is alleen van toepassing op ontwikkelingsbuilds. Staging-builds dupliceren de productie-build en de productie-build installeert alleen de basis.
Test pak
Voor ontwikkelingstakken kunt je ervoor kiezen om de testsuite in of uit te schakelen. Het is standaard ingeschakeld. Wanneer de testsuite is ingeschakeld, kunt je deze beperken door testtags op te geven:ref:testtags <developer/reference/testing/selection>.
Odoo-versie
Alleen voor ontwikkelingstakken kunt je de versie van Odoo wijzigen als je geüpgradede code wilt testen of functies wilt ontwikkelen terwijl jouw productiedatabase momenteel wordt geüpgraded naar een nieuwere versie.
Daarnaast heb je per versie twee opties met betrekking tot de code-update.
Je kunt ervoor kiezen om automatisch te profiteren van de nieuwste oplossingen voor bugs, beveiliging en prestaties. De bronnen van jouw Odoo-server worden wekelijks bijgewerkt. Dit is de optie ‘Nieuwste’.
Je kunt ervoor kiezen om de Odoo-bronnen aan een specifieke revisie vast te zetten door ze uit een lijst met datums te selecteren. Revisies vervallen na 3 maanden. Wanneer de vervaldatum nadert, krijgt je per mail bericht en als je daarna geen actie onderneemt, wordt je automatisch op de laatste revisie gezet.
Aangepaste domeinen
Hier kunt je extra domeinen configureren voor de geselecteerde vestiging. Het is mogelijk om andere toe te voegen <name> .odoo.com-domeinen of jouw eigen aangepaste domeinen. Voor dit laatste moet je:
eigenaar of aankoop van de domeinnaam,
voeg de domeinnaam toe aan deze lijst,
configureer in de domeinnaambeheerder van jouw registrar de domeinnaam met een
CNAME-record ingesteld op de domeinnaam van jouw productiedatabase.
Om bijvoorbeeld www.mijnbedrijf.com aan jouw database mijnbedrijf.odoo.com te koppelen:
in Odoo.sh, voeg www.mycompany.com toe in de aangepaste domeinen van jouw projectinstellingen,
configureer in jouw domeinnaambeheerder (bijvoorbeeld godaddy.com, gandi.net, ovh.com) www.mijnbedrijf.com met een
CNAMErecord met als waarde mijnbedrijf.odoo. com.
Kale domeinen (bijvoorbeeld mijnbedrijf.com) worden niet geaccepteerd:
ze kunnen alleen worden geconfigureerd met
A-records,Arecords accepteren alleen IP-adressen als waarde,het IP-adres van jouw database kan veranderen als gevolg van een upgrade, een hardwarestoring of jouw wens om jouw database in een ander land of continent te hosten.
Daarom konden kale domeinen plotseling niet meer werken vanwege deze wijziging van het IP-adres.
Als je bovendien wilt dat zowel mijnbedrijf.com als www.mijnbedrijf.com met jouw database werken, is het laten omleiden van de eerste naar de tweede een van de best practices voor SEO <https://support.google. com/webmasters/answer/7451184?hl=nl>`_ (Zie Geef één versie van een URL op om een document te bereiken) om één dominante URL te hebben. Je kunt daarom mijnbedrijf.com gewoon configureren om door te verwijzen naar www.mijnbedrijf.com. De meeste domeinbeheerders hebben de functie om deze omleiding te configureren. Dit wordt gewoonlijk een webomleiding genoemd.
HTTPS/SSL
Als de omleiding correct is ingesteld, genereert het platform binnen een uur automatisch een SSL-certificaat met Let’s Encrypt en is jouw domein toegankelijk via HTTPS.
Hoewel het momenteel niet mogelijk is om jouw eigen SSL-certificaten op het Odoo.sh-platform te configureren, overwegen we de functie als er voldoende vraag is.
SPF- en DKIM-compliance
Als het domein van de e-mailadressen van jouw gebruikers SPF (Sender Policy Framework) of DKIM (DomainKeys Identified Mail) gebruikt, vergeet dan niet om Odoo te autoriseren als verzendende host in jouw domeinnaaminstellingen om de afleverbaarheid van jouw uitgaande e-mails te vergroten. De configuratiestappen worden uitgelegd in de documentatie over SPF en DKIM.
Waarschuwing
Als je vergeet jouw SPF of DKIM te configureren om Odoo te autoriseren als verzendende host, kan dit ertoe leiden dat jouw e-mails als spam worden afgeleverd in de inbox van jouw contacten.
Shell-opdrachten¶
In de rechterbovenhoek van de weergave zijn verschillende shell-opdrachten beschikbaar.
Elke opdracht kan naar het klembord worden gekopieerd om in een terminal te worden gebruikt, en sommige ervan kunnen rechtstreeks vanuit Odoo.sh worden gebruikt door op de knop uitvoeren te klikken. In dat geval zal een pop-up de gebruiker vragen om eventuele tijdelijke aanduidingen te definiëren, zoals als ``<URL> ``, ``<PATH> ``, …
Klonen¶
Download de Git-opslagplaats.
$ git clone --recurse-submodules --branch master git@github.com:odoo/odoo.git
Kloont de repository odoo/odoo.
--recurse-submodules: Downloadt de submodules van jouw repository. Submodules die in de submodules zijn opgenomen, worden ook gedownload.--branch: checkt een specifieke branch van de repository uit, in dit geval master.
De knop run is niet beschikbaar voor deze opdracht, omdat deze bedoeld is voor gebruik op jouw machines.
Vork¶
Maak een nieuwe vertakking op basis van de huidige vertakking.
$ git checkout -b feature-1 master
Creëert een nieuwe branch met de naam feature-1, gebaseerd op de branch master, en checkt deze vervolgens uit.
$ git push -u origin feature-1
Uploadt de nieuwe branch feature-1 naar jouw externe repository.
Samenvoegen¶
Voeg de huidige vertakking samen met een andere vertakking.
$ git merge staging-1
Voegt de vertakking staging-1 samen in de huidige vertakking.
$ git push -u origin master
Uploadt de wijzigingen die je zojuist hebt toegevoegd in de master branch op jouw externe repository.
SSH¶
Instellingen¶
Om SSH te gebruiken, moet je de publieke SSH-sleutel van jouw profiel instellen (als dit nog niet is gebeurd). Om dit te doen, volgt je deze stappen:
Kopieer de SSH-sleutel naar jouw klembord ( pas alleen stap 1 toe)
Plak de gekopieerde inhoud in de SSH-sleutels van jouw profiel en druk op “Toevoegen”
De sleutel zou hieronder moeten verschijnen
Connectie¶
Om via ssh verbinding te maken met jouw builds, gebruikt je de volgende opdracht in een terminal:
$ ssh <build_id>@<domain>
Je vind een snelkoppeling voor deze opdracht op het SSH-tabblad in de rechterbovenhoek.
Op voorwaarde dat je over de :ref:`juiste toegangsrechten beschikt<odoosh-gettingstarted-settings-collaborators> ` voor het project krijgt je ssh-toegang tot de build.
Notitie
Langdurige ssh-verbindingen kunnen niet worden gegarandeerd. Inactieve verbindingen worden verbroken om bronnen vrij te maken.
Submodule¶
Voeg een branch uit een andere repository in je huidige branch toe als submodule.
Met Submodules kunt je modules uit andere opslagplaatsen in jouw project gebruiken.
De submodulefunctie wordt gedetailleerd beschreven in het hoofdstuk :ref:`Submodules<odoosh-advanced-submodules> ` van deze documentatie.
$ git submodule add -b master <URL> <PATH>
Voegt de branch master van de repository toe *<URL> * als submodule onder het pad *<PATH> * in jouw huidige vestiging.
$ git commit -a
Legt al jouw huidige wijzigingen vast.
$ git push -u origin master
Uploadt de wijzigingen die je zojuist hebt toegevoegd in de master branch op jouw externe repository.
Verwijderen¶
Verwijder een vertakking jeit jouw repository.
$ git push origin :master
Verwijdert de vertakking in jouw externe repository.
$ git branch -D master
Verwijdert de vertakking in jouw lokale kopie van de repository.