هل أبدأ أتعلم TDD؟ ولا أكتب الاختبارات بعدين؟

الصراحة؟ هذا مو السؤال الحقيقي.
السؤال اللي فعلًا لازم تسأله:
هل الكود اللي تكتبه أصلًا قابل للاختبار؟
الموضوع مو عن التوقيت ولا الطريقة.
ناس تمشي مع TDD، وناس تكتب الاختبارات بعد ما تخلص.
بس كل هذا ما يفرق إذا كودك نفسه ما يسمح تنختبره.
خلني أقولك أربع مبادئ إذا فهمتها، بتقدر تختار طريقتك بنفسك، وبتفهم ليش فيه ناس تفضل TDD وناس لا. بتصير كل الطرق منطقية لأنك عرفت الأساس.

1. قلل الآثار الجانبية – Minimise Side Effects

الاختبار يتعقد إذا كودك:

يكتب على الهاردسك

يرسل طلبات HTTP

يتعامل مع الوقت

يتأثر بالبيئة

يعني ببساطة: يعتمد على أشياء ما تقدر تتحكم فيها.
الحل؟ افصل هالجزء عن منطقك، وخله في طبقة خارجية، بحيث تقدر تختبر منطقك بدون ما تدخل في تعقيدات خارجية.

2. اعزل التبعيات – Isolate Dependencies

إذا كلاسك هو اللي ينشئ الأشياء اللي يحتاجها بنفسه، فبتضطر تختبر أشياء مالك دخل فيها.
الحل؟ مرر له التبعيات من برّا، ويفضل تكون عبر Interfaces.
كذا تقدر تسوي لها Mock بسهولة وقت الاختبار.

3. قلل المسؤوليات – Narrow Responsibilities

الميثود اللي تسوي كل شيء؟ مستحيل تختبرها بشكل فعّال.
خلي كل كلاس أو ميثود له مسؤولية واحدة.
الوضوح في الهدف = سهولة في الاختبار.

4. عرف السلوك بوضوح – Define Explicit Behaviours

لا ترجع أشياء غامضة زي true/false بدون سياق.
ولا ترجع object عام وما توضح فيه شيء.
ولا تسوي استثناء وتسكت عليه.
وضح وش تتوقع يصير، وخلي سلوك كودك واضح زي الشمس.

طيب متى نقول عن اختبار إنه "مو اختبار وحدة"؟

مايكل فيذرز قالها بكل وضوح:

"الاختبار لا يعتبر اختبار وحدة (Unit Test) إذا:

تواصل مع قاعدة البيانات

أو مع الشبكة

أو نظام الملفات

أو ما يشتغل مع باقي اختبارات الوحدة في نفس الوقت

أو يحتاج تعديلات على بيئة التشغيل (زي الإعدادات)"

ببساطة: إذا طلع برا الكود واختلط بأشياء خارجية؟ ما عاد اختبار وحدة.

الخلاصة؟

الموضوع ما هو متى تكتب الاختبار.
الموضوع: هل تقدر تختبر كودك أصلاً؟
افهم المبادئ اللي فوق، وصدقني…
وقتها بتعرف الطريق اللي يناسبك بدون ما أحد يقولك وش تسوي.
الاختبار مو هدف.
الاختبار نتيجة طبيعية لكود نظيف ومحترم.

#اختبار_الوحدات #CleanCode #TDD #برمجة #تطوير_البرمجيات #قابلية_الاختبار

بتشوفوا كثير هالأيام ناس يقولوا "تبني تطبيق كامل في ساعتين أين كان ".
الكلام ذا مش كذب، بس خذوها بعقل.

ما حد قال إنك بتسوي ERP يحل مشاكل المحاسبة وإدارة الموارد، وتخلي أوراكل أو غيرها ترجع بيتها!

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

الذكاء الاصطناعي بيرفع من إنتاجية المهندسين الفَلاطِحَة بشكل رهيب،
بس ما بيحول أي حد لمهندس يقدر يبني أنظمة ثقيلة ومعقدة، لسه ما وصلنا هناك.

استخدموا عقولكم، هي أغلى نعمة، لا تضيعوها.

الجامعة هي الفرصة الي من خلالها تتعلم أشياء كثيره  فستغلها بكل طاقتك كلامي ليس تطلع الأول وتكون تنين الدفعة 💁‍♂️

أهم شي أولًا: خليها تشتغل (First, make it work)
بعدين تقدر تزبط الشكل (Then make it pretty)
ولا تنسى تضيف اختبارات كثير (Add safety with lots of tests) عشان تتأكد إن كل شي تمام.
ابعد عن التعقيد الزايد (Stay away from over-engineering)، خلك بسيط وواضح.
وإذا حسيت الكود يبيله ترتيب؟ عدله ونسّقه (Refactor if needed – and it usually is!)

الـ Refactoring هو السلاح الخفي اللي يخلي كودك نظيف وسهل تتعامل معه.
خلك ذكي، نظّم كودك، واستمتع بالبرمجة!

#يوميات_مبرمج #Refactoring #CleanCode #نصايح_كود #برمجة

العنوان: "لو كلمت شات جي بي تي، كان حضرلي المحاضرة"

المعيد داخل المحاضرة، ماسك اللابتوب، والشرح شغال كأننا شغالين في جوجل،
وإحنا أصلاً لسه مش عارفين نثبت لينكس!

من سنة أولى لسنة ثالثة، بنتكلم عن أنظمة تشغيل، شبكات، قواعد بيانات، ولغات برمجة.
بس الواقع؟
أنا ما ثبتش لينكس، ولا مرة.
درست PHP، درست Python، بس ولا مرة كتبت كود حقيقي فيهم.

اللي اكتشفته؟
الموضوع مش ملزم!
يعني محدش بيتابع وراك إذا كنت فعلًا طبّقت ولا لأ،
إنت حر... تكتب في التقرير إنك عملت كل حاجة، وهما هيصدقوك.

المعيد بيشرحلك كأنك هتطلع بكرا تبني نظام تشغيل،
وإنت مش عارف تفرق بين CMD و Terminal.
بيطلب منك مشاريع مش بتتناسب مع اللي إنت فهمته أصلًا،
وبيعتبر أي سؤال إضافي "تضييع وقت".

طب لو كلمت شات جي بي تي، يحضرلي المحاضرة؟
أيوه، ويحضرها كمان بفهم، ويشرحلي بعد المحاضرة بمنطق وهدوء.

الجامعة بتقولك: "اللي عايز يتعلم، يتعلم لوحده."
طب ما توريني الطريق الأول؟ ما تديني تجربة حقيقية؟
مش تحفظني أوامر وخليني أكتب كود في Word!

المشكلة مش في المادة... المشكلة في طريقة التدريس، وفي عدم ربط العلم بالحياة.

أنا ما ثبتش لينكس، لكن كتبت في التقرير إني ثبتّه
ما برمجتش بـ PHP، لكن نجحت في المادة.
ليه؟
لأن النظام بيربي طالب بيجيد التمثيل، مش التطبيق.

فـ لو إنت طالب ولسه بتقول "هبدأ لما أخلص المنهج"،
أحب أقولك: المنهج مش هيخلص،
ابدأ من دلوقتي، واشتغل على نفسك بنفسك،
لأن الجامعة مش دايمًا بتعرف تجهزك... لكن أنت تقدر تجهّز نفسك.

فكرة إنك تضيف بوابة دفع في مشروعك مش حاجة واوو، الفكرة الحقيقية هي: هل انت مستعد تحمي نفسك من الفخاخ اللي جاية بعدها ولا لا؟

تعال نعرف مع بعض رحلة الدفع كيف بتم، وإيش الفخاخ اللي لازم نخلي بالنا منها من بدري. خلينا نمشيها "فخاخ" كذا كأنك ماشي في أرض ألغام!

شوف يا صديقي، العملية ماشية كذا:

تسجل العملية في قاعدة البيانات ترسل الطلب لبوابة الدفع عشان يتم تستلم التأكيد من بوابة الدفع (وهنا تبدأ الفخاخ!)

المحطة الأولى:
تسجيل العملية
أول حاجة تعملها إنك تسجل البيانات هذي عندك:

مين هو العميل؟ المبلغ كم؟ حالة العملية (بانتظار الدفع). تاريخ الطلب.
ليش نسوي كذا؟ لأن البيانات هذي بتكون المرجع لك لما تجي تتأكد من نجاح العملية. ولو نسيتها؟ مبروك عليك المشاكل يا صاحبي!

المحطة الثانية:
إرسال الطلب لبوابة الدفع
هنا الموضوع سهل، السيستم حقك يرسل البيانات لبوابة الدفع، والعميل يدخل بيانات البطاقة أو أي وسيلة دفع ثانية. ذي مش شغلتك، لأن بوابة الدفع هي اللي بتتعامل مع البنك والمشاكل التقنية هناك.

المحطة الثالثة:
استلام التأكيد (وهنا تبدأ الفخاخ!) الفخ الأول: إنك تصدق أي رد من بوابة الدفع!

بوابة الدفع ردت وقالت لك "تم الدفع"، رحت حدثت العملية عندك لـ "مدفوعة"، وسويت كل الخطوات؟ للأسف، ممكن يكون اتنصب عليك!

ليش؟ فيه أدوات مثل Charles Proxy و Burp Suite تخلّي أي أحد يعترض الطلب اللي رايح لبوابة الدفع، ويرد عليك هو، قبل ما يوصل الطلب. فيرسل لك بيانات مزيفة، وانت تصدق إنها حقيقية!

الحل؟ بعد ما توصلك البيانات، لازم ترسل Request ثاني من الباك إند لبوابة الدفع وتتأكد إن العملية فعلًا تمت هناك، مش مجرد أحد يضحك عليك.

الفخ الثاني:
التلاعب في المبلغ
حتى لو تأكدت إن العملية نجحت، انت متأكد إن العميل دفع المبلغ الصحيح؟

ممكن أحد يلعب في البيانات اللي رايحة لبوابة الدفع، مثلًا: اشترى منتج بـ100 دولار، لكن بدل ما توصل البوابة إنها تخصم 100، وصلها إنها تخصم 2 دولار بس!

الحل؟ لما تبعت طلب التأكيد لبوابة الدفع، لا تسأل بس "هل العملية نجحت؟"، لازم تسأل كمان "المبلغ كم؟"، وتقارنه باللي عندك.

الفخ الثالث:
حيلة استرجاع الفلوس (Refund Fraud)

العميل ممكن يدفع، وبعدها يتصل بالبنك ويقول إنه ما كان هو اللي دفع، والبنك يرجع له الفلوس، وانت تخسر! والأسوأ؟

ممكن يدخل يعيد نفس العملية، وانت تخزنها عندك كأنها جديدة، ويرجع يسترجع الفلوس، ويعيد الحركة مرة ثانية وثالثة!
الحل؟

اتأكد إن العملية مازالت pending مش refunded. حدد وقت انتهاء لكل عملية دفع، ولو تأخر الوقت تلغيها تلقائي. اتفق مع بوابة الدفع على حد أدنى للدفع.

الفخ الرابع: تجاهل الـ Webhooks!

بعض المبرمجين يعتمدوا على الرد المباشر من بوابة الدفع، وذا أكبر خطأ!

ليش؟ العميل ممكن يقفل الصفحة قبل ما توصله الاستجابة، أو يصير تأخير في الرد.
الحل؟

اعتمد على Webhooks، اللي هي إشعارات تجيك من بوابة الدفع لما يصير أي تغيير. سيستمك لازم يكون قادر يستقبلها ويتعامل معها صح.

إضافات مهمة ل الشباب:

التعامل مع الـ Idempotency: أحيانًا يصير تأخير أو تكرار في الطلبات، ممكن يسبب تنفيذ العملية مرتين بالخطأ. الحل؟ استخدم Unique Transaction ID، وتأكد ما في معاملة مكررة.

الالتزام بـ PCI DSS Compliance: لو تتعامل مع بيانات البطاقات مباشرة، لازم تلتزم بالمعايير الأمنية، لأن ذا الشي مو خيار، بل إلزامي.

لا تخزن بيانات الكروت عندك نهائيًا. استخدم التوكنز أو Customer IDs اللي توفرها بوابة الدفع.

تأكد إن السيرفر هو اللي يتعامل مع بوابة الدفع، مش الفرونت إند. الـ Signature من بوابة الدفع يضمن إن الرد جاي من عندهم فعلاً، مش مزور، بس مش كافي لحاله. لازم كمان تتأكد إن الـ Transaction ID ما يتكرر، عشان تمنع Replay Attacks.

بالنسبة للفخ الثاني
(التلاعب في المبلغ)، لو قلنا إن الحل هو التأكد من الدفع عن طريق طلب خلفي، طيب ما هو ممكن نفس الشخص يعترض الرد الثاني؟ الحل؟
اعتمد على Webhook أو IPN يجيك مباشرة من بوابة الدفع.

تأكد إن كل Transaction ID يُستخدم مرة وحدة فقط وبمدة محددة.
وفي الأخير خليك دائمًا يقظ، وتأكد إن كل خطوة في الدفع محمية كويس. وصدقني، الأمان في الدفع مش مجرد خطوة، دي رحلة كاملة لازم تكون مستعد لها من البداية للنهاية!

#أمان_الدفع #بوابة_الدفع #تطوير_ويب #حماية_المدفوعات #أمن_المعلومات #المدفوعات_الإلكترونية #مطورين #نصائح_برمجية #تجربة_مطور #فخاخ_الدفع

هات لي  هندسة وبيزنس
مش كلها  تقنية معلومات
دي لما فكرت اربط بوابة دفع بمشروع التخرج ناهيك عن ربطها في مشاريع سابقه مش فاكرين قوي ذا الجانب طبعا بعد ما تكلمت مع واحد فاهم في هذا الجانب الكلام ده مش من رأسي دا من كلامه لن تحصل الكلام هذا لافي كتب ولا في المريخ الا من ناس جربت فكل الشكر لكل من يعطي  من وقته لتوضيح أهم الأشياء الي فعلا ناقصه 🙆

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

صدقني، هالأسلوب يخسّرك كثير. لأنك لما تلبس قناع الفاهم، تحرم نفسك من فرصة حقيقية للتعلم. يمكن صاحبك عنده خبرة، أو مرّ بتجربة، أو قرأ شيء مفيد، ولو سألته وقلت له: "صراحة أول مرة أسمعها، ممكن توضح لي؟" — راح يقدّرك ويحترم فيك رغبتك في الفهم.

لا تخلي الكبرياء يمنعك من إنك تطور نفسك. مافيش إنسان يعرف كل شيء، والعلم عمره ما كان عيب، العيب إنك تتهرب من الفهم علشان ما يبان إنك مش عارف.

خليك دائمًا من النوع اللي يسأل، ويفهم، ويتواضع. التواضع في طلب العلم رفعة، مو نقصان. واللي يسأل اليوم، بكرة يكون هو اللي يُسأل.

إذا أنت مبرمج التطبيقات اللي ندوّر عليه،
قدّم على وظيفة App Developer معنا🖱

– مشاريع إبداعية تنشاف وتُستخدم
– بيئة تشجّعك تطوّر وتبدع
– الدوام حضوري في مقر الشركة
– رواتب مجزية
– مقر العمل صنعاء - *#مدري*😁
للتقديم، قم بتعبئة الفورما التالية ⇓
https://forms.gle/wkQ4w3iXCvP7KdQs7


#منقول

يسعدنا في مجموعة هائل سعيد أنعم وشركاه إطلاق برنامج تمهيد - نواة المستقبل للتدريب الصيفي لطلاب وطالبات المستويين الأخيرين في الجامعات اليمنية لمنحهم فرصة التدريب خلال الإجازة الصيفية.
على مدار شهرين، سيوفر البرنامج للمشاركين فرصة فريدة لاكتساب خبرات وتطوير مهاراتهم من خلال التدريب عبر وظائف وشركات مختلفة في مجموعة هائل سعيد أنعم وشركاه. اغتنم هذه الفرصة لتنمية وتعزيز نموك الذاتي من خلال التسجيل في هذا البرنامج المصمم لإطلاق العنان لإمكانيات الجيل القادم. اضغط لمعرفة المزيد والتقديم:

https://careers.hsayemen.com/lp/تمهيد/d6f2094cd85a04d2/?locale=ar_SA

اغتنموا الفرصة و سجلوا للتدريب في البرنامج التدريبي التأهيلي الاستثنائي 🔥🔥

خير الله واجد
موقع من أفضل المواقع الي استفدت لعمل prototype أصحاب ui/ux
جربته والله ضخم جدا ال free في limit
أتمنى أن يفيدكم ب ai

https://www.visily.ai/

تحذير مهم: لا تستخدم الشبكات العامة للإنترنت لمشاركة معلومات حساسة!
هل تعلم أن اتصالك بشبكة Wi-Fi عامة (زي الموجودة في المقاهي أو المولات) ممكن يعرّض بياناتك للخطر؟ خاصة لو دخلت موقع غير آمن (يبدأ بـ http:// بدل https://)!
ليش؟
الشبكات العامة غير مشفّرة، وأي شخص على نفس الشبكة ممكن يتجسس على اتصالك. ممكن يسرق معلوماتك، كلمات المرور، أو حتى بياناتك البنكية باستخدام أدوات بسيطة! والمواقع الغير آمنة ما تقدم أي حماية لبياناتك.
الحل؟
لا تدخل معلوماتك الخاصة في شبكة عامة. لا تستخدم مواقع غير آمنة (تأكد من وجود علامة القفل في المتصفح). استخدم VPN إذا اضطررت للشبكة العامة. أو الأفضل: استخدم باقة الجوال عند الحاجة.
احمِ نفسك، وكن واعيًا في عالم الإنترنت.

"الذكاء الاصطناعي... الطفرة التي جعلتنا نلهث خلف العالم"

عندما بدأ الذكاء الاصطناعي بالانتشار، استفاد منه العالم المتقدم بشكل مذهل. تغيّرت طرق التعليم، وتطورت سُبل العلاج، وتحولت الشركات إلى نماذج أكثر ذكاءً ومرونة.
لكن بالنسبة لبلدان مثل اليمن، كانت الضربة أقسى من أن توصف.

لماذا؟

لأننا لم نكن قد وصلنا بعد إلى المرحلة التي كان فيها الآخرون قبل 10 سنوات، فجاء الذكاء الاصطناعي وقفز فوقنا بعقود. فصرنا لا نلحق فقط، بل نكافح لنفهم ما يحدث.

💔😂

عن تجربه 👇


عند استخدام GitHub، في خيارات مختلفة لتنظيم المشاريع والعمل الجماعي. في البداية، يمكن الواحد يبدأ بريبو في حسابه الشخصي، ويضيف الباقين كمساهمين. لكن مع مرور الوقت، بيواجهوا مشاكل، مثل:
الريبو بيكون مربوط بحساب شخص واحد، يعني لو الشخص هذا غاب أو حذف المشروع، بيضيع كل شيء. ما في صلاحيات واضحة بين الأعضاء، والكل يقدر يعدل أو يمسح من المشروع. الشكل العام للمشروع بيكون فوضوي، ما في هوية ثابتة للفريق أو المشروع.
لكن لو استخدمنا GitHub Organization بدلًا من الريبو الشخصي، الأمور بتتغير:
المشروع بيكون مرتبط باسم الفريق أو الشركة، مو باسم شخص واحد. تقدر توزع الصلاحيات بين الأعضاء بشكل واضح، سواء كانوا مالكين، مشرفين أو مطورين. لو واحد غاب أو خرج من الفريق، المشروع يظل محفوظ وما يتأثر. الشكل العام بيكون أكثر احترافية، وهذا مهم في حالة عرض الشغل أو في السيرة الذاتية.
الفرق بين الريبو الشخصي و Organization: الريبو الشخصي حلو لو بتشتغل لحالك، لكن في حالة العمل الجماعي، الـ Organization هي الخيار الأفضل، لأنها بتمنحك تحكمًا أفضل، وتنظيمًا دقيقًا للصلاحيات، وأمانًا أكبر للمشروع.
أما بالنسبة لـ Azure DevOps: هو قوي ولديه أدوات مفيدة مثل Pipelines و Boards، لكنه بيكون أكثر تعقيدًا في المشاريع الصغيرة. GitHub هو الأنسب في حالة المشاريع الجماعية الصغيرة أو الطلابية.
ولكن إذا كنت بتشتغل مع مجموعة أو على مشروع جماعي، استخدم GitHub Organization لأنه يوفر لك تنظيمًا أفضل وأمانًا للمشروع.

الصورة هذه توضح لك ليش DevOps

لا اريد ان اعمل تقييم لأي دكتور أو معيد لأن الوضع سيء ولا اريد ان يكون تقييمي يخرج دكتور أو معيد من مهنته مع ان التقييمات الطلابية غالبًا لا تؤخذ بالجدية الكافية أو لا تترجم إلى قرارات فعلية.

The resume said "10 years experience" The code said "1 year, ten times"

المرحلة الأولى: البداية والتخطيط

كنت في بداية المشروع، وقررت أنني سأستخدم Azure DevOps لتنفيذ الأتمتة، وكان الهدف أنني أتمكن من تسريع عمليات البناء والنشر باستخدام CI/CD pipeline.
لكن مع مرور الوقت، بدأت أواجه بعض التساؤلات التي كانت تقلقني:
"لماذا لا أستخدم GitHub Actions بدلاً من DevOps؟"
كنت أعرف أن GitHub Actions أصبح أحد الخيارات الشائعة في الأتمتة، وكان في بالي أن هذا الخيار قد يكون أسهل وأسرع.
لكن في الوقت نفسه، كنت أعلم أن Azure DevOps قد يقدم ميزات قوية أخرى، مثل التكامل السهل مع Microsoft Stack.

المرحلة الثانية: التساؤل عن GitHub Actions

بدأت أبحث في الفرق بين GitHub Actions و Azure DevOps:

GitHub Actions:

يوفر CI/CD مباشرة داخل GitHub.

يدعم الـ runners القابلة للتخصيص.

يعجبني أن GitHub هو المكان الذي أعمل فيه مباشرة مع المستودعات، لذا كان من الممكن أن يكون كل شيء في مكان واحد.

Azure DevOps:

يقدم بنية تحتية قوية للأتمتة.

يدعم الـ agents الجاهزة أو المحلية.

كنت أعرف أن Azure DevOps يعطي تحكمًا أكبر في بيئات العمل الحساسة، وهو شيء كنت أحتاجه لمشروعي.

لكن هنا بدأ السؤال يدور في رأسي: "هل GitHub Actions أفضل من Azure DevOps في هذه الحالة؟ أم أن Azure DevOps هو الخيار الأنسب نظرًا لمتطلبات الأمان والإدارة؟"

المرحلة الثالثة: الفرق بين Agent و Runner

بينما كنت أبحث، بدأت أتساءل:
"ما هو الفرق بين Agent و Runner؟"
كنت متأكدًا أن هناك شيء أساسي يفصل بين الاثنين، وكنت بحاجة لفهم هذا التفصيل.

الـ Agent (في Azure DevOps):

هو الخادم الذي يتولى عملية تنفيذ الـ pipeline.

يمكن أن يكون مستضافًا من قبل Microsoft أو مستضافًا محليًا (Self-hosted).

الـ Agent المستضاف يأتي جاهزًا من Microsoft، ويقوم بتشغيل المهام على بيئات مهيأة مسبقًا.

الـ Agent المحلي يمكن استخدامه لتخصيص البيئة بما يتناسب مع متطلبات الأمان والبنية التحتية الخاصة بك.

الـ Runner (في GitHub Actions):

هو نظير الـ Agent في GitHub Actions.

يعمل بنفس الطريقة، حيث يقوم بتشغيل المهام في البيئة المخصصة.

يمكنك استخدام Runner مستضاف من GitHub أو Runner محلي.

الفكرة في GitHub Actions أن الـ Runner يتحكم في بيئة العمل ولكن بتخصيص أكبر لاحتياجاتك، ويعمل مع كل مستودع على حدة.

المرحلة الرابعة: الأسئلة والتساؤلات الداخلية

بدأت أتساءل الآن بعد أن عرفت الفرق بين Agent و Runner:
هل أحتاج إلى استخدام DevOps Agent مع كل ميزاته الأمنية؟
أم أن GitHub Actions Runner سيحقق لي نفس النتائج، لكن بأسلوب أبسط؟
إذا كانت البيئة في شركتي حساسة، هل أحتاج إلى استخدام Self-hosted Agent (أو Self-hosted Runner في حالة GitHub Actions) لتحكم أكبر؟
لماذا أستخدم Agent من Azure DevOps إذا كنت أستطيع استخدام GitHub Actions مع Runner الذي يقدم تخصيص أكبر ومرونة أفضل في التعامل مع GitHub مباشرة؟

المرحلة الخامسة: القرار والتجربة

بعد التفكير والتساؤل، قررت أنني سأجرب كل خيار وأقيمه بناءً على الأمان والتحكم والتخصيص:

جربت GitHub Actions مع Runner:
كانت الفكرة بسيطة لأنني أعمل مع GitHub مباشرة.
الـ Runner المستضاف كان جيدًا، لكن شعرت أنني بحاجة إلى المزيد من التخصيص.
كان من السهل إعداد Self-hosted Runner ليتوافق مع بيئة العمل الخاصة بالشركة.

جربت Azure DevOps مع Agent:
البيئة كانت أكثر أمانًا وتخصيصًا.
الـ Agent المحلي أعطاني سيطرة أكبر على البيانات والبنية التحتية.
شعرت أن Azure DevOps يوفر تكامل أفضل مع الأنظمة الداخلية في شركتي.

المرحلة السادسة: التقييم النهائي

الآن وبعد التجربة:
هل GitHub Actions أفضل من Azure DevOps؟
بالنسبة لمشاريع صغيرة أو إذا كنت تعمل داخل GitHub فقط، يمكن أن يكون GitHub Actions خيارًا جيدًا بفضل مرونته.
أما إذا كنت بحاجة إلى تحكم أمني كامل في بيئة العمل، فـ Azure DevOps و الـ Agent المحلي سيكون أفضل بكثير.

النصيحة:

إذا كانت بيئة العمل في شركتك حساسة ولا تستطيع المخاطرة باستخدام حلول مستضافة من جهة خارجية، فإن Self-hosted Agent في Azure DevOps هو الخيار الأكثر أمانًا.
إذا كانت المرونة و التخصيص أكثر أهمية بالنسبة لك وتعمل بشكل أساسي على GitHub، فإن GitHub Actions مع Self-hosted Runner يمكن أن يكون الخيار الأفضل.


#Devops
#On_Promise

لو كنت تتواصل مع الذكاء الاصطناعي طوال يومك، تذكر أن تطلب منه في نهاية اليوم أن يسرد لك كل ما ناقشته معه. هذه الطريقة ستساعدك على تنظيم أفكارك وتوثيق كل النقاط المهمة. اليوم، كنت أعمل على تجربة أدوات الأتمتة، مثل GitHub Actions و Azure DevOps، وكنت أتساءل عن الفرق بين الـ Agent والـ Runner. مع الوقت، جربت الـ Self-hosted Agent في Azure DevOps، وأدركت الفرق الكبير في الأمان والتحكم في بيئة العمل. هذه التجربة غيرت الطريقة التي أفكر بها في تخصيص الأتمتة واستخدام الأدوات بشكل أكثر فاعلية. تعلمت الكثير، وحققت تحسن كبير في تطبيقاتي.