Grenar

Översikt

Vyn Grenar ger dig en översikt över de olika grenar som ditt repositorium har.

../../../_images/interface-branches.png

Stadier

Odoo.sh erbjuder tre olika stadier för dina filialer: produktion, staging och utveckling.

Du kan ändra stadiet för en gren genom att dra och släppa den i stadieavsnittets rubrik.

../../../_images/interface-branches-stagechange.png

Produktion

Detta är den filial som innehåller den kod som din produktionsdatabas körs på. Det kan bara finnas en produktionsgren.

När du pushar en ny commit i den här grenen uppdateras din produktionsserver med koden för den nya revisionen och startas sedan om.

Om dina ändringar kräver uppdatering av en modul, t.ex. en ändring i en formulärvy, och du vill att den ska utföras automatiskt, ska du öka modulens versionsnummer i dess manifest (__manifest__.py). Plattformen kommer då att se till att utföra uppdateringen under vilken instansen kommer att hållas tillfälligt otillgänglig av underhållsskäl.

Denna metod är likvärdig med att utföra en uppgradering av modulen via Apps-menyn, eller via -u-omkopplaren i kommandoraden.

Om ändringarna i commiten hindrar servern från att starta om, eller om moduluppdateringen misslyckas, återställs servern automatiskt till den tidigare kodrevisionen och databasen återställs till det skick den hade före uppdateringen. Du har fortfarande tillgång till loggen för den misslyckade uppdateringen, så du kan felsöka den.

Demodata laddas inte, eftersom de inte är avsedda att användas i en produktionsdatabas. Enhetstesterna utförs inte, eftersom det skulle öka produktionsdatabasens otillgänglighetstid under uppdateringarna.

Partners som använder testprojekt bör vara medvetna om att deras produktionsgren, tillsammans med alla staging-grenar, automatiskt kommer att återställas till utvecklingsstadiet efter 30 dagar.

Uppställning

Staging branches är avsedda att testa dina nya funktioner med hjälp av produktionsdata utan att kompromissa med den faktiska produktionsdatabasen med testposter. De kommer att skapa databaser som är neutraliserade duplikat av produktionsdatabasen.

Neutraliseringen omfattar:

  • Inaktivera schemalagda åtgärder. Om du vill testa dem kan du aktivera dem manuellt eller aktivera dem igen. Tänk på att plattformen kommer att utlösa dem mer sällan om ingen använder databasen för att spara resurser.

  • Inaktivera utgående e-post genom att fånga upp dem med en mailcatcher. Ett -gränssnitt för att visa e-postmeddelanden som skickas av din databas tillhandahålls. På så sätt behöver du inte oroa dig för att skicka testmeddelanden till dina kontakter.

  • Ange betalningsleverantörer och fraktleverantörer i testläge.

  • Inaktivera IAP-tjänster

Den senaste databasen kommer att hållas vid liv på obestämd tid, äldre från samma filial kan bli skräpplockade för att göra plats för nya. Den kommer att vara giltig i 3 månader, varefter du förväntas bygga upp filialen på nytt. Om du gör konfigurations- eller vyändringar i dessa databaser, se till att dokumentera dem eller skriv dem direkt i filialens moduler, med hjälp av XML-datafiler som åsidosätter standardkonfigurationen eller vyerna.

Enhetstesterna utförs inte eftersom de i Odoo för närvarande är beroende av demodata, som inte är inlästa i produktionsdatabasen. I framtiden, om Odoo stöder att köra enhetstesterna utan demodata, kommer Odoo.sh att överväga att köra testerna på staging-databaser.

Utveckling

Utvecklingsgrenar skapar nya databaser med hjälp av demodata för att köra enhetstesterna. De installerade modulerna är de som ingår i dina grenar. Du kan ändra listan över moduler som ska installeras i din projektinställningar.

När du pushar en ny commit i en av dessa grenar startas en ny server, med en databas som skapats från grunden och den nya revisionen av grenen. Demodata laddas och enhetstesterna utförs som standard. Detta verifierar att dina ändringar inte bryter mot någon av de funktioner som testas av dem. Om du vill kan du inaktivera testerna eller tillåta att specifika tester körs med anpassade taggar i grenens inställningar.

I likhet med staging branches skickas inte e-postmeddelandena utan fångas upp av en mailcatcher och schemalagda åtgärder utlöses inte så länge databasen inte används.

De databaser som skapas för utvecklingsgrenar är avsedda att leva i cirka tre dagar. Efter det kan de automatiskt garbage collected för att göra plats för nya databaser utan föregående meddelande.

Sammanfoga dina filialer

Du kan enkelt slå samman dina grenar genom att dra och släppa dem i varandra.

../../../_images/interface-branches-merge.png

När du vill testa ändringarna i dina utvecklingsgrenar med produktionsdata kan du antingen:

  • slå samman utvecklingsgrenen med din staging-gren genom att dra och släppa den på önskad staging-gren,

  • dra och släpp utvecklingsgrenen på staging-sektionens titel för att göra den till en staging-gren.

När de senaste ändringarna är redo för produktion kan du dra och släppa din staging-gren till din produktionsgren för att slå samman och driftsätta de senaste funktionerna i produktion.

Om du är tillräckligt djärv kan du också slå samman dina utvecklingsgrenar med din produktionsgren. Det innebär bara att du hoppar över valideringen av dina ändringar med produktionsdata genom en staging branch.

Du kan slå samman dina utvecklingsgrenar med varandra och dina staging-grenar med varandra.

Naturligtvis kan du också använda git merge direkt på din arbetsstation för att slå samman dina grenar. Odoo.sh kommer att meddelas när nya revisioner har lagts in i dina grenar.

Vid sammanslagning av en staging-gren i produktionsgrenen slås endast källkoden samman: Eventuella konfigurationsändringar som du har gjort i staging-databaserna överförs inte till produktionsdatabasen.

Om du testar konfigurationsändringar i staging-grenar och vill att de ska tillämpas i produktionen måste du antingen:

  • skriv konfigurationsändringarna i XML-datafiler som åsidosätter standardkonfigurationen eller vyerna i dina grenar, och öka sedan versionen av din modul i dess manifest (__manifest__.py) för att utlösa uppdateringen av modulen när du slår samman din staging-gren med din produktionsgren. Detta är bästa praxis för bättre skalbarhet i din utveckling eftersom du kommer att använda Gits versionshanteringsfunktioner för alla dina konfigurationsändringar och därmed ha en spårbarhet för dina ändringar.

  • skicka dem manuellt från din staging- till din produktionsdatabas genom att kopiera/klistra in dem.

Flikar

Historia

En översikt över din filialhistorik:

  • Meddelandena om åtagandena och deras upphovsmän,

  • De olika händelser som är kopplade till plattformen, t.ex. scenförändringar, databasimport, återställning av säkerhetskopior.

../../../_images/interface-branches-history.png

För varje händelse visas en status i det övre högra hörnet. Den kan ge information om den pågående åtgärden i databasen (installation, uppdatering, import av säkerhetskopia, …) eller dess resultat (teståterkoppling, lyckad import av säkerhetskopia, …). När en åtgärd har lyckats kan du komma åt databasen med hjälp av knappen connect.

E-post

Denna flik innehåller postfångaren. Den visar en översikt över de e-postmeddelanden som skickas av din databas. Mail catcher är tillgänglig för dina utvecklings- och staging-grenar eftersom e-postmeddelandena från din produktionsdatabas verkligen skickas istället för att fångas upp.

../../../_images/interface-branches-mails.png

Skal

En skalåtkomst till din container. Du kan utföra grundläggande Linux-kommandon (ls, top) och öppna ett skal på din databas genom att skriva psql.

../../../_images/interface-branches-shell.png

Du kan öppna flera flikar och dra och släppa dem för att arrangera layouten som du vill, t.ex. sida vid sida.

Observera

Långvariga shell-instanser garanteras inte. Inaktiva shells kan när som helst kopplas bort för att frigöra resurser.

Redaktör

En integrerad utvecklingsmiljö (IDE) online för att redigera källkoden. Du kan också öppna terminaler, Python-konsoler och till och med Odoo Shell-konsoler.

../../../_images/interface-branches-editor.png

Du kan öppna flera flikar och dra och släppa dem för att arrangera layouten som du vill, t.ex. sida vid sida.

Övervakning

Den här länken innehåller olika övervakningsmätvärden för den aktuella byggnaden.

../../../_images/interface-branches-monitoring.png

Du kan zooma, ändra tidsintervall eller välja ett specifikt mätvärde i varje graf. I graferna finns kommentarer som hjälper dig att relatera till ändringar i byggprocessen (databasimport, git push, etc…).

Loggar

En viewer för att titta i dina serverloggar.

../../../_images/interface-branches-logs.png

Olika stockar finns tillgängliga:

  • install.log: Loggarna för databasinstallationen. I en utvecklingsgren ingår loggar från testerna.

  • pip.log: Loggarna för installationen av Python-beroenden.

  • odoo.log: Loggarna för den körande servern.

  • uppdatering.log: Loggarna över databasuppdateringarna.

  • pg_long_queries.log: Loggar över psql-frågor som tar ovanligt lång tid.

Om nya rader läggs till i loggarna kommer de att visas automatiskt. Om du scrollar till botten kommer webbläsaren att scrolla automatiskt varje gång en ny rad läggs till.

Du kan pausa hämtningen av loggar genom att klicka på motsvarande knapp i det övre högra hörnet av vyn. Hämtningen stoppas automatiskt efter 5 minuter. Du kan starta om den med hjälp av play-knappen.

Säkerhetskopior

En lista över de säkerhetskopior som finns tillgängliga för nedladdning och återställning, möjligheten att utföra en manuell säkerhetskopiering och att importera en databas.

../../../_images/interface-branches-backups.png

Odoo.sh gör dagliga säkerhetskopior av produktionsdatabasen. Den sparar 7 dagliga, 4 veckovisa och 3 månatliga säkerhetskopior. Varje säkerhetskopia innehåller databasdumpen, fillagret (bilagor, binära fält), loggar och sessioner.

Staging- och utvecklingsdatabaser säkerhetskopieras inte. Du har dock möjlighet att återställa en säkerhetskopia av produktionsdatabasen i dina staging-grenar, för teständamål, eller att manuellt återställa data som av misstag har raderats från produktionsdatabasen.

Listan innehåller de säkerhetskopior som sparas på den server som din produktionsdatabas ligger på. Denna server sparar endast en månads säkerhetskopior: 7 dagliga och 4 veckovisa säkerhetskopior.

Dedikerade backupservrar behåller samma säkerhetskopior samt ytterligare 3 månatliga säkerhetskopior. För att återställa eller ladda ner en av dessa månatliga säkerhetskopior, vänligen kontakta oss.

Om du slår samman en commit som uppdaterar versionen av en eller flera moduler (i __manifest__.py), eller deras länkade pythonberoenden (i requirements.txt), utför Odoo.sh automatiskt en säkerhetskopiering (flaggas med typ Update i listan), eftersom antingen behållaren kommer att ändras genom installationen av nya pip-paket, antingen själva databasen kommer att ändras med moduluppdateringen som utlöses efteråt. I dessa två fall gör vi en säkerhetskopia eftersom det potentiellt kan förstöra saker.

Om du slår samman en commit som bara ändrar lite kod utan de ovan nämnda ändringarna, görs ingen säkerhetskopiering av Odoo.sh, eftersom varken containern eller databasen ändras så plattformen anser att detta är tillräckligt säkert. Som en extra försiktighetsåtgärd kan du naturligtvis göra en manuell säkerhetskopia innan du gör stora ändringar i dina produktionskällor, ifall något skulle gå fel (dessa manuella säkerhetskopior är tillgängliga i ungefär en vecka). För att undvika missbruk begränsar vi antalet manuella säkerhetskopior till 5 per dag.

Funktionen importera databas accepterar databasarkiv i det format som tillhandahålls av:

  • standard Odoo databashanterare, (tillgänglig för lokala Odoo-servrar under /web/database/manager)

  • hanterare av Odoos onlinedatabaser,

  • knappen Odoo.sh backup download på denna flik Backups,

  • knappen för nedladdning av Odoo.sh dump i Builds-vyn.

Uppgradering

Tillgänglig för produktions- och staginggrenar för giltiga projekt.

Inställningar

Här hittar du ett par inställningar som endast gäller för den aktuella filialen.

../../../_images/interface-branches-settings.jpg

Beteende vid nytt åtagande

För utvecklings- och staging-grenar kan du ändra grenens beteende när den tar emot en ny commit. Som standard skapar en utvecklingsgren en ny build och en staging-gren uppdaterar den tidigare build (se Production Stage). Detta är särskilt användbart om funktionen du arbetar med kräver en viss inställning eller konfiguration, för att undvika att behöva ställa in den manuellt igen vid varje commit. Om du väljer new build för en staging-gren kommer den att göra en ny kopia från produktionsbyggnaden varje gång en commit pushas. En gren som återställs från staging till utveckling kommer automatiskt att ställas in på ”Gör ingenting”.

**Installation av moduler

Välj vilka moduler som ska installeras automatiskt för dina utvecklingsbyggnader.

../../../_images/interface-settings-modulesinstallation.png
  • Installera endast mina moduler installerar endast modulerna för grenen. Detta är standardalternativet. submoduler är undantagna.

  • Fullständig installation (alla moduler) installerar modulerna i grenen, de moduler som ingår i undermodulerna och alla standardmoduler i Odoo. När du kör den fullständiga installationen är testsviten inaktiverad.

  • Installera en lista med moduler installerar de moduler som anges i inmatningen strax under detta alternativ. Namnen är modulernas tekniska namn och de måste vara kommaseparerade.

Om testerna är aktiverade kan standardpaketet för Odoo-moduler ta upp till 1 timme. Denna inställning gäller endast för utvecklingsbyggnader. Staging builds duplicerar produktions build och produktions build installerar endast base.

Test svit

För utvecklingsgrenar kan du välja att aktivera eller inaktivera testsviten. Den är aktiverad som standard. När testsviten är aktiverad kan du begränsa dem genom att ange testtaggar testtaggar.

Odoo Version

Endast för utvecklingsgrenar kan du ändra versionen av Odoo, om du vill testa uppgraderad kod eller utveckla funktioner medan din produktionsdatabas håller på att uppgraderas till en nyare version.

För varje version har du dessutom två alternativ när det gäller koduppdateringen.

  • Du kan välja att dra nytta av de senaste bugg-, säkerhets- och prestandafixarna automatiskt. Källorna till din Odoo-server kommer att uppdateras varje vecka. Detta är alternativet ”Senaste”.

  • Du kan välja att fästa Odoo-källorna till en specifik revision genom att välja dem från en lista med datum. Revisioner upphör att gälla efter 3 månader. Du kommer att meddelas via e-post när utgångsdatumet närmar sig och om du inte vidtar några åtgärder efteråt kommer du automatiskt att ställas in på den senaste revisionen.

Anpassade domäner

Här kan du konfigurera ytterligare domäner för den valda filialen. Det är möjligt att lägga till andra <name>.odoo.com-domäner eller dina egna anpassade domäner. För det senare måste du:

  • äga eller köpa domännamnet,

  • lägg till domännamnet i listan,

  • i registrarens domännamnshanterare, konfigurera domännamnet med en CNAME-post som är inställd på domännamnet för din produktionsdatabas.

Till exempel för att associera www.mycompany.com till din databas mycompany.odoo.com:

  • i Odoo.sh, lägg till www.mycompany.com i de anpassade domänerna i dina projektinställningar,

  • i din domännamnshanterare (t.ex. godaddy.com, gandi.net, ovh.com), konfigurera www.mycompany.com med en CNAME-post med värdet mycompany.odoo.com.

Bara domäner (t.ex. mycompany.com) accepteras inte:

  • de kan endast konfigureras med hjälp av A-poster,

  • A-poster accepterar endast IP-adresser som värde,

  • IP-adressen till din databas kan ändras till följd av en uppgradering, ett maskinvarufel eller om du vill ha din databas i ett annat land eller på en annan kontinent.

Därför kan nakna domäner plötsligt inte längre fungera på grund av denna ändring av IP-adressen.

Om du vill att både mycompany.com och www.mycompany.com ska fungera med din databas är det dessutom en av de bästa metoderna för SEO (se Tillhandahåll en version av en URL för att nå ett dokument) att låta den första omdirigera till den andra för att ha en dominerande URL. Du kan därför bara konfigurera mycompany.com att omdirigera till www.mycompany.com. De flesta domänhanterare har funktionen för att konfigurera denna omdirigering. Detta kallas vanligen för en webbomdirigering.

HTTPS/SSL

Om omdirigeringen är korrekt konfigurerad kommer plattformen automatiskt att generera ett SSL-certifikat med Let’s Encrypt inom en timme och din domän kommer att vara tillgänglig via HTTPS.

Även om det för närvarande inte är möjligt att konfigurera dina egna SSL-certifikat på Odoo.sh-plattformen överväger vi funktionen om det finns tillräckligt med efterfrågan.

SPF- och DKIM-överensstämmelse

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.

Varning

Om du glömmer att konfigurera SPF eller DKIM för att godkänna Odoo som en sändande värd kan det leda till att dina e-postmeddelanden levereras som skräppost i dina kontakters inkorg.

Shell-kommandon

I det övre högra hörnet av vyn finns olika skalkommandon tillgängliga.

../../../_images/interface-branches-shellcommands.png

Varje kommando kan kopieras till Urklipp för att användas i en terminal, och vissa av dem kan användas direkt från Odoo.sh genom att klicka på knappen run i sådana fall kommer en popup att uppmana användaren att definiera eventuella platshållare som <URL>, <PATH>, …

Klon

Ladda ner Git-förvaret.

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

Klonar förvaret odoo/odoo.

  • --recurse-submodules: Laddar ner undermodulerna i ditt arkiv. Undermoduler som ingår i undermodulerna hämtas också.

  • --branch: checkar ut en specifik gren av arkivet, i detta fall master.

Knappen kör är inte tillgänglig för detta kommando, eftersom det är avsett att användas på dina datorer.

Gaffel

Skapa en ny gren baserat på den aktuella grenen.

$ git checkout -b feature-1 master

Skapar en ny gren kallad feature-1 baserad på grenen master, och checkar sedan ut den.

$ git push -u origin feature-1

Laddar upp den nya grenen feature-1 på ditt fjärranslutna arkiv.

Sammanslagning

Slå samman den aktuella grenen med en annan gren.

$ git merge staging-1

Sammanfogar grenen staging-1 i den aktuella grenen.

$ git push -u origin master

Laddar upp de ändringar du just lagt till i master-grenen på ditt fjärranslutna repositorium.

SSH

Inställning

För att kunna använda SSH måste du skapa en offentlig SSH-nyckel för din profil (om det inte redan är gjort). Följ dessa steg för att göra det:

  1. Generera en ny SSH-nyckel

  2. Kopiera SSH-nyckeln till urklipp (gäller endast steg 1)

  3. Klistra in det kopierade innehållet i SSH-nycklarna i din profil och tryck på ”Lägg till”

    ../../../_images/SSH-key-pasting.png
  4. Nyckeln ska visas nedan

    ../../../_images/SSH-key-appearing.png

Anslutning

För att ansluta till dina byggnader med ssh använder du följande kommando i en terminal:

$ ssh <build_id>@<domain>

Du hittar en genväg för detta kommando på fliken SSH i det övre högra hörnet.

../../../_images/SSH-panel.png

Förutsatt att du har korrekt behörighet på projektet kommer du att få ssh-åtkomst till bygget.

Observera

Långvariga ssh-anslutningar kan inte garanteras. Inaktiva anslutningar kommer att kopplas bort för att frigöra resurser.

Undermodul

Lägg till en gren från ett annat arkiv i din aktuella gren som en submodul.

Med Submodules kan du använda moduler från andra arkiv i ditt projekt.

Funktionen för undermoduler beskrivs i detalj i kapitlet Submoduler i denna dokumentation.

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

Lägger till grenen master i arkivet <URL> som en undermodul under sökvägen <PATH> i din aktuella gren.

$ git commit -a

Överför alla dina aktuella ändringar.

$ git push -u origin master

Laddar upp de ändringar du just lagt till i master-grenen på ditt fjärranslutna repositorium.

Radera

Ta bort en gren från ditt arkiv.

$ git push origin :master

Raderar grenen i ditt fjärranslutna arkiv.

$ git branch -D master

Raderar grenen i din lokala kopia av arkivet.