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

Організація робочого процесу 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. Update the PHP configuration if needed (like adding the PostgreSQL PHP extension);
5. Оновіть інфраструктуру Docker і Platform.sh, якщо це необхідно (додайте сервіс PostgreSQL);
6. Протестуйте локально;
7. Протестуйте віддалено;
8. Об'єднайте гілку з основною;
9. Розгорніть у продакшн;
10. Видаліть гілку.

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

1
2
3
4
5
6
7
8
9
10
11

--- 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
         storage_factory_id: session.storage.factory.native

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

1

$ symfony console make:migration

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

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

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

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

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).

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

1

$ symfony cloud:env:delete sessions-in-db

1

$ symfony cloud:deploy

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

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

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

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

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

1

$ symfony cloud:url -1

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

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

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

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

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

1

$ symfony cloud:env:sync

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

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

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

1

$ symfony cloud:env:debug

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

1

$ symfony cloud:env:debug --off

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

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

Зверніться до кроку про doc:`Продуктивність <29-performance>`, щоб дізнатися більше про те, як можна використовувати Blackfire для тестування коду перед розгортанням.

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

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

1
2

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

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

1

$ symfony cloud:deploy

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

Очищування

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

1
2

$ git branch -d sessions-in-db
$ symfony cloud:env:delete -e sessions-in-db