Гілки

Загальний огляд

Перегляд гілок дає вам огляд різних гілок, які має ваше сховище.

Етапи

Odoo.sh пропонує три різні етапи для ваших філій: виробництво, постановка та розробка.

Ви можете змінити етап гілки, перетягнувши її в заголовок розділу етапів.

Виробництво

Це гілка, що містить код, на якому працює ваша робоча база даних. Виробнича гілка може бути тільки одна.

Коли ви натискаєте новий комміт у цій гілці, ваш робочий сервер оновлюється кодом нової версії, а потім перезапускається.

Якщо ваші зміни вимагають оновлення модуля, наприклад зміни в поданні форми, і ви хочете, щоб це було виконано автоматично, збільште номер версії модуля в його маніфесті (__manifest__.py). Потім платформа подбає про виконання оновлення, під час якого екземпляр буде тимчасово недоступний через технічне обслуговування.

Цей метод еквівалентний виконанню оновлення модуля через меню Додатки або за допомогою перемикача -u командний рядок.

У випадку, якщо зміни в коміті перешкоджають перезапуску сервера або якщо оновлення модулів не вдається, сервер автоматично повертається до попередньої успішної версії коду, а база даних відкочується, як це було до оновлення. Ви все ще маєте доступ до журналу невдалих оновлень, тож можете вирішити проблему.

Демо-дані не завантажуються, оскільки вони не призначені для використання у робочій базі даних. Модульні тести не виконуються, оскільки це призведе до збільшення часу недоступності робочої бази даних під час оновлень.

Партнери, які використовують пробні проекти, повинні знати, що їхні виробничі гілки разом із усіма проміжними гілками автоматично повертаються до стадії розробки через 30 днів.

Проміжний

Проміжні гілки призначені для тестування ваших нових функцій за допомогою даних про виробництво без шкоди для фактичної бази даних із тестовими записами. Вони створять бази даних, які є нейтралізованими дублікатами робочої бази даних.

Нейтралізація включає:

• Відключення запланованих дій. Якщо ви хочете перевірити їх, ви можете запустити їх дію вручну або повторно ввімкнути. Майте на увазі, що платформа запускатиме їх рідше, якщо ніхто не використовує базу даних, щоб заощадити ресурси.

• Вимкнення вихідних електронних листів шляхом їх перехоплення за допомогою mailcatcher. інтерфейс для перегляду надаються електронні листи, надіслані вашою базою даних. Таким чином, вам не доведеться турбуватися про надсилання тестових електронних листів своїм контактам.

• Налаштування постачальників платежів і постачальників доставки в тестовому режимі.

• Вимкнення служб IAP

Найновішу базу даних зберігатиметься необмежений час, старіші з тієї ж гілки можуть збиратися, щоб звільнити місце для нових. Він буде дійсний протягом 3 місяців, після чого вас чекає відновлення гілки. Якщо ви вносите зміни в конфігурацію або перегляд у цих базах даних, обов’язково задокументуйте їх або запишіть безпосередньо в модулях гілки, використовуючи файли даних XML, які замінюють конфігурацію або перегляди за замовчуванням.

Модульні тести не виконуються, оскільки в Odoo наразі вони покладаються на демонстраційні дані, які не завантажуються у робочу базу даних. У майбутньому, якщо Odoo підтримуватиме виконання модульних тестів без демонстраційних даних, Odoo.sh розгляне можливість запуску тестів у проміжних базах даних.

Розробка

Гілки розробки створюють нові бази даних, використовуючи демонстраційні дані для виконання модульних тестів. Встановлені модулі - це ті, які включені у ваші гілки. Ви можете змінити цей список модулів для встановлення в налаштуваннях проекту.

Коли ви натискаєте нову фіксацію в одній із цих гілок, запускається новий сервер із базою даних, створеною з нуля, і новою версією гілки. Демонстраційні дані завантажуються, а модульні тести виконуються за замовчуванням. Це підтверджує, що ваші зміни не порушують жодну з перевірених ними функцій. Якщо ви бажаєте, ви можете вимкнути тести або дозволити запуск певних тестів із спеціальними тегами в налаштуваннях гілки <odoosh-gettingstarted-branches-tabs-settings>.

Подібно до проміжних гілок, електронні листи не надсилаються, але перехоплюються перехоплювачем пошти, і заплановані дії не запускаються, доки база даних не використовується.

Бази даних, створені для гілок розробки, мають жити близько трьох днів. Після цього їх можна автоматично зібрати як сміття, щоб звільнити місце для нових баз даних без попереднього повідомлення.

Об’єднання ваших гілок

Ви можете легко об’єднати свої гілки, перетягнувши їх одну в одну.

Якщо ви хочете перевірити зміни ваших гілок розробки за допомогою виробничих даних, ви можете:

• об’єднати гілку розробки з вашою проміжною гілкою, перетягнувши її на потрібну проміжну гілку,

• перетягнути гілку розробки на заголовок проміжного розділу, щоб зробити її гілкою проміжної.

Коли ваші останні зміни будуть готові для виробництва, ви можете перетягнути свою проміжну гілку у свою робочу гілку, щоб об’єднати та розгорнути у виробництві ваші нові функції.

Якщо у вас достатньо сміливості, ви можете також об’єднати ваші гілки розробки у виробничу. Це просто означає, що ви пропускаєте перевірку ваших змін із даними виробництва через проміжну гілку.

Ви можете об’єднати свої гілки розробки одна в одну, а свої проміжні гілки одна в одну.

Звичайно, ви також можете використовувати git merge безпосередньо на своїй робочій станції, щоб об’єднати свої гілки. Odoo.sh отримає сповіщення, коли у ваших гілках будуть розміщені нові версії.

Об’єднання проміжної гілки у виробничу гілку об’єднує лише вихідний код: будь-які зміни конфігурації, які ви внесли в проміжні бази даних, не передаються до робочої бази даних.

Якщо ви тестуєте зміни конфігурації в проміжних гілках і бажаєте, щоб вони були застосовані у виробництві, ви повинні:

• записати зміни конфігурації у файли даних XML, замінивши конфігурацію за замовчуванням або перегляди у ваших гілках, а потім збільшити версію вашого модуля в його маніфесті (__manifest__.py), щоб ініціювати оновлення модуля, коли ви об’єднаєте проміжну гілку в ваша виробничу гілку. Це найкраща практика для кращої масштабованості ваших розробок, оскільки ви будете використовувати функції контролю версій Git для всіх змін конфігурації, а отже матимете можливість відстежувати свої зміни.

• передати їх вручну з вашої проміжної бази даних у вашу робочу базу даних, скопіювавши/вставивши їх.

Вкладки

Історія

Огляд історії вашої гілки:

• Повідомлення комітів та їх авторів,

• Різноманітні події, пов’язані з платформою, такі як зміни стадії, імпорт бази даних, відновлення резервної копії.

Для кожної події у верхньому правому куті відображається статус. Він може надавати інформацію про поточну операцію з базою даних (інсталяція, оновлення, імпорт резервної копії, …) або її результат (відгук про тестування, успішний імпорт резервної копії, …). Після успішної операції ви можете отримати доступ до бази даних завдяки кнопці підключення.

Листи

Ця вкладка містить перехоплювач пошти. Він відображає огляд електронних листів, надісланих вашою базою даних. Перехоплювач пошти доступний для ваших гілок розробки та тестування, оскільки електронні листи вашої робочої бази даних дійсно надсилаються, а не перехоплюються.

Оболонка

Доступ оболонки до вашого контейнера. Ви можете виконати основні команди Linux (ls, top) і відкрити оболонку у своїй базі даних, ввівши psql.

Ви можете відкрити кілька вкладок і перетягнути їх, щоб упорядкувати макет за своїм бажанням, наприклад, поруч.

Примітка

Тривала робота екземплярів оболонки не гарантується. Неактивні оболонки можна будь-коли відключити, щоб звільнити ресурси.

Редактор

Онлайнове інтегроване середовище розробки (IDE) для редагування вихідного коду. Ви також можете відкрити термінали, консолі Python і навіть консолі Odoo Shell.

Ви можете відкрити кілька вкладок і перетягнути їх, щоб упорядкувати макет за своїм бажанням, наприклад, поруч.

Моніторинг

Це посилання містить різні показники моніторингу поточної збірки.

Ви можете масштабувати, змінювати часовий діапазон або вибирати певний показник на кожному графіку. Анотації на графіках допомагають вам пов’язати зміни у збірці (імпорт бази даних, git push тощо).

Журнали

Переглядач, щоб переглянути журнали вашого сервера.

Доступні різні журнали:

• install.log: Журнали встановлення бази даних. У гілку розробки включаються журнали тестів.

• pip.log: журнали встановлення залежностей Python.

• odoo.log: журнали запущеного сервера.

• update.log: журнали оновлень бази даних.

• pg_long_queries.log: журнали запитів psql, які займають надзвичайно багато часу.

Якщо в журналах буде додано нові рядки, вони відображатимуться автоматично. Якщо прокрутити вниз, браузер автоматично прокручуватиметься щоразу, коли буде додано новий рядок.

Ви можете призупинити отримання журналів, натиснувши відповідну кнопку у верхньому правому куті перегляду. Отримання автоматично зупиняється через 5 хвилин. Ви можете перезапустити його за допомогою кнопки відтворення.

Резервні копії

Список резервних копій, доступних для завантаження та відновлення, можливість виконувати резервне копіювання вручну та імпортувати базу даних.

Odoo.sh робить щоденні резервні копії робочої бази даних. Він зберігає 7 щоденних, 4 щотижневих і 3 щомісячних резервних копій. Кожна резервна копія містить дамп бази даних, сховище файлів (вкладення, бінарні поля), журнали та сеанси.

Резервне копіювання баз даних проміжної та розробки не створюється. Тим не менш, у вас є можливість відновити резервну копію робочої бази даних у ваших проміжних гілках для тестування або вручну відновити дані, які були випадково видалені з робочої бази даних.

Список містить резервні копії, що зберігаються на сервері, на якому розміщено вашу робочу базу даних. Цей сервер зберігає лише один місяць резервного копіювання: 7 щоденних і 4 щотижневих резервних копій.

Виділені сервери резервного копіювання зберігають ті самі резервні копії, а також 3 додаткові щомісячні резервні копії. Щоб відновити або завантажити одну з цих щомісячних резервних копій, будь ласка, зв’яжіться з нами.

Якщо ви об’єднаєте комміт, оновлюючи версію одного чи кількох модулів (у __manifest__.py), або їх зв’язані залежності python (у requirements.txt), тоді Odoo.sh автоматично виконує резервне копіювання (позначено типом Update у списку), оскільки або контейнер буде змінено шляхом встановлення нових пакетів pip, або сама база даних буде змінена з оновленням модуля, що запускається пізніше. У цих двох випадках ми робимо резервну копію, оскільки це потенційно може порушити роботу.

Якщо ви об’єднаєте комміт, який змінює лише деякий код без вищезгаданих модифікацій, тоді Odoo.sh не робить резервне копіювання, оскільки ні контейнер, ні база даних не змінюються, тому платформа вважає це достатньо безпечним. Звичайно, як додатковий запобіжний захід, ви можете створити резервну копію вручну, перш ніж вносити значні зміни у свої робочі джерела, на випадок, якщо щось піде не так (ці ручні резервні копії доступні приблизно протягом тижня). Щоб уникнути зловживань, ми обмежуємо ручне резервне копіювання до 5 на день.

Функція імпорт бази даних приймає архіви бази даних у форматі, наданому:

• стандартний менеджер баз даних Odoo (доступний для локальних серверів Odoo у /web/database/manager)

• менеджер онлайн-баз даних Odoo,

• кнопку завантаження резервної копії Odoo.sh на цій вкладці Резервні копії,

• кнопку завантаження дампа Odoo.sh у перегляд збірок.

Оновлення

Доступно для виробничої та проміжної гілок для дійсних проектів.

Дивись також

Документація оновлення

Налаштування

Тут ви можете знайти кілька параметрів, які застосовуються лише до вибраної гілки.

Поведінка після нового коміту

Для гілок розробки та проміжної ви можете змінити поведінку гілки після отримання нового коміту. За замовчуванням гілка розробки створить нову збірку, а проміжна гілка оновить попередню збірку (див. Етап виробництва). Це особливо корисно, якщо функція, над якою ви працюєте, потребує певного налаштування або конфігурації, щоб уникнути необхідності вручну налаштовувати її знову під час кожного коміту. Якщо ви виберете нову збірку для проміжної гілки, вона створюватиме свіжу копію робочої збірки щоразу, коли надсилатиметься комміт. Для гілки, яка повертається з етапу проміжної до розробки, буде автоматично встановлено значення „Нічого не робити“.

Установка модулів

Виберіть модулі для автоматичного встановлення для збірок розробки.

• Встановлювати тільки мої модулі встановить лише модулі гілки. Це параметр за замовчуванням. Підмодулі <odoosh-advanced-submodules> виключені.

• Повна інсталяція (усі модулі) встановить модулі гілки, модулі, що входять до підмодулів, і всі стандартні модулі Odoo. Під час виконання повної інсталяції набір тестів вимкнено.

• Встановлювати список модулів встановить модулі, зазначені у вхідних даних безпосередньо під цією опцією. Назви є технічними назвами модулів, і вони повинні бути розділені комами.

Якщо тестування ввімкнено, стандартний набір модулів Odoo може зайняти до 1 години. Цей параметр застосовується лише до збірок для розробки. Поетапні збірки дублюють робочу збірку, а робоча збірка лише встановлює базу.

Набір тестів

Для гілок розробки ви можете ввімкнути або вимкнути набір тестів. Він увімкнено за замовчуванням. Коли набір тестів увімкнено, ви можете обмежити їх, вказавши тестові теги test tags.

Версія Odoo

Лише для гілок розробки ви можете змінити версію Odoo, якщо ви хочете протестувати оновлений код або розробити функції, поки ваша робоча база даних перебуває в процесі оновлення до новішої версії.

Крім того, для кожної версії у вас є два варіанти оновлення коду.

• Ви можете скористатися останніми автоматичними виправленнями помилок, безпеки та продуктивності. Вихідні коди вашого сервера Odoo оновлюватимуться щотижня. Це опція „Остання“.

• Ви можете закріпити вихідні коди Odoo до певної версії, вибравши їх зі списку дат. Ревізії втрачають чинність через 3 місяці. Ви отримаєте сповіщення електронною поштою, коли закінчиться термін дії, і якщо ви не вживете заходів після цього, вам буде автоматично встановлено останню версію.

Користувацькі домени

Тут ви можете налаштувати додаткові домени для обраної гілки. Є можливість додати інші <name>.odoo.com або свої власні домени. Для останнього вам необхідно:

• мати або придбати доменне ім’я,

• додати доменне ім’я в цей список,

• у менеджері доменних імен вашого реєстратора налаштувати доменне ім’я за допомогою запису CNAME, встановленого для доменного імені робочої бази даних.

Наприклад, щоб прив’язати www.mycompany.com до вашої бази даних mycompany.odoo.com:

• в Odoo.sh додати www.mycompany.com у користувацькі домени налаштувань вашого проекту,

• у вашому менеджері доменних імен (наприклад, godaddy.com, gandi.net, ovh.com), налаштувати www.mycompany.com із записом CNAME зі значенням mycompany.odoo. com.

Голі домени (наприклад, mycompany.com) не приймаються:

• їх можна налаштувати лише за допомогою записів A,

• Записи A приймають лише IP-адреси як значення,

• IP-адреса вашої бази даних може змінитися після оновлення, апаратного збою або вашого бажання розмістити свою базу даних в іншій країні чи на континенті.

Таким чином, голі домени могли раптово більше не працювати через цю зміну IP-адреси.

Крім того, якщо ви бажаєте, щоб і mycompany.com, і www.mycompany.com працювали з вашою базою даних, переспрямування першого на друге є одним із оптимальних методів пошукової оптимізації (Див. Надайте одну версію URL-адреси для доступу до документа), щоб мати одну домінуючу URL-адресу. Тому ви можете просто налаштувати mycompany.com для переспрямування на www.mycompany.com. Більшість менеджерів доменів мають функцію налаштування цього переспрямування. Це зазвичай називають веб-переспрямуванням.

HTTPS/SSL

Якщо переспрямування налаштовано правильно, платформа автоматично згенерує сертифікат SSL із Let’s Encrypt протягом години, і ваш домен буде доступний через HTTPS.

Хоча наразі неможливо налаштувати власні сертифікати SSL на платформі Odoo.sh, ми розглядаємо цю функцію, якщо буде достатній попит.

Відповідність SPF і DKIM

Якщо в домені електронних адрес ваших користувачів використовується SPF (Sender Policy Framework) або DKIM (DomainKeys Identified Mail), не забудьте авторизувати Odoo як хост-відправник у налаштуваннях свого доменного імені, щоб збільшити доставку ваших вихідних електронних листів. Етапи налаштування пояснюються в документації про SPF і DKIM.

Попередження

Якщо забути налаштувати SPF або DKIM, щоб авторизувати Odoo як хост-відправник, ваші електронні листи потраплятимуть у папку вхідних контактів як спам.

Команди оболонки

У верхньому правому куті перегляду доступні різні команди оболонки.

Кожну команду можна скопіювати в буфер обміну для використання в терміналі, а деякі з них можна використати безпосередньо з Odoo.sh, натиснувши кнопку виконати. У такому разі спливаюче вікно запропонує користувачеві визначити можливі заповнювачі, наприклад як <URL> ``, ``<PATH>, …

Клонувати

Завантажити репозиторій Git.

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

Клонує репозиторій odoo/odoo.

• --recurse-submodules: завантажує підмодулі вашого сховища. Також завантажуються субмодулі, що входять до складу субмодулів.

• --branch: перевіряє певну гілку репозиторію, у цьому випадку master.

Кнопка виконати недоступна для цієї команди, оскільки вона призначена для використання на ваших машинах.

Fork

Створює нову гілку на основі поточної гілки.

$ git checkout -b feature-1 master

Створює нову гілку під назвою feature-1 на основі гілки master, а потім переходить в неї.

$ git push -u origin feature-1

Завантажує нову гілку feature-1 у ваш віддалений репозиторій.

З’єднати

Об’єднує поточну гілку в іншу гілку.

$ git merge staging-1

Об’єднує гілку staging-1 у поточну гілку.

$ git push -u origin master

Завантажує зміни, які ви щойно додали, у гілку master у вашому віддаленому сховищі.

SSH

Встановлення

Щоб використовувати SSH, вам потрібно налаштувати відкритий SSH-ключ вашого профілю (якщо це ще не зроблено). Для цього виконайте такі дії:

1. Створити новий ключ SSH

2. Скопіювати ключ SSH у буфер обміну ( застосувати лише крок 1)

3. Вставити скопійований вміст до SSH-ключів вашого профілю та натиснути «Додати»

   

4. Ключ має з’явитися нижче

   

З’єднання

Щоб підключитися до своїх збірок за допомогою ssh, скористайтеся такою командою в терміналі:

$ ssh <build_id>@<domain>

Ви знайдете ярлик для цієї команди на вкладці SSH у верхньому правому куті.

За умови, що у вас є правильні права доступу у проекті вам буде надано ssh доступ до збірки.

Примітка

Тривалі з’єднання ssh не гарантуються. Неактивні підключення буде відключено, щоб звільнити ресурси.

Підмодуль

Додайте гілку з іншого репозиторію у вашу поточну гілку як підмодуль.

Підмодулі дозволяють використовувати модулі з інших сховищ у вашому проекті.

Функцію підмодулів детально описано в розділі Підмодулі цієї документації.

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

Додає гілку master репозиторію <URL> як підмодуль у шляху <PATH> у вашій поточній гілці.

$ git commit -a

Фіксує всі поточні зміни.

$ git push -u origin master

Завантажує зміни, які ви щойно додали, у гілку master у вашому віддаленому сховищі.

Видалити

Видаляє гілку зі свого сховища.

$ git push origin :master

Видаляє гілку у вашому віддаленому сховищі.

$ git branch -D master

Видаляє гілку у вашій локальній копії сховища.