هندسة

CI/CD للشركات الناشئة: الشحن بشكل أسرع دون كسر الأشياء

| 10 دقيقة قراءة
واجهة GitHub تعرض سير عمل نشر التعليمات البرمجية

تحتاج كل عملية بدء تشغيل إلى 5 عمليات فحص لـ CI/CD: فحص الوبر، وفحص النوع، والاختبارات، والنشر التلقائي إلى التدريج، ونشر الإنتاج بنقرة واحدة. يؤدي هذا إلى اكتشاف 90% من الأخطاء قبل أن يراها المستخدمون. يستغرق الإعداد بعد ظهر أحد الأيام، ويكلف 0 دولارًا شهريًا على المستويات المجانية (GitHub Actions + Vercel)، ويوفر ما بين 900 إلى 1800 دولار شهريًا في حوادث الإنتاج التي تم تجنبها.

الشركات الناشئة التي تشحن أسبوعيًا تتفوق على تلك التي تشحن شهريًا. CI/CD هي الطريقة التي تقوم بها بالشحن أسبوعيًا دون نشر الأخطاء. إنه الفرق بين الفريق الذي يتحرك بسرعة بثقة والفريق الذي يتحرك بسرعة ويكسر الإنتاج كل جمعة.

إذا كنت تدير شركة ناشئة تضم من 2 إلى 10 مهندسين وما زلت تقوم بالنشر عن طريق SSH-ing في خادم أو تنقر على "دمج" ثم تصلي، فإن هذا الدليل يرشدك عبر الحد الأدنى من إعداد CI/CD الذي تحتاجه. تستغرق عملية التهيئة بعد ظهر أحد الأيام، وتتكلف 0 دولارًا أمريكيًا شهريًا للمستويات المجانية، وتدفع تكاليفها في المرة الأولى التي تكتشف فيها خطأ ما قبل أن يفعل المستخدمون لديك ذلك.

ماذا يعني CI/CD باللغة الإنجليزية البسيطة

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

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

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

لماذا تتخطاها الشركات الناشئة (ولماذا يكلفها ذلك لاحقًا)

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

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

بحلول الوقت الذي يكون لديك فيه 10 مهندسين، يكون سبب النشر اليدوي2-3 حوادث الإنتاج شهريا. كل حادث يكلف 2-4 ساعات من الوقت الهندسي للتشخيص والإصلاح. وهذا يعني فقدان 4 إلى 12 ساعة من وقت كبار المهندسين كل شهر؛ الوقت الذي تدفع مقابله من الراتب ولكنك تحصل على قيمة منتج صفرية منه.

الرياضيات واضحة ومباشرة. يتكلف مهندس كبير 75 دولارًا - 150 دولارًا في الساعة. تتكلف اثنتي عشرة ساعة من الاستجابة للحوادث شهريًا ما بين 900 إلى 1800 دولار. يستغرق إعداد CI/CD فترة ما بعد الظهيرة ويكلف 0 دولارًا شهريًا على المستويات المجانية. يمكنك استرداد وقت الإعداد في الشهر الأول.

الحد الأدنى لخط أنابيب CI/CD القابل للحياة

لا تحتاج إلى خط أنابيب مدته 45 دقيقة يضم 200 خطوة. أنت بحاجة إلى خمس عمليات فحص تكتشف 90% من الأخطاء قبل أن تصل إلى مرحلة الإنتاج.

1. الوبر على كل العلاقات العامة

يكشف الفحص عن مشكلات النمط والمتغيرات غير المستخدمة والأخطاء الشائعة. يستغرق ESLint مع التكوين القياسي (مثل الإعداد المسبق لـ Airbnb أو Next.js) من 5 إلى 15 ثانية للتشغيل ويكتشف المشكلات التي قد تظهر في مراجعة التعليمات البرمجية. يؤدي هذا إلى تحرير المراجعين للتركيز على المنطق والهندسة المعمارية بدلاً من تنسيق الوسائط.

2. اكتب الشيك على كل العلاقات العامة

إذا كنت تستخدم TypeScript (ويجب أن تستخدمه)، فقم بتشغيل tsc --noEmit في كل طلب سحب. يؤدي هذا إلى اكتشاف أخطاء الكتابة التي قد يفوتها المحرر الخاص بك؛ خاصة الأخطاء في الملفات التي لم تقم بتغييرها بشكل مباشر ولكنها تعتمد على الكود الذي قمت بتعديله. خطأ في الكتابة تم اكتشافه في CI يكلف دقيقتين لإصلاحه. نفس الخطأ الذي تم اكتشافه في تكاليف الإنتاج ساعتين.

3. إجراء اختبارات على كل العلاقات العامة

تتحقق الاختبارات التلقائية من أن التعليمات البرمجية الخاصة بك تقوم بما يفترض أن تفعله. يتم تشغيل مجموعة اختبار جيدة النطاق خلال 30 إلى 90 ثانية وتكتشف الأخطاء المنطقية التي تخطئ في الفحص والتحقق من الكتابة. لا تحتاج إلى تغطية 100%. أنت بحاجة إلى اختبارات على مسارات التعليمات البرمجية التي تتعامل مع الأموال وبيانات المستخدم وقواعد العمل الأساسية.

4. النشر التلقائي للتدريج عند الدمج إلى الرئيسي

عندما يجتاز PR جميع عمليات التحقق ويتم دمجه، يقوم المسار بإنشاء التطبيق ونشره في بيئة مرحلية. وهذا يمنح فريقك عنوان URL مباشرًا حيث يمكن لمديري المنتجات والمصممين والعملاء مراجعة التغييرات قبل وصولها إلى مرحلة الإنتاج. لا مزيد من "هل يمكنك النشر إلى التدريج حتى أتمكن من اختبار ذلك؟" الرسائل في سلاك.

5. النشر بنقرة واحدة إلى الإنتاج

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

الأدوات والتكاليف

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

إجراءات جيثبمجاني للمستودعات العامة ويتضمن 2000 دقيقة شهريًا لعمليات إعادة الشراء الخاصة. وهذا يكفي لفريق مكون من 5-8 مهندسين يدفعون 20-30 موظفًا رئيسيًا في الأسبوع. يتم تشغيل خطوات الوبر والتحقق من الكتابة والاختبار كمسار عمل يتم تشغيله عند كل طلب سحب.

فيرسليتم النشر تلقائيًا في كل دفعة، ويمنحك معاينة عناوين URL لكل علاقات عامة، ويتعامل مع بيئات التدريج والإنتاج خارج الصندوق. يغطي المستوى المجاني معظم الشركات الناشئة حتى تصل إلى عدد كبير من الزيارات. إذا كنت تقوم بالإنشاء باستخدام Next.js أو Astro أو أي إطار عمل للواجهة الأمامية، فإن Vercel هو أسرع مسار إلى القرص المضغوط.

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

Fly.ioينشر حاويات Docker على خوادم قريبة من مستخدميك. إنه مناسب تمامًا لواجهات برمجة التطبيقات والخدمات التي تحتاج إلى زمن استجابة منخفض عبر المناطق. تتضمن الطبقة المجانية 3 أجهزة افتراضية مشتركة و160 جيجابايت من التحويلات الخارجية.

ما الذي يجب اختباره وما الذي يجب تخطيه

اختبار كل شيء يجعل خط الأنابيب الخاص بك بطيئًا. اختبار أي شيء لا يمنحك أي شبكة أمان. الجواب الصحيح يجلس في الوسط.

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

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

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

تخطي الأجزاء الداخلية للإطار.لا تختبر ما إذا كان React يُعيد التصيير عندما تتغير الحالة. لقد اختبر فريق React ذلك بالفعل. اختبر ما يفعله الكود الخاص بك مع الإخراج المقدم.

سلم الثقة النشر

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

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

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

تعمل عمليات النشر المعاينة على تغيير كيفية مراجعة الفرق للتعليمات البرمجية

يحصل كل علاقات عامة على عنوان URL مباشر. ليست لقطة شاشة في سلسلة رسائل Slack. ليس تسجيل الشاشة. نسخة حية وتفاعلية من تطبيقك مع التغييرات المقترحة التي تعمل على خادم حقيقي.

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

تقوم Vercel وNetlify بذلك خارج الصندوق. تؤدي كل دفعة إلى فرع العلاقات العامة إلى إنشاء عنوان URL فريد للمعاينة يتم تحديثه تلقائيًا عند دفع التزامات جديدة. لا حاجة إلى أي تكوين يتجاوز توصيل GitHub repo الخاص بك.

في Savi، أدت عمليات نشر المعاينة إلى إلغاء المحادثة "بدا الأمر مختلفًا على جهازي". يقوم أصحاب المصلحة بمراجعة الميزات في نفس البيئة التي سيتم فيها تشغيل التعليمات البرمجية في النهاية. إذا كان يعمل على عنوان URL للمعاينة، فإنه يعمل في الإنتاج.

الأخطاء الشائعة التي تبطئ الفريق

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

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

لا توجد بيئة التدريج.النشر مباشرة من العلاقات العامة إلى الإنتاج يعني أن كل عملية دمج هي مقامرة. يمنحك التدريج فرصة أخيرة للتعرف على المشكلات في بيئة تعكس الإنتاج. تبلغ التكلفة 0 دولارًا أمريكيًا للطبقة المجانية من Vercel و5 دولارات أمريكية إلى 20 دولارًا شهريًا للسكك الحديدية.

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

كيف يقوم سافي بإعداد كل مشروع

نقوم بتكوين CI/CD كجزء من كل بناء، وليس كفكرة لاحقة. إليك ما يأتي به كل مشروع Savi في اليوم الأول.

إجراءات GitHub لـ CI.يقوم كل علاقات عامة بتشغيل سير عمل يقوم بتشغيل ESLint والتحقق من نوع TypeScript ومجموعة الاختبار. إذا فشلت أي خطوة، فلا يمكن دمج العلاقات العامة. تفرض قواعد حماية الفروع هذا الأمر بحيث لا يتجاوز أحد مسار التدفق، ولا حتى قائد المشروع.

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

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

فحص النوع الآلي والفحص.نحن ندير TypeScript صارمًا دون أي ضمني وESLint مع قواعد تم ضبطها لاكتشاف الأخطاء الحقيقية، وليس تفضيلات النمط. تضيف عمليات التحقق هذه ما بين 15 إلى 30 ثانية إلى المسار وتلتقط ما بين 60 إلى 70% من المشكلات قبل أن يطلع المراجع البشري على الكود.

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

الأسئلة المتداولة

ما هي تكلفة CI/CD لشركة ناشئة؟

صفر دولار على المستويات المجانية. تمنحك GitHub Actions 2000 دقيقة شهريًا لعمليات إعادة الشراء الخاصة. تتعامل الطبقة المجانية من Vercel مع عمليات نشر الواجهة الأمامية من خلال معاينة عناوين URL. فريق مكون من 5-8 مهندسين يدفعون 20-30 موظفًا رئيسيًا أسبوعيًا يتناسب مع هذه الحدود. يمكنك استرداد وقت الإعداد بعد الظهر في الشهر الأول عن طريق تجنب تكاليف الحوادث التي تتراوح بين 900 و1800 دولار.

ما هو الحد الأدنى لخط أنابيب CI/CD الذي تحتاجه كل شركة ناشئة؟

خمس خطوات: فحص كل PR (من 5 إلى 15 ثانية)، والتحقق من الكتابة في كل PR، وتشغيل اختبارات الوحدة على كل PR، والنشر التلقائي للتدريج عند الدمج إلى الرئيسي، ونشر الإنتاج بنقرة واحدة. يؤدي هذا إلى اكتشاف 90% من الأخطاء قبل الإنتاج. احتفظ بخط الأنابيب الإجمالي أقل من 3 دقائق للوبر والأنواع والاختبارات مجتمعة.

متى تتوقف عمليات النشر اليدوية عن العمل عند بدء التشغيل؟

النشر اليدوي يكسر عند 5 مهندسين. من خلال خمسة مطورين يدفعون التعليمات البرمجية، تحصل على تعارضات دمج وتفاعلات ميزات غير مختبرة وتوقيت نشر عشوائي. بواسطة 10 مهندسين، تتسبب عمليات النشر اليدوية في حدوث 2-3 حوادث إنتاج شهريًا، كل منها يكلف 2-4 ساعات من وقت كبار المهندسين للتشخيص والإصلاح.

ما هي أدوات CI/CD التي يجب أن تستخدمها الشركة الناشئة؟

GitHub Actions for CI (مجاني لعمليات إعادة الشراء العامة، 2000 دقيقة/شهر للقطاع الخاص). Vercel للقرص المضغوط للواجهة الأمامية مع عناوين URL للمعاينة التلقائية على كل العلاقات العامة. السكك الحديدية (5 دولارات شهريًا) أو Fly.io (طبقة مجانية مع 3 أجهزة افتراضية مشتركة) للخدمات الخلفية. تتكلف هذه المجموعة من 0 إلى 5 دولارات شهريًا وتغطي فرقًا مكونة من 2 إلى 10 مهندسين.

ما مدى السرعة التي يجب أن يعمل بها خط أنابيب CI/CD؟

أبقِ خط الأنابيب الخاص بك أقل من 3 دقائق لإجراء اختبارات الوبر والتحقق من النوع والوحدة. إن خط الأنابيب الذي يستغرق 25 دقيقة يقتل سرعة المطورين لأن المهندسين يتجنبون فتح العلاقات العامة. ابدأ بإجراء 10 إلى 20 اختبارًا تغطي منطق العمل الأساسي (المدفوعات والاشتراكات والإجراءات الأساسية). يعمل ESLint خلال 5-15 ثانية؛ يضيف التحقق من نوع TypeScript 15-30 ثانية.

قراءة ذات صلة

هل تريد إعداد CI/CD في مشروعك؟

نقوم بتكوين خطوط الأنابيب كجزء من كل بناء. الاختبارات الآلية، ونشر المعاينة، وإصدارات الإنتاج بنقرة واحدة.

تحدث إلى فريقنا

تواصل معنا

ابدأ محادثة

أخبرنا عن مشروعك. سنردّ خلال 24 ساعة بخطة واضحة، وجدول زمني تقديري، ونطاق التسعير.

البريد الإلكتروني

hello@savibm.com

مقرّنا في

الإمارات والهند