المقدمة

كلنا عارفين GitHub وأهميته في كونه منصة لاستضافة الـ Code Repositories باستخدام Git Version Control. و GitHub بيتم استعماله على نطاق واسع من قبل المطورين لإدارة مشاريعهم البرمجية، والتعاون مع فرق العمل، واستضافة مشاريع مفتوحة المصدر.

بالإضافة إلى توفير أدوات لتتبع المشاكل، وإدارة المشاريع، وكمان فيه مميزات تانية زي GitHub Actions والي بتمكن المطورين من تنفيذ عمليات CI/CD.

وفي السنوات الأخيرة، أصبح GitHub جزء لا يتجزأ من عملية تطوير البرمجيات العالمية، مع مجتمع يضم ملايين المطورين والشركات.

Enhance the Reliability and Efficiency of Code Pushes

قامت GitHub بعمل Rollout لأكتر من Technical Upgrade وده بهدف التحسين من الـ Reliability والكفاءة الخاصة بعملية الـ Code Pushes.

والـ Code Pushes هي أكيد واحدة من العمليات الشائعة والمتكررة اللي كلنا بنقوم بيها بشكل دوري. والحركة اللي عملوها دي هدفها معالجة أي مشاكل محتملة وانهم يوفروا تجربة أكثر سلاسة لأي حد بيعمل Code Push على GitHub.

فتعالوا نشوف ايه التحسينات اللي فريق مهندسين GitHub خدها عشان يحسن من كفاءة عملية الـ Code Push.

ايه اللي بيحصل لما بنعمل Code Push ؟

الاجابة المنطقية واللي كتير عارفينها ان الـ Repository بالتأكيد هيبقى فيها الـ Updates بتاعتي اللي انا عملتلها Push , ولكن رغم ان الكلام ده صحيح الان ان فيه مجموعة من العمليات اللي بتحصل كمان واحنا ممكن مانكونش على دراية كاملة بيها.

ودي بعض الأمثلة للعمليات اللي بتحصل لما بنعمل Push لأي Code على GitHub:

• بيحصل مزامنة بين الـ Pull Requests وبعضها , وده معناه ان الـ Diffs والـ Commits اللي موجودين في الـ Pull Request بيتأثروا بالتغييرات اللي بتطرأ من الـ Code Push اللي عملناه
• بيتم عمل Dispatching للـ Push Webhooks
• بيتم عمل Triggering للـ Workflows
• لو عملنا Push لـ App Configuration File , التطبيق هيتم عمل ليه Installing بشكل اوتوماتيك على الـ Repository
• بيتم نشر الـ GitHub Pages
• وغيرهم كتير من العمليات اللي بتحصل واحنا ممكن ما نكونش على دراية كافية بيها.

فلما بتيجي تعمل Code Push بيكون فيها ما يقرب من 60 عملية مختلفة من الـ Logic مرتبطين تقريبًا بحوالي 20 Service مختلفة وكلهم بيحصلهم Run بعد ما تعمل Code Push وده طبعا في الـ Monolith GitHub اللي هم مصممينه.

فزي ما احنا شايفين احنا عندنا Monolith Application وفيه Sequential Operations بتحصل تباعًا مع كل Code Push بيتم.

ايه هي المشاكل ؟

المشكلة ان لحد قبل ما يحصل أي تحسين في الـ System ده , كان الموضوع كله قايم على Background Job ضخمة جدًا , كل لما يحصل Notify للـ Ruby and Rails GitHub Monolith بأن حصل عملية Code Push, كان بيحصل عملية Enqueue لـ Job ضخمة اسمها RepositoryPushJob , والـ Job دي هي اللي كان فيها الـ Logic الضخم اللي اتكلمنا عنه واللي فيه أكتر من 60 Logic.

وبالتأكيد مع وجود كمية كبيرة من الـ Processing Logic اللي شايلاه وحجمها وتعقيدها , كل ده كان بيؤدي إلى مشاكل كتيرة.

وده شكل الـ Sequential Operations اللي بتتم بعد ما يحصل Code Push.

مصدر الصورة

Enormous Job and Retry

حجم الـ RepositoryPushJob الضخم خلى بالتبعية ان بعض العمليات أثناء ما بيحصل Processing Logic لو فيه مشكلة حصلت ان صعب يحصلها Retry مرة تانية بشكل سليم. وبالتالي لو حصل أي مشكلة في النص في أي Processing Logic هنضطر اننا نعيد الموال ده تاني من اول وجديد من أول Processing Logic تاني.

وبالتأكيد مش هيكون ده خيار مناسب لبعض المهام زي :

• كتابة الـ Push Records في الـ Database واللي هينتج عنه بالتأكيد Duplicated Entries
  • ارسال الـ Push Webhooks هي عملية Time Sensitive والمفترض اننا منحاولش نعيد تنفيذها لفترة طويلة بعد ما الـ Code Push يكون حصل
  • مش حاجة كويسة اننا نبعت برضو أكتر من مرة نفس الـ Webhook

Tightly Coupling and Catching Failures

بعض الـ Processing Logic اللي موجود قدر انه ينجو من الـ Failures اللي ممكن تحصل , ولكن احيانا كتير بسبب طبيعة الـ RepositoryPushJob فيه بعض العمليات اللي بتحصل في الأول واللي مش معمولها Handling بشكل كويس من ناحية الـ Failures وخصوصا ان زي ما وضحنا في صعوبة الـ Retries , ده بيؤدي ان في النهاية الـ Job كلها بتفشل تباعًا حتى لو فيه Error Handling في باقي الـ Processing Logic.

فبمجرد ما أول Failure يحصل مش معموله Handling بيحصل Retry للـ Job كلها مع بعض يا اما بتفشل كلها. وده لان كل الـ Steps اللي بتحصل متأخر واللي ممكن تكون مهمة جدًا هي مرتبطة ارتباط وثيق بالـ Initial Steps اللي في البداية وده طبعا بيخلي فيه اعتمادية عالية بينهم.

Bad Latency

زي ما شوفنا بسبب الاعتمادية العالية بين الـ Steps وبعضها لاننا شغالين Sequential , فأصبح دلوقتي لازم على كل الـ Steps اللي موجودة في الآخر انها تستنى كل اللي قبلها يتنفذ عشان تتنفذ , ومع الـ Scale أكيد كل ده كان بيقدم Latency بتوصل احيانا لـ ثانية وأكتر وده طبعا بيقابل المطور وهو بيعمل Push , أو مستني يحصل Pull Request Synchronization.

حلول المشاكل