Гілки

Огляд

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

Етапи

Odoo.sh пропонує три різні етапи для ваших гілок: production, staging та development.

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

Production

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

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

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

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

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

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

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

Staging

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

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

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

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

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

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

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

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

Development

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вкладки

Історія

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

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

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

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

Листи

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

Shell

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

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

Примітка

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

Редактор

Онлайнове інтегроване середовище development (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 щомісячних резервних копій. Кожна резервна копія містить дамп бази даних, сховище файлів (вкладення, бінарні поля), журнали та сеанси.

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

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

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

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

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

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

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

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

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

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

Оновлення

Доступно для production та staging гілок для дійсних проектів.

Перегляньте також

Оновлення - Odoo.sh

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

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

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

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

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

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

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

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

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

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

Набір тестів

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

Версія Odoo

Лише для гілок development ви можете змінити версію 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 як хоста-відправника, ваші ел. листи потраплятимуть у папку «Вхідні» як спам.

Команди Shell

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

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

Clone

Завантажити репозиторій 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 не гарантуються. Неактивні підключення буде відключено, щоб звільнити ресурси.

Submodule

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

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

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

$ 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

Видаляє гілку у вашій локальній копії репозиторію.