SymfonyWorld Online 2020
100% online
30+ talks + workshops
Live + Replay watch talks later

خطوة 11: تفرع الكود

5.0 version
Maintained

تفرع الكود

هناك العديد من الطرق لتنظيم سير عمل تغييرات الكود في المشروع. لكن العمل مباشرة على الفرع الرئيسي (master) في GIT والنشر المباشر للإنتاج (production) دون اختبار ليست ربما أحسن طريقة.

لا يقتصر الاختبار على اختبارات الوحدات أو الاختبارات الوظيفية فحسب ، بل يتعلق أيضًا بالتحقق من سلوك التطبيق مع بيانات الإنتاج (production). إذا تمكنت أنت أو أصحاب المصلحة stakeholders من تصفح التطبيق تمامًا كما سيتم نشره للمستخدمين النهائيين ، فستصبح هذه ميزة كبيرة ستمكنك من النشر بثقة. انه شيء رائع عندما يتمكن الأشخاص الغير التقنيين من التحقق من صحة الميزات الجديدة.

سنواصل القيام بكل العمل في الفرع الرئيسي (master) ل Git في الخطوات التالية للتبسيط وتجنب التكرار، ولكن دعونا نرى كيف يمكننا تحسين ما قمنا به.

اعتماد سيرة عمل لنظام GIT.

سير عمل بسيط وفعال ممكن استعماله هو إنشاء فرع واحد لكل وظيفة جديدة أو إصلاح خلل.

وصف البنية التحتية (Infrastructure)

ربما لم تكن قد أدركت ذلك بعد ، ولكن وجود بنية تحتية (infrastructure) مخزنة في ملفات بجانب الكود يساعد كثيرًا. يستخدم Docker و SymfonyCloud ملفات الضبط لوصف البنية التحتية (infrastructure) للمشروع. عندما تحتاج وظيفة جديدة إلى خدمة إضافية ، فإن التغييرات في الكود والتغييرات في البنية التحتية هي جزء من نفس التصحيح.

إنشاء فروع

يبدأ سير العمل بإنشاء فرع Git:

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

يقوم هذا الأمر بإنشاء فرع " sessions-in-redis '' من الفرع `` الرئيسي / master ''. فإنه ينشئ فرع "fork" للكود وتكوين (configuration) البنية التحتية.

تخزين الجلسة في Redis

كما كنت قد خمنت إنطلاقا من إسم الفرع، نريد تغيير تخزين الجلسات من نظام الملفات إلى متجر Redis.

الخطوات اللازمة لتحقيق المبتغى هي نموذجية:

  1. إنشاء فرع في GIT؛
  2. تحديث تكوين Symfony إذا إستلزم الأمر؛
  3. كتابة و / أو تحديث بعض الكود إذا إستلزم الأمر؛
  4. تحديث تكوين PHP (إضافة إمتداد Redis PHP)؛
  5. تحديث البنية التحتية في Docker و SymfonyCloud (إضافة خدمة Redis)؛
  6. الإختبار محليًا
  7. الإختبار عن بعد؛
  8. دمج الفرع في الفرع الرئيسي (Master)؛
  9. النشر في الإنتاج (production)؛
  10. حذف الفرع؛

يمكن إجراء جميع التغييرات المطلوبة من 2 إلى 5 في رقعة واحدة:

patch_file
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
--- a/.symfony.cloud.yaml
+++ b/.symfony.cloud.yaml
@@ -15,8 +15,13 @@ runtime:
 build:
     flavor: none

+variables:
+    php-ext:
+        redis: 5.3.1
+
 relationships:
     database: "db:postgresql"
+    redis: "rediscache:redis"

 web:
     locations:
--- a/.symfony/services.yaml
+++ b/.symfony/services.yaml
@@ -2,3 +2,6 @@ db:
     type: postgresql:11
     disk: 1024
     size: S
+
+rediscache:
+    type: redis:5.0
--- 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(REDIS_URL)%'
         cookie_secure: auto
         cookie_samesite: lax

--- a/docker-compose.yaml
+++ b/docker-compose.yaml
@@ -8,3 +8,7 @@ services:
             POSTGRES_PASSWORD: main
             POSTGRES_DB: main
         ports: [5432]
+
+    redis:
+        image: redis:5-alpine
+        ports: [6379]

أليس هذا رائع؟

"إعادة تشغيل" Docker لبدء خدمة Redis:

1
2
$ docker-compose stop
$ docker-compose up -d

سأتيح لك فرصة الإختبار محليًا من خلال تصفح الموقع. نظرًا لعدم وجود تغييرات ولأننا لا نستخدم الجلسات حتى الآن ، فكل شيء يسير كما كان من قبل.

نشر فرع

قبل النشر في الإنتاج ، يجب أن نختبر الفرع على نفس البنية التحتية المطابقة للإنتاج. يجب أن نتحقق أيضًا أن كل شيء يعمل بشكل جيد لبيئة prod ل Symfony (الموقع المحلي يستخدم بيئة dev ل Symfony.

أولاً ، تأكد من تنفيذ (commit) التغييرات على الفرع الجديد:

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

الآن ، دعنا ننشئ * بيئة ل SymfonyCloud * على أساس * فرع Git * :

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

هذا الأمر ينشئ بيئة جديدة على النحو التالي:

  • يرث هذا الفرع الكود والبنية التحتية من فرع Git الحالي"sessions-in-redis"؛
  • تأتي البيانات من الفرع الرئيسي (master) (المعروفة أيضًا بالإنتاج - production ) من خلال أخذ لقطة متسقة لجميع بيانات الخدمة ، بما في ذلك الملفات ( على سبيل المثال الملفات التي يقوم المستخدم بتحميلها) وقواعد البيانات؛
  • يتم إنشاء مجموعة جديدة (cluster) مخصصة لنشرالكود والبيانات والبنية التحتية.

نظرًا لأن النشر يتبع نفس خطوات النشر في الإنتاج ، فسيتم تنفيذ عمليات ترحيل قاعدة البيانات أيضًا. هذه طريقة رائعة للتحقق من أن عمليات الترحيل تعمل مع بيانات الإنتاج.

الفروع الغير `` الرئيسية '' تشبه إلى حد كبير `` الرئيسية '' باستثناء بعض الاختلافات الصغيرة: على سبيل المثال ، لا يتم إرسال رسائل البريد الإلكتروني افتراضيًا.

بمجرد الإنتهاء من النشر ، افتح الفرع الجديد في متصفح:

1
$ symfony open:remote

لاحظ أن جميع أوامر SymfonyCloud تعمل على فرع Git الحالي. يفتح هذا الأمر عنوان URL المنشور لفرع "sessions-in-redis"؛ سيبدو عنوان URL كما يلي: "https://sessions-in-redis-xxx.eu.s5y.io/"

اختبر الموقع على هذه البيئة الجديدة ، يجب أن تشاهد جميع البيانات التي أنشأتها في البيئة الرئيسية.

إذا قمت بإضافة المزيد من المؤتمرات حول البيئة "الرئيسية / master '' ، فلن تظهر في بيئة "sessions-in-redis" والعكس صحيح. البيئات مستقلة ومعزولة.

إذا تطور الكود في الفرع الرئيسي (Master) ، يمكنك دائمًا إعادة بناء (Rebase) فرع Git ونشر الإصدار المحدث ، وحل كل التعارضات (conflicts) لكل من الكود والبنية التحتية.

يمكنك حتى مزامنة البيانات من الفرع الرئيسي(Master) مرة أخرى إلى بيئة "sessions-in-redis":

1
$ symfony env:sync

تصحيح أخطاء عمليات النشر للإنتاج قبل النشر

بشكل افتراضي ، تستخدم جميع بيئات SymfonyCloud نفس الإعدادات مثل بيئة "Master" / "prod (تعرف أيضًا ببيئة Symfony" prod ''). هذا يسمح لك باختبار التطبيق في ظروف الحياة الحقيقية. يمنحك الشعور بالتطوير والاختبار مباشرة في الإنتاج (production servers) ، ولكن دون المخاطر المرتبطة بها. هذا يذكرني بالأيام الخوالي عندما كنا ننشر عبر FTP.

في حالة وجود مشكلة ، قد ترغب في التغيير إلى بيئة "dev" ل Symfony :

1
$ symfony env:debug

عند الانتهاء ، ارجع إلى إعدادات الإنتاج:

1
$ symfony env:debug --off

Warning

لا تقوم ابداً بتمكين بيئة التطوير (dev) ولا تقوم ايضاً بتمكين أداة تعريف سيمفوني علي الفرع الرئيسي (master)؛ فهذا سوف يجعل تطبيقك بطئ جداً وسوف يفتح الكثير من الثغرات الأمنية الخطيرة.

اختبار عمليات نشر الإنتاج (production deployments) قبل النشر

الوصول إلى الإصدار القادم من الموقع مع بيانات الإنتاج (production) يتيح الكثير من الفرص: من اختبار الانحدار البصري (visual regression) إلى اختبار الأداء (performance). Blackfire <https://blackfire.io> _ هي الأداة المثالية لهذه المهمة.

ارجع إلى خطوة "الأداء (performance)" لمعرفة المزيد حول كيفية استخدام Blackfire لاختبار الكود قبل النشر.

الإدماج في الإنتاج (production)

عندما تكون راضيًا عن تغييرات في الفرع ، قم بدمج الكود والبنية التحتية مرة أخرى في فرع Git الرئيسي (master):

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

وقم بالنشر:

1
$ symfony deploy

عند النشر ، يتم فقط دفع التغييرات فيالكود والبنية الأساسية إلى SymfonyCloud ؛ لا تتأثر البيانات بأي شكل من الأشكال.

التنظيف

وأخيرًا ، قم بالتنظيف بإزالة فرع Git وبيئة SymfonyCloud:

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

  • « Previous خطوة 10: إنشاء واجهة المستخدم
  • Next » خطوة 12: الاستماع إلى الأحداث

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