Крок 11: Розгалуження коду

5.2 version
Maintained

Розгалуження коду

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

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

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

Організація робочого процесу Git

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

Створення гілок

Робочий процес починається зі створення гілки Git:

1
$ git branch -D sessions-in-db || true
1
$ git checkout -b sessions-in-db

Ця команда створює гілку sessions-in-db із гілки master. Це «розгалужує» код і конфігурацію інфраструктури.

Зберігання сесій у базі даних

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

Необхідні кроки, щоб зробити це реальністю, типові:

  1. Створіть гілку Git;
  2. Оновіть конфігурацію Symfony, якщо це необхідно;
  3. Напишіть та/або оновіть код, якщо це необхідно;
  4. Оновіть конфігурацію PHP, якщо це необхідно (наприклад, додайте розширення PHP PostgreSQL);
  5. Оновіть інфраструктуру Docker і SymfonyCloud, якщо це необхідно (додайте сервіс PostgreSQL);
  6. Протестуйте локально;
  7. Протестуйте віддалено;
  8. Об’єднайте гілку з основною;
  9. Розгорніть у продакшн;
  10. Видаліть гілку.

Щоб зберігати сесії в базі даних, змініть конфігурацію session.handler_id так, щоб вона вказувала на DSN бази даних:

patch_file
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
--- a/config/packages/framework.yaml
+++ b/config/packages/framework.yaml
@@ -7,7 +7,7 @@ framework:
     # Enables session support. Note that the session will ONLY be started if you read or write from it.
     # Remove or comment this section to explicitly disable session support.
     session:
-        handler_id: null
+        handler_id: '%env(DATABASE_URL)%'
         cookie_secure: auto
         cookie_samesite: lax

Щоб зберігати сесії в базі даних, нам потрібно створити таблицю sessions. Зробіть це за допомогою міграції Doctrine:

1
$ symfony console make:migration

Відредагуйте файл, щоб додати створення таблиці в методі up():

patch_file
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
--- a/migrations/Version00000000000000.php
+++ b/migrations/Version00000000000000.php
@@ -21,6 +21,14 @@ final class Version00000000000000 extends AbstractMigration
     {
         // this up() migration is auto-generated, please modify it to your needs

+        $this->addSql('
+            CREATE TABLE sessions (
+                sess_id VARCHAR(128) NOT NULL PRIMARY KEY,
+                sess_data BYTEA NOT NULL,
+                sess_lifetime INTEGER NOT NULL,
+                sess_time INTEGER NOT NULL
+            )
+        ');
     }

     public function down(Schema $schema) : void

Виконайте міграцію бази даних:

1
$ symfony console doctrine:migrations:migrate

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

Примітка

Тут нам не потрібні кроки 3-5, оскільки ми повторно використовуємо базу даних у якості сховища сесій, але глава про використання Redis показує, наскільки просто додати, протестувати і розгорнути новий сервіс як у Docker, так і в SymfonyCloud.

Оскільки нова таблиця не «управляється» Doctrine, ми маємо налаштувати Doctrine так, щоб таблиця не видалялася під час наступної міграції бази даних:

patch_file
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
--- a/config/packages/doctrine.yaml
+++ b/config/packages/doctrine.yaml
@@ -5,6 +5,8 @@ doctrine:
         # IMPORTANT: You MUST configure your server version,
         # either here or in the DATABASE_URL env var (see .env file)
         #server_version: '13'
+
+        schema_filter: ~^(?!session)~
     orm:
         auto_generate_proxy_classes: true
         naming_strategy: doctrine.orm.naming_strategy.underscore_number_aware

Зафіксуйте свої зміни в новій гілці:

1
2
$ git add .
$ git commit -m'Configure database sessions'

Розгортання гілки

Перш ніж розгорнути гілку в продакшн, ми маємо перевірити її на тій самій інфраструктурі, що і продакшн. Ми також маємо переконатися, що все добре працює в середовищі Symfony prod (локальний веб-сайт використовував середовище Symfony dev).

Тепер, створімо середовище SymfonyCloud на основі гілки Git:

1
$ symfony env:delete sessions-in-db --no-interaction
1
$ symfony env:create

Ця команда створює нове середовище наступним чином:

  • Гілка успадковує код і інфраструктуру від поточної гілки Git (sessions-in-db);
  • Дані надходять з основного (продакшн) середовища шляхом створення послідовного знімка всіх службових даних, включаючи файли (наприклад, завантажені користувачем) та бази даних;
  • Для розгортання коду, даних та інфраструктури створюється новий виділений кластер.

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

Будь-яке середовище відмінне від master майже ідентичне, за винятком невеликих відмінностей: наприклад, електронні листи не надсилаються за замовчуванням.

Після завершення розгортання відкрийте нову гілку в браузері:

1
$ symfony open:remote

Зверніть увагу, що всі команди SymfonyCloud працюють у поточній гілці Git. Ця команда відкриває URL-адресу для щойно розгорнутої гілки sessions-in-db; посилання матиме приблизно наступний вигляд: https://sessions-in-db-xxx.eu.s5y.io/.

Протестуйте веб-сайт у цьому новому середовищі, ви маєте побачити всі дані, які ви створили в основному середовищі.

Якщо ви додасте більше конференцій в середовищі master, вони не будуть відображатися в середовищі sessions-in-db і навпаки. Середовища є незалежними й ізольованими.

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

Ви навіть можете синхронізувати дані з основного середовища до середовища sessions-in-db:

1
$ symfony env:sync

Налагодження розгортання в продакшн

За замовчуванням всі середовища SymfonyCloud використовують ті ж налаштування, що й середовище master/prod (середовище Symfony prod). Це дозволяє протестувати застосунок у реальних умовах. Таким чином створюється відчуття розробки та тестування безпосередньо на продакшн-серверах, але без пов’язаних з цим ризиків. Це нагадує мені про старі добрі часи, коли ми розгортали через FTP.

У разі виникнення проблем, можливо, ви захочете перемкнутися на середовище Symfony dev:

1
$ symfony env:debug

Після закінчення поверніться до продакшн налаштувань:

1
$ symfony env:debug --off

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

Ніколи не вмикайте середовище dev і ніколи не вмикайте Symfony Profiler у гілці master. Це зробить ваш застосунок дуже повільним і відкриє багато серйозних вразливостей у системі безпеки.

Тестування розгортання в продакшн

Наявність доступу до майбутньої версії веб-сайту з продакшн даними відкриває безліч можливостей: від візуального регресійного тестування до тестування продуктивності. Blackfire — це ідеальний інструмент для роботи.

Зверніться до кроку про «Продуктивність», щоб дізнатися більше про те, як можна використовувати Blackfire для тестування коду перед розгортанням.

Об’єднання з продакшн

Коли вас влаштовують зміни в гілці, об’єднайте код та інфраструктуру з основною гілкою Git:

1
2
$ git checkout master
$ git merge sessions-in-db

І розгорніть:

1
$ symfony deploy

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

Очищування

Нарешті, очистьте, видаливши гілку Git і середовище SymfonyCloud:

1
2
$ git branch -d sessions-in-db
$ symfony env:delete --env=sessions-in-db --no-interaction

  • « Previous Крок 10: Створення інтерфейсу користувача
  • Next » Крок 12: Прослуховування подій

This work, including the code samples, is licensed under a Creative Commons BY-NC-SA 4.0 license.