عبد الصمد العماري

الأعضاء
  • المساهمات

    13
  • تاريخ الانضمام

  • تاريخ آخر زيارة

السُّمعة بالموقع

1 Neutral
  1. إنّ التكامل المستمر (Continuous integration) سهل للغاية. نزّل خدمة الأتمتة مفتوحة المصدر Jenkins، وثبّتها، وأنشئ وظيفة، وانقر على الزر، ثم احصل على رسالة بريد إلكتروني جميلة تفيد بأن إنشاءك مكسور أو معطّل (أفترض أن إنشاءك تلقائي). بعد ذلك، أصلح الاختبارات التي لا تعمل (أفترض كذلك أن لديك اختبارات)، واحصل على رسالة بريد إلكتروني أجمل تفيد أن إنشاءك على ما يرام. بعد ذلك، غرّد حول الموضوع مدعيا أن فريقك يستخدم التكامل المستمر. ثم في غضون أسابيع قليلة، ابدأ في فلترة تنبيهات Jenkins إلى مجلدها الخاص لكي لا تستمرّ بإزعاجك. على أي حال، ليس لدى فريقك الوقت أو الرغبة لإصلاح جميع اختبارات الوحدة في كل مرة يعطّلها شخص ما. بعد كل شيء، نعلم جميعًا أن اختبارات الوحدة لا تناسب فريقًا يعمل وفق مواعيد نهائية محدّدة، أليس كذلك؟ هذا خطأ. يمكن للتكامل المستمر أن يعمل في هذه الظروف بل ويجب أن يعمل فيها. ما هو التكامل المستمر؟ في الوقت الحاضر، تُطوّر البرمجيات في فرق نعمل على تطوير فروعٍ للميزات وعزل التعديلات أثناء تطويرها. ثم ندمج الفروع في فرع رئيسي master. وبعد كل عملية دمج، يُختبر المنتج بالكامل، وتُنفّذ جميع اختبارات الوحدة والتكامل المتاحة. وهذا ما يسمى «التكامل المستمر» (continuous integration ويعرف أيضا بالاختصار "CI"). في بعض الأحيان، تفشل بعض الاختبارات. عندما يحدث ذلك، نقول إن "البناءات مكسورة". مثل هذا الفشل هو أحد الآثار الجانبية الإيجابية لمراقبة الجودة لأنه يعطي تنبيهًا بعلامة حمراء فور حدوث خطأ ما. هذه ممارسة معروفة في تطوير البرمجيات، عندما يصبح إصلاح هذا الخطأ أولوية قصوى للمتسبّب فيه وللفريق بأكمله. إذ يتوجّب إصلاح الخطأ مباشرة بعد أن يرسل خادم التكامل المستمر تنبيهًا بالعلامة الحمراء. هناك بعض الأدوات الجيدة المتاحة في السوق، والتي تُؤتمت إجراءات DevOps. بعضها مفتوح المصدر يمكنك تنزيله وتثبيته على الخوادم الخاصة بك. نذكر منها على سبيل المثال: Jenkins و Go و CruiseControl. وبعضها الآخر متاح كخدمات سحابية، مثل: Travis و Shippable و Wercker وغيرها الكثير. لماذا لم يعد التكامل المستمر صالحًا؟ إن التكامل المستمر رائعٌ، ولكن في أغلب الأحيان كلما كان الفريق أكبر (وقاعدة الشيفرة كذلك)، كلما تعطلت الإنشاءات وكلما طالت المدة لإصلاحها. لقد رأيت العديد من الأمثلة يبدأ فيها فريق يعمل بجِدٍّ بتجاهل التنبيهات الحمراء، التي يرسلها Jenkins. بعد بضعة أسابيع، يصبح الفريق ببساطة غير قادر على إصلاح جميع الأخطاء في الوقت المناسب. وهذا، في الغالب، لأن العمل له أولويات أخرى. إذ لا يفهم مالكو المنتجات أهمية "البنية النظيفة" ولا يمكن للمدراء التقنيين شراء الوقت لتثبيت اختبارات الوحدة. كما أن الشيفرة المكسورة تكون أصلا في الفرع الرئيسي master، و في معظم الحالات، تكون قد نُشرت بالفعل على الإنتاج وسُلّمت للمستخدمين النهائيين. فما الحاجة إذن لإصلاح الاختبارات إذا كان العمل قد سُلّم فعليًا؟ لا تأخذ معظم فرق التطوير تنبيهات التكامل المستمر على محمل الجد. لا تمثّل Jenkins أو Travis بالنسبة لهم سوى مجرد أدوات لطيفة لا تلعب أي دور في عملية التطوير والتسليم بأكملها. بغض النظر عن ما يقوله خادم التكامل المستمر، مازلنا نقدم ميزات جديدة للمستخدمين النهائيين. ونترك إصلاح إنشائنا إلى وقت لاحق. وهذا منطقي بالنسبة لي. ما هو الحل؟ منذ بضع سنوات، نشرت مقالًا بعنوان "منع التعارضات في مشاريع PHP الموزّعة والمرنة". اقترحت في المقالة حلولًا لهذه الإشكالات في Subversion و PHP. منذ ذلك الوقت، استخدمت هذا النهج تجريبيًا في عدد من المشاريع مفتوحة المصدر وبعض المشاريع التجارية أيضا في PHP وجافا وروبي وجافاسكريبت و Git و Subversion. في جميع الحالات، كانت تجربتي إيجابية، ولهذا السبب رأى rultor.com النور لاحقًا. لذلك، فإن الحل بسيط للغاية: احظُر على أي شخص دمج أي شيء في الفرع الرئيسي master وأنشئ سكريبتًا يمكن لأي شخص استدعاؤه. سيقوم السكريبت بعمليات الدمج والاختبار والتنفيذ. لن تكون لدى السكريبت أي استثناءات. فإذا انكسر أي فرع في اختبار واحد، سيرفض الفرع بأكمله. بمعنى آخر، يجب أن تظهر تلك العلامة الحمراء للتنبيه قبل أن تنتقل الشيفرة إلى الفرع الرئيسي master. ويجب أن يتحمّل مسؤولية الاختبارات المكسورة من تسبّب فيها. لنفترض أنّني أقوم بتطوير ميزة في فرعي الخاص. انتهيت من التطوير وكسرت بعض الاختبارات عن طريق الخطأ. يحدث ذلك، فنحن جميعا نرتكب أخطاء. ولكن لا يمكنني دمج تعديلاتي في Master. سيرفض Git ببساطة تنفيذ الأمر push لأنني لا أملك الأذونات المناسبة. كل ما يمكنني فعله هو أن أستدعي السكريبت السحري، وأطلب منه دمج فرعي الخاص. سيحاول السكريبت الدمج، ولكن قبل الدخول إلى الرئيسية، ستشغّل جميع الاختبارات. وإذا كُسِر أي منها، سيكون الرفض نتيجة حتمية. لن تُدمج التعديلات التي أجريتها وأصبح لزامًا عليّ إصلاحها قبل استدعاء السكريبت مرة أخرى. قد يؤدي هذا النهج في البداية إلى إبطاء عملية التطوير، لأن على الجميع بدء كتابة تعليمات برمجية أنظف. ولكن في النهاية، فإن هذه الطريقة تؤتي ثمارها. إنشاءات ما قبل الإقلاع تقدم بعض خوادم التكامل المستمرّ CI ميزة "إنشاءات ما قبل الإقلاع"، وهذا يعني اختبار الفروع قبل دمجها في master رئيسي. لدى Travis، على سبيل المثال، هذه الميزة المفيدة للغاية. عندما تقوم بإيداع جديد في فرع ما، يحاول Travis إنشاءه على الفور، ويُبلغ عبر طلبات الإضافة في GitHub عن أي مشاكل قد تحدث. انتبه، فإنشاءات ما قبل الإقلاع لا تندمج. دورها فقط هو التحقّق مما إذا كان فرعك الخاصّ نظيفًا. بعد الدمج، يمكن بسهولة كسر الفرع الرئيسي master. لذا، فهذه الآلية لا تضمن أنه لا أحد يستطيع الإيداع بشكل مباشر، والتسبب بكسر عن طريق الخطأ. تبقى عمليات الإنشاء قبل الإقلاع تدبيرًا وقائيًا، لكنها لا تحل المشكلة تمامًا. موقع Rultor.com من أجل البدء في العمل وفق ما هو موضح أعلاه، كل ما عليك فعله هو إلغاء أذونات الكتابة في الفرع الرئيسي master (أو ‎/trunk، في Subversion). لسوء الحظ، هذا غير ممكن في GitHub. الحل الوحيد هو العمل من خلال الفروع وطلبات السحب فقط. ما عليك سوى إزالة الجميع من قائمة المتعاونين (collaborators) وسيكون عليهم إرسال تعديلاتهم من خلال طلبات السحب. بعد ذلك، ابدأ في استخدام موقع rultor.com الذي سيساعدك على اختبار كل طلب للإضافة ودمجه ودفعه. في الأساس، Rultor هو السيناريو الذي كنا نتحدث عنه أعلاه، وهو متاح كخدمة سحابية مجانية. ترجمة -وبتصرف- للمقال Master Branch Must Be Read-Only لصاحبه Yegor Bugayenko
  2. روتينات رائعة ومفيدة بالتأكيد رغم أنها تحتاج إلى قدر كبير من الالتزام. ولكن ساعة البافلوك ب 150 دولار من أجل الاستيقاظ...😥
  3. تعرف على devopssec

    بارك الله فيك شكرا لك.
  4. إنّ ما ترغب فيه عندما تحتاج إلى إنشاء منتج برمجي ولكن خبرتك في هندسة البرمجيات محدودة هو التعهيد الخارجي للبرمجيات. إنها ممارسة تجارية ذكية يستخدمها الجميع بدءًا من أصحاب الألف دولار الذين يملكون مواقع الويب الشخصية وانتهاء بأصحاب الثروات الكبيرة؛ وكلهم يفشلون إلى حد ما. في الواقع، من الصعب جدًا أن لا تفشل. لذا أعددت فيما يلي قائمة من التلميحات البسيطة لكل من يقرّر التعهيد الخارجي لتطوير البرمجيات (يوجد أهمها في الأسفل). ولكم تمنيت لو أن شخصًا ما قد أعطاها لي منذ 15 عامًا. لتكن لديك اتفاقية "العمل مقابل أجر" تأكد من أن العقد الذي أبرمته مع الفريق المُتعهِّد لإنشاء البرامج يشتمل على شيء من هذا القبيل: "يجب على الأطراف اعتبار جميع التسليمات التي أنشأها المطور بمثابة أعمال أُنجِزت للتأجير كما هو محدد بموجب قوانين حقوق الطبع والنشر". هذا هو التعريف المختصر والسهل لعبارة "كل ما تنجزه لي هو ملكي". ضع هذا في العقد ولن تستطيع شركة التعهيد الخارجي ادعاء أن البرنامج الذي أنشأته مِلكها، وهو ما يحدث هنا وهناك. احرص على امتلاك مستودعٍ خاصٍّ بك للشيفرة المصدرية تأكد من أن مستودع الشيفرة المصدرية تحت سيطرتك. وأفضل طريقة للقيام بذلك هي إنشاء مستودع GitHub خاصٍّ. سيكون المخزون مرئيًا ولا يمكن الوصول إليه إلّا من خلالك أنت وفريق التعهيد الخارجي. علاوة على ذلك، تأكد من أن الفريق لديه صلاحية القراءة فقط ولا يمكنه تغيير الشيفرة مباشرة إلا من خلال طلبات السحب (pull requests)، لأن Git يتيح إمكانية تدمير السجل بأكمله بضغطة واحدة "قسرية" على الفرع الرئيسي (master branch). لذلك سيكون من الأفضل لك أن تكون الشخص الوحيد الذي لديه صلاحية الكتابة. لجعل الأمور أكثر بساطة، أنصحك باستخدام Rultor كأداة لدمج طلبات السحب هذه بشكل شبه تلقائي. اجمع الإحصائيات بانتظام اطلب من أعضاء فريق التعهيد الخارجي جمع الاحصائيات بانتظام من البرنامج الذي يقومون بإنشائه وإرسالها إليك بطريقة أو بأخرى (عبر البريد الإلكتروني ربما). أنصح باستخدام Hits-of-Code ومدى تغطية اختبارات الوحدة (أو فقط إجمالي عدد اختبارات الوحدة) والتذاكر المفتوحة والمغلقة ومدة الإنشاء. أنا أتحدث هنا عن مقاييس عملية. وهو ما لن تحصل عليه فعليًا باستخدام أدوات أخرى مثل NewRelic. ستحدّد هذه المقاييس أداء الفريق، وليس المنتج قيد التطوير. لا أقول أنه يجب عليك إدارة الفريق من خلال المقاييس، ولكن عليك أن تراقب هذه الأرقام وديناميكيتها. إجراء مراجعات فنية مستقلة تتجلى أهمية هذه المراجعات في صعوبة تضخيمها أو التحايل فيها. إنها حاسمة بشكل استثنائي عندما يتعلق الأمر بالتعهيد الخارجي للبرمجيات. في الواقع، هذه هي الطريقة الأفضل لجمع المعلومات الموضوعية عن البرنامج الذي تحصل عليه من جهة خارجية. لا تعتمد على التقارير والوعود والضمانات والتوثيقات الشاملة. بدلاً من ذلك، استأجر شخصًا آخر بنظام الساعة واطلب منه مراجعة ما يطوّره شريك الخارجي. قم بهذ المراجعات بانتظام وبشكل منهجي. لا تخف من الإساءة إلى المبرمجين، واشرح لهم بصراحة أهمية المراجعة بالنسبة لك. إذا كانوا مهنيين، فسوف يفهمون ويحترمون أهداف عملك. يمكنك أيضا أن تريهم هذه المقالة :-). أتمتة النشر والتحكم فيه اطلب من الفريق المُتعهِّد أتمتة آلية النشر بالكامل وإبقاءها تحت سيطرتك. وأنصح بأن تفعل هذا خلال الأيام الأولى للمشروع. هذا يعني أنه ينبغي تجميع المنتج واختباره وتعبئته وتثبيته ونشره في مستودع الإنتاج (أو على الخادم/الخوادم) بنقرة واحدة. ستحتاج بالطبع إلى إنشاء سكريبت لأتمتة سلسلة العمليات هذه ويجب على شريكك الخارجي أن يكتبه لك. ثم، عند بدء عملية التطوير، يُنفّذ السكريبت تلقائيًا في كل مرة يجري فيها تعديل جديد على المستودع الذي ينشر الإنتاج. المهم هنا هو أن تعرف كيفية عمل هذا السكريبت وكيفية تشغيله حتى تكون قادرًا على بناء منتجك ونشره بنفسك. اطلب إصدارات أسبوعية لبرنامجك لا تنتظر الإصدار النهائي؛ بل اطلب من الفريق المُتعهِّد إصدار نسخة جديدة كل أسبوع. بغض النظر عن مدى كثافة التطوير وعدد الميزات الجاري تنفيذها، من الممكن دائمًا تجميع نسخة جديدة وإصدارها. إذا كان التطوير مكثفًا فعلاً، فاطلب من فريقك استخدام GitFlow أو شيء مشابه لعزل فرع الإنتاج المستقر عن باقي الفروع. لكن احذر من طول الانتظار! احرص على رؤية برنامجك مجمّعًا ومنشورًا كل أسبوع، بدون استثناءات ولا أعذار. إذا لم يتمكن الفريق المُتعهِّد من تقديم ذلك لك، فهذا يدعوك للقلق وإلى تغيير شيء ما. وظِّف مديرًا تقنيًا تنفيذيًا (CTO) مستقلًا تُقدّم هذه النصيحة في الغالب للشركات الصغيرة أو الأفراد الذين يستعينون بفريق خارجي لتطوير البرمجيات ويعتمدون على خبراتهم مع الاستمرار في التركيز على تطوير أعمالهم. هذا ليس من الحكمة في شيء؛ يجب أن يكون لديك مدير تقني تنفيذي مستقل (CTO) يقوم بإبلاغك ويتحكم في كيفية عمل الفريق المُتعهِّد. ينبغي التعاقد مع هذا الشخص وفقًا لجدول دفع مختلف مع أهداف وشروط وأهداف مختلفة. في كثير من الأحيان، يحاول أصحاب الأعمال التذاكي في البرمجيات والتحكم في فريق البرنامج مباشرةً، ويتعلمون أساسيات لغة المصطلحات البرمجية ومبادئ DevOps، لكن هذا يقود حتمًا إلى الفشل. كن ذكيا، فأنت تقوم بتطوير الأعمال، سيكون تعاملك المباشر مع مدير التقنية CTO ويتولى هو توجيه الفريق المُتعهِّد ومراقبته؛ بحيث يرسل CTO لك التقارير عن سير العمل، ويرسل له أعضاء الفريق التقارير التقنية بدورهم. حدّد آليةً للمكافآت والعقوبات لا توجد إدارة بدون هذين المكونين الرئيسيين. ليس من المفترض أن تدير جميع المبرمجين في الفريق المُتعهِّد، بل عليك إدارة الفريق بأكمله كوحدة تحكم واحدة. عليك أن تمنحهم نوعًا من التحفيز. ينبغي أن يعرفوا ماذا سينالون إذا نجحوا وكم سيعانون إذا فشلوا. إذا لم توضح هذه الآلية، فستُضطر للتعامل معها ضمنيًا، إذ أن فرص الرّبح تكون منخفضة جدًا. يفترض معظم الناس أن أفضل حافز والحافز الوحيد لفريق البرمجيات هو استمراره في العمل على المشروع. أنت تدفع لهم وهذا يكفي، أليس كذلك؟ هذا خطأ. لا يمكن أن تكون الإدارة فعالة عندما يكون التحويل المصرفي الشهري بمثابة مكافأة وغيابها يعد عقابًا. إنه أسلوب فجّ، وهذا ما يجعله عديم الفعالية إطلاقًا. ابحث عن آلية أفضل وأكثر لباقة وبالتالي أكثر فعالية. لا تقض أكثر من شهر في المشروع يقول بعض الناس 12 أسبوعًا، وأنا أقول شهرًا، ولست وحدي من يقول ذلك. هل تعلم أن الإصدار الأول من Minecraft (الذي بِيعَ لاحقًا إلى Microsoft مقابل 2.5 مليار دولار) تم إصداره في غضون ستة أيام فقط؟ هناك العديد من الأمثلة الأخرى، بما في ذلك Uber و Dropbox و Buffer وغيرها. لقد عبّر إريك ريس في كتابه Lean Startup عن هذا المفهوم بعبارة "منتج الحد الأدنى القابل للتطبيق" (Minimum Viable Product وتختصر إلى MVP)، وأنا متأكد من أنك سمعت هذا الاختصار من قبل. إذا كان المطورون يعدون بتسليم المنتج في غضون بضعة أشهر، فهناك شيء ليس على ما يرام. ينبغي حتمًا أن تحصل على بعض البرامج العاملة في أقل من شهر وينبغي أن تكون جاهزًا للمستخدمين الذين يدفعون رسومًا حقيقية. لقد أنشأت معظم مشاريعي اللطيفة في أقل من أسبوع لكل منها. لا تدفع الرواتب سيريدون منك بطبيعة الحال أن تدفع شهريًا، بالإضافة إلى التأمين الصحي، وأجهزة الحاسوب، والإجازات، ومكتب مشمس لطيف. وهذا هو ما يمكن أن تضيع فيه مخططاتك، إذ أنك تجعلهم سعداء بينما تخسر أنت. عليك إيجاد طريقة لملاءمة أهدافك (تسليم MVP في أقرب وقت ممكن والبدء في جني الأموال) مع أهدافهم (شراء سيارة جديدة وقضاء الإجازة التالية على الشاطئ). هل تستطيع فعل ذلك؟ إنه أمر صعب. لهذا السبب أنشأنا Zerocracy، مما يجعل الفواتير التدريجية والدفع بالنتائج أمرًا ممكنًا. يمكنك إما نقل مشروعك إلى هذه المنصة وإدارة مطوريك هناك، أو ابتكار شيء ما بمفردك. ولكن تذكر، ليست هناك رواتب شهرية! تدفع فقط مقابل النتائج المقدمة. لا تدعهم يجربون يريد كل مبرمج ذكي استخدام مشروعك الجديد كإجراء اختبار لبعض التقنيات الجديدة. لا يحب الناس أن يكرّروا نفس الشيء الذي كانوا يفعلونه بالأمس، إلا إذا كانوا أغبياء ومملين. ولهذا، سيَنصح أعضاء فريقك غالبا باستخدام شيء جديد، قد يكون إطار عمل جديدًا أو قاعدة بيانات جديدة أو حلّ استضافة سحابية جديدًا أو أدوات نشر جديدة. إنهم يفعلون ذلك لأغراضهم الخاصة، وليس لمساعدة المشروع. لا تسقط في هذا الفخ وكن مصرًّا على استخدام ما لديهم من خبرة، على الأقل في مرحلة MVP. يمكنك أن تعدهم بحرية التجربة، ولكن في وقت لاحق عندما يتم إطلاق النسخة MVP. ترجمة -وبتصرف- للمقال Software Outsourcing Survival Guide لصاحبه Yegor Bugayenko
  5. يعدُّ Yeoman (وتلفظ «يومِن» ومعناها في اللغة الأجنبية الخادم الجليل الذي يخدم النبلاء أو الشخص الذي يقدم خدمات جليلة ذات شأن) نظامًا عامًّا للسقالات يسمح بإنشاء أي نوع من التطبيقات، فهو يتيح البدء السريع في مشاريع جديدة ويبسّط صيانة المشاريع القائمة. السقالة باللغة العربية هي هيكل مؤقت يُستخدَم في حمل الأشخاص والمواد بغرض البناء؛ أمَّا في البرمجة، فينطبق التعريف تمامًا عليها أي هي منصةٌ مؤقتةٌ تُستعمَل في بناء هياكل التطبيقات للانطلاق بعملية الإنشاء بسرعة وذلك بتوليد الملفات البدائية الأساسية للمشروع أو التطبيق (الهيكل العام) الذي تود إنشاءه وفق مواصفات ومعايير تحدِّدها مما يوفر عليك الكثير من الوقت. ويمكن القول أنَّ Yeoman محايدٌ مع لغات البرمجة أي يسمح بإنشاء مشاريع بأي لغة تريد (لغات الويب أو لغة جافا أو بايثون أو سي شارب أو غيرها). لا يتخذ Yeoman في حد ذاته أي قرارات. تُتخَذ كل القرارات من قبل المولّدات التي هي في الأساس ملحقات في بيئة Yeoman. هناك الكثير من المولدات المتاحة كما أنّه من السهل إنشاء مولّد جديد يناسب أي سير عمل تريد. Yeoman هو دائمًا خيارك الصحيح لاحتياجات بناء التطبيقات وتوليد ملفات المشروع الابتدائية. فيما يلي بعض حالات الاستخدام الشائعة له: إنشاء مشروع جديد بسرعة إنشاء أقسام جديدة من المشروع، مثل وحدة تحكم جديدة مع اختبارات الوحدة إنشاء وحدات (modules) أو حزم (packages) التمهيد لخدمات جديدة فرض المعايير والممارسات الجيّدة والدلائل النمطية الترويج لمشاريع جديدة من خلال السماح للمستخدمين بالبدء مع تطبيق أو مشروع نموذجي وغيرها من حالات الاستخدام جدول المحتويات حرصًا على تنظيم المقالة ولتسهيل الوصول إلى القسم الذي تريده بسهولة، سنذكر هنا جدول المحتويات باختصار: الجزء الأول: البدء مع Yeoman تثبيت yo وبعض المولدات تنصيب السقالة واستخدامها عمليًا أوامر yo الأخرى استكشاف الأخطاء وإصلاحها الجزء الثاني: تنصيب سقالة Yeoman لبناء تطبيق ويب بناء تطبيق نموذجي باستخدام Yeoman ماذا لدينا في هذه الورشة؟ الخطوة 1: إعداد بيئة التطوير الخاصة بك الخطوة 2: تثبيت مولّد Yeoman الخطوة 3: استخدام مولّد لتنصيب سقالة حول التطبيق وبناء هيكله الخطوة 4: مراجعة بنية التطبيق الذي أنشأته بواسطة Yeoman الخطوة 5: معاينة تطبيقك في المتصفح الخطوة 6: اختبار التطبيق بواسطة Karma و Jasmine الخطوة 7: الاستفادة من التخزين المحلي لحفظ المهام (todos) الخطوة 8: الاستعداد لمرحلة الإنتاج ختام الورشة، تهانينا! المصادر الجزء الأول: البدء مع Yeoman يُعدُّ yo أداة سطر الأوامر في Yeoman التي تسمح بإنشاء مشاريع باستخدام قوالب السقالات (scaffolding templates، يشار إليها باسم «المولدات» [generators]). يُثبَّت yo والمولدات المستخدمة باستعمال مدير حزم نود (npm). تثبيت yo وبعض المولدات تأكد بدايةً من تثبيت Node.js ومدير حزمه npm على حاسوبك. نفِّذ الأمر التالي للتأكد من وجود Node.js و npm لديك: $ nodejs -v v8.10.0 $ npm -v 3.5.2 ننصحك بالرجوع إلى مقال تثبيت Node.js على نظام أبونتو لمزيد من المعلومات حول عملية التثبيت على نظام لينكس. أمَّا على نظام ويندوز، نقترح استخدام أداة سطر أوامر أفضل مثل cmder أو PowerShell لتجربة أفضل. يمكنك دومًا الرجوع إلى موقع Node.js الرسمي واختيار نوع نظام التشغيل لتثبيت Node.js و npm عليه. ثبِّت بعد ذلك yo باستخدام npm عبر الأمر التالي: npm install -g yo بعد ذلك، تُثبَّت المولد(ات) اللازم(ة)، والتي تكون عبارة عن حزم npm تسمى بالشكل generator-XYZ، إذ XYZ هو اسم المولِّد. ابحث عنها على في هذه الصفحة أو عن طريق تحديد خيار قائمة "تثبيت مولد" (install a generator) أثناء في سطر الأوامر yo. إن أردت تثبيت المولد webapp مثلًا، نفِّذ الأمر التالي: npm install -g generator-webapp قد يواجه مستخدمو Node و npm الجدد مشكلات متعلقة بالأذونات. تظهر هذه المشكلات في شكل أخطاء EACCESS أثناء التثبيت. ارجع إلى دليل npm لإصلاح الأذونات إذا حدث لك هذا. تنصيب السقالة واستخدامها عمليًا سنستخدم المولِّد generator-webapp الذي ثبَّتناه للتو في أمثلتنا أدناه. استبدل بالاسم webapp (الذي هو XYZ) اسم المولد الخاص بك للحصول على نفس النتيجة. من أجل تنصيب السقالة في مشروعك الجديد، نفِّذ الأمر التالي: yo webapp ستطرح أغلب المولّدات مجموعة من الأسئلة من أجل تخصيص المشروع الجديد؛ هل تذكر المواصفات والمعايير التي أخبرتك آنفًا بها لتخصيص بها مشروعك؟ ها هي عمليًا. لمعرفة الخيارات المتاحة، استخدم أمر المساعدة : yo webapp --help تعتمد الكثير من المولدات على أنظمة البناء (تعرف بأنها «أدوات بناء» أيضًا) مثل Gulp أو Grunt، ومديري الحزم مثل npm و Bower. تأكد من زيارة موقع المولّد لتتعلّم كيفية تشغيل التطبيق الجديد وصيانته. يمكنك الوصول بسهولة إلى الصفحة الرئيسية للمولّد بتنفيذ الأمر التالي: npm home generator-webapp من المرجّح أن توفر إطارات العمل المعقدة للسقالات مولدات إضافية لبناء الأجزاء الصغيرة من المشروع. يشار إلى هذه المولدات عادةً بالمولدات الفرعية (sub-generators)، ويمكن الوصول إليها كما يلي: generator:sub-generator. لنأخذ المولِّد generator-angular مثالًا. يمكن بمجرد إنشاء تطبيق angular بالكامل إضافة ميزات أخرى. لإضافة وحدة تحكم جديدة إلى المشروع، شغِّل المولد الفرعي لوحدة التحكم: yo angular:controller MyNewController أي أن عمل السقالة لا تقتصر على بناء التطبيق توليد ملفاته الأولية، بل إضافة مزايا وعناصر إليه. أوامر yo الأخرى بخلاف الأساسيات التي غطّيناها في القسم السابق، يعد yo أيضًا أداة تفاعلية بالكامل. ستوفر كتابة yo ببساطة في الطّرفية قائمة من الخيارات لإدارة كل ما يتعلق بالمولدات: التشغيل والتحديث والتثبيت والمساعدة وغيرها من الأدوات. تُوفّرyo أيضا الأوامر التالية: yo --help: تمكنك من الوصول إلى شاشة المساعدة الكاملة yo --generators: تعطي قائمة بكل المولدات المثبتة yo --version: للحصول على الإصدار استكشاف الأخطاء وإصلاحها يمكن إيجاد معظم المشكلات بتنفيذ الأمر: yo doctor سيشخِّص الأمر doctor خطوات لحلّ المشكلات الأكثر شيوعًا. الجزء الثاني: تنصيب سقالة Yeoman لبناء تطبيق ويب أصبحت الآن جاهزًا لبناء تطبيق ويب كامل الوظائف من البداية بالاستعانة بمنصة Yeoman و FountainJS. سيُكتَب نموذج التطبيق في React أو Angular1 أو Angular2. ليس لديك أي فكرة عن React أو Angular؟ لا بأس، سوف نرشدك. ومع ذلك، فإننا نفترض أن لديك تجربة سابقة مع لغة جافاسكريبت. بناء تطبيق نموذجي باستخدام Yeoman سيكون نموذج تطبيق الويب الذي ستنشئه تنفيذًا لمشروع إطار عمل يسمى TodoMVC. ستتمكن من إضافة عناصر مهام لإنجازها (todos) أوحذفها، أو ترشيحها، وسنضيف معًا ميزة لحفظها في وضع عدم الاتصال. ماذا لدينا في هذه الورشة؟ سنبني تطبيق TodoMVC أعلاه من الصفر. كل خطوة سوف تُبنَى على التي تسبقها، لذلك سننتقل من خلال كل خطوة تلو الأخرى: الخطوة 1: إعداد بيئة التطوير الخاصة بك الخطوة 2: تثبيت مولّد Yeoman الخطوة 3: استخدام مولّد لتنصيب سقالة حول التطبيق وبناء هيكله الخطوة 4: مراجعة بنية التطبيق الذي أنشأته بواسطة Yeoman الخطوة 5: معاينة تطبيقك في المتصفح الخطوة 6: اختبار التطبيق بواسطة Karma و Jasmine الخطوة 7: الاستفادة من التخزين المحلي لحفظ المهام (todos) الخطوة 8: الاستعداد لمرحلة الإنتاج سوف تستغرق هذه الخطوات حوالي 25 دقيقة لإتمامها. في الختام، سيكون لديك تطبيق TodoMVC أنيق وسوف يكون جهاز حاسوبك معدًّا لإنشاء المزيد من تطبيقات الويب الرائعة في المستقبل. جاهز؟ لنبدأ مع الخطوة الأولى! الخطوة 1: إعداد بيئة التطوير الخاصة بك ستكون معظم تفاعلاتك مع Yeoman عبر سطر الأوامر. نفّذ الأوامر في الطّرفية إذا كنت تستخدم نظام التشغيل Mac أو في الصدفة shell في نظام لينكس أو في واجهة cmder (وهي المفضلة) أو PowerShell أو cmd.exe إذا كنت تستخدم نظام التشغيل ويندوز. تثبيت المتطلبات الأساسية قبل تثبيت Fountain Webapp Generator، ستحتاج إلى ما يلي: الإصدار السادس من Node.js أو ما بعده. الإصدار الثالث من npm أو ما بعده (والذي يأتي مرفقًا مع Node) نظام التحكم بالإصدارات Git يمكنك أن تتحقق مما إذا كان لديك Node و npm مثبتين بكتابة ما يلي: node --version && npm --version إذا كنت بحاجة إلى ترقية Node أو تثبيته، فإن أسهل طريقة هي استخدام المثبت في نظامك الأساسي. نزِّل حزمة "msi." بالنسبة لنظام ويندوز أو "pkg." لنظام التشغيل Mac من موقع NodeJS ثم ثبِّتها. وإذا كنت تستخدم نظام لينكس، يمكنك تنزيل أحدث إصدار من صفحة التنزيل في الموقع الرسمي. يكون مدير الحزم npm مدمجًا مع Node، رغم أنّك قد تحتاج إلى تحديثه. وتأتي بعض إصدارات Node مع الإصدارات القديمة بدلاً من npm. يمكنك تحديث npm باستخدام هذا الأمر: npm install --global npm@latest يمكنك التحقق من تثبيت Git من خلال كتابة ما يلي: git --version إذا لم يكن لديك Git، حمّل أداة التثبيت من الموقع الرسمي. إن كان نظام التشغيل لديك هو أحد توزيعات ديبيان من لينكس، فنفِّذ الأمر التالي لتثبيت Git: sudo apt install git تثبيت أدوات Yeoman بمجرد تثبيت Node، ثَبِّت أيضًا مجموعة أدوات Yeoman عبر تنفيذ الأمر التالي: npm install --global yo هل هناك أخطاء؟ إذا واجهت أي أخطاء في الأذونات أو الوصول، مثل خطأ EPERM أو EACCESS، فلا تستخدم sudo كحلّ بديل. تستطيع الاستفادة من هذا الدليل. ويمكنك أيضًا الإطلاع على هذا المقال لمعلومات أوسع حول عملية التثبيت. التحقق من نجاح عملية التثبيت من المستحسن التحقق من تثبيت كل شيء كما هو متوقع عبر تنفيذ أوامر Yeoman شائعة الاستخدام مثل yo مع الراية version-- كالتالي: yo --version إصدارات أدوات CLI التي تعمل معها هذه الورشة البرمجية تتغير التكنولوجيا بسرعة! لقد نُفِّذت هذه الورشة التعليمية باستخدام الإصدار 1.8.4 من سطر الأوامر yo. إذا كنت تواجه مشكلات في إصدار أحدث، فسيسعدنا أن نعرف عنها. يمكنك فتح تذكرة في GitHub للإبلاغ بأي مشكلة. الخطوة 1: تثبيت مولد Yeoman ستحتاج في سير عمل تطوير الويب التقليدي إلى قضاء الكثير من الوقت في إعداد الشيفرة المتداولة (boilerplate code) الخاص بتطبيق الويب الذي تعمل عليه، وتنزيل التبعيات، وإنشاء بنية مجلد الويب الخاصة بك يدويًا. ولكن مولّدات Yeoman ستسهّل عليك المهمّة كثيرًا! لنثبِّت مولّدًا لمشاريع FountainJS. تثبيت المولّد يمكنك تثبيت مولدات Yeoman باستخدام الأمر npm وهناك أكثر من 3500 مولد متاح الآن، وكثير منها كتبه أفراد مجتمع المصادر المفتوحة. ثبِّت المُولِّد generator-fountain-webapp باستخدام هذا الأمر: npm install --global generator-fountain-webapp سيبدأ هذا بتثبيت حزم Node المطلوبة للمولد. تذكير: إذا واجهت أي أخطاء في الأذونات أو الوصول، مثل خطأ EPERM أو EACCESS، فلا تستخدم sudo كحلّ بديل. تستطيع الاستفادة من هذا الدليل. في الوقت الذي تستخدم فيه npm install مباشرة، يمكنك البحث عن المولدات عبر قائمة Yeoman التفاعلية. نفِّذ الأمر yo وحدِّد Install a generator للبحث عن المولدات المنشورة. الخطوة 3: استخدام مولّد لتنصيب سقالة حول التطبيق وبناء هيكله لقد استخدمنا كلمة «سقالة» مرات عديدة وشرحنا معناها في بداية هذا الدليل لكن قد ما تزال غريبة بعض الشيء. تعني السقالة، بالمفهوم المستخدم في Yeoman للكلمة (وفي عالم البرمجة عمومًا)، إنشاء ملفات لتطبيق الويب الخاص بك وفق معايير ومواصفات تضبطها أنت. سترى في هذه الخطوة كيف يمكن لـ Yeoman إنشاء ملفات خاصة بمكتبتك أو إطارك المفضل، مع خيارات لاستخدام مكتبات خارجية أخرى مثل Webpack و Babel و SASS وربطها بمشروعك، بأقل جهد ممكن. إنشاء مجلد المشروع أنشئ مجلدًا باسم mytodo ليحوي جميع ملفات المشروع الذي سنعمل على بنائه: mkdir mytodo && cd mytodo هذا المجلد هو المكان الذي سيولِّد المولد فيه ملفات مشروعك الابتدائية (أي هيكل المشروع). الوصول للمولدات عبر قائمة Yeoman نفِّذ الأمر yo لرؤية المولدات الخاصة بك: yo إذا كان لديك عدد قليل من المولدات المثبتة، فستتمكن من الاختيار بشكل تفاعلي منها. اختر المُولِّد Fountain Webapp لتشغيله. استخدام المولدات مباشرة عندما تستأنس أكثر بسطر الأوامر yo، ستفضّل تشغيل المولِّد مباشرةً دون استخدام القائمة التفاعلية (وضغط المزيد من الأزرار) على النحو التالي: yo fountain-webapp إعداد المولد الخاص بك توفر بعض المولدات إعدادات اختيارية لتخصيص تطبيقك مع مكتبات مطوّري البرامج المشتركة لتسريع الإعداد الأولي لبيئة التطوير الخاصة بك. يوفر المولد FountainJS بعض الخيارات لكي تستخدم ما تفضله: إطار العمل (React أو Angular2 أو Angular1) وحدة الإدارة (Webpack أو [SystemJS] أو لا شيء إذا كنت تستعمل Bower) معالج أولي لشيفرة جافاسكربت (Babel أو TypeScript أو لا شيء) معالج أولي لشيفرة CSS ‏(SASS أو LESS أو لا شيء) ثلاثة نماذج للتطبيق (صفحة هبوط وصفحة "مرحبا بالعالم" [hello world] ونموذج TodoMVC) سوف نستخدم لهذه الورشة الخيارات التالية: React Webpack Babel SASS نموذج Redux TodoMVC حدّد هذه الخيارات على التوالي باستخدام مفاتيح الأسهم ثم زر "إدخال" واستمتع بما يحدث على الشاشة. سيبني Yeoman تلقائيًا هيكل تطبيقك ويولد لك جميع الملفات الابتدائية الأساسية له، وسيجلب كل الاعتماديات (dependencies) الخاصة به. بعد بضع دقائق، سنكون مستعدين للانتقال إلى الخطوة التالية. الخطوة 4: مراجعة التطبيق الذي بناه Yeoman افتح المجلّد mytodo الخاص بك لإلقاء نظرة على ما جرى بناؤه إلى الآن. يجب أن يبدو مثلما توضحه الصورة التالية: لدينا في مجلد المشروع المجلدات الفرعية التالية: src: مجلّد رئيسي لتطبيق الويب app: شيفرة React و Redux index.html: ملف html الرئيسي index.js: نقطة الدخول لتطبيق TodoMVC conf : مجلّد رئيسي لملفات الضبط الخاصة بالأدوات الخارجية (Browsersync و Webpack و Gulp و Karma) gulp_tasks و gulpfile.js: مهام أداة البناء Gulp babelrc. و package.json و node_modules: الضبط والاعتماديات المطلوبة gitattributes. و gitignore.: ملفات ضبط Git أنشِئ الإيداع (commit) الأول في المستودع الآن وبعد التوليد والتثبيت، يجب أن يكون لديك مستودع git جديد مهيأ بالفعل. يمكنك الإيداع فيه بأمان لحفظ الحالة الراهنة من خلال هذه الأوامر: git add --all && git commit -m 'First commit' الخطوة 5: استعرض تطبيقك في متصفّح الويب إن أردت معاينة تطبيق الويب الخاص بك في متصفحك المفضل، ليس عليك القيام بأي شيء خاص لإعداد خادم ويب محلي على جهاز حاسوبك، فهو جزء من مهام Yeoman. تشغيل الخادم شغّل سكربت npm لإنشاء خادم http محلي يستند إلى Node على localhost:3000 (أو 127.0.0.1:3000 بالنسبة لبعض التكوينات) بتنفيذ الأمر التالي: npm run serve افتح لسانًا جديدًا في متصفحك وانتقل إلى العنوان 3000:localhost: إيقاف الخادم إذا احتجت في أي وقت إلى إيقاف الخادم، فاستخدم الاختصار Ctrl + C لإنهاء عملية سطر الأوامر الحالية. ملاحظة: لا يمكنك تشغيل أكثر من خادم http واحد على نفس المنفذ (3000 افتراضيًا). مراقبة ملفاتك افتح محرر النصوص الذي تفضّله وابدأ في إجراء التغييرات. سيفرض كل حفظِ لملفاتك تحديث المتصفح تلقائيًا إذ لا يتعين عليك القيام بذلك بنفسك. يُطلق على هذا إعادة التحميل المباشر وهي طريقة رائعة لتعاين حالة تطبيقك في الوقت الفعلي وعكس التغييرات مباشرةً على المتصفح دون أن تفعل أي شيء. تُوَّفر لتطبيقك عملية إعادة التحميل المباشر (Live reloading) من خلال مجموعة من مهام Gulp التي يتم إعدادها في الملف gulpfile.js و Browsersync التي يتم إعدادها في الملف gulp_tasks/browsersync.js؛ فهي تراقب التغييرات التي تطرأ على ملفاتك وتعيد تحميلها تلقائيًا في المتصفح في حالة اكتشاف تغيير ما. فيما يلي أدناه، حرّرنا الملف Header.js القابع في المجلّد src/app/components. بفضل التحديث المباشر، تظهر التغييرات مباشرةً في المتصفح وهذه صورة قبل إجراء أي تعديل: وصورة بعد إجراء تعديل (تغيير عنوان التطبيق) وحفظ الملف: لا تنس الاختبار! لديك تطبيق TodoMVC مجرّب وأنت تقوم بتغيير العنوان. يتعيّن عليك تعديل الاختبار في mytodo/src/app/components/Header.spec.js أو التراجع عن التغيير للتثبت من عملية إعادة التحميل المباشر. الخطوة 6: الاختبار باستخدام Karma و Jasmine إذا لم يكن Karma مألوفًا لديك، فهو برنامج اختبار شيفرات جافاسكربت أي إطار عمل محايد للاختبار. أمّا إطار الاختبار Jasmine فهو مدمج في المولد fountainjs. عندما نفّذنا الأمر yo fountain-webapp في وقت سابق من هذا الدليل، قام المولد بتوليد الملفات ذات النمط spec.js.* في المجلد المصدري لمجلد المشروع mytodo، وأنشأ الملف conf/karma.conf.js، ثم سحب وحدات Node إلى Karma. سنحرّر سكربت Jasmine لوصف الاختبارات قريبًا ولكن دعنا نرى كيف يمكننا إجراء الاختبارات أولًا. تشغيل اختبارات الوحدة دعنا نعود إلى سطر الأوامر ونوقف الخادم المحلي قسرًا باستخدام الاختصار Ctrl + C. يوجد بالفعل سكربت npm أُدرِج في الملف package.json الخاص بنا لإجراء الاختبارات. يمكن تشغيله على النحو التالي: npm test ينبغي أن تنجح جميع الاختبارات. تحديث اختبارات الوحدة ستجد اختبارات الوحدة مهيّأة في المجلد src، لذلك افتح الملف src/app/reducers/todos.spec.js. هذا هو اختبار الوحدة للمخفض (reducer) الخاص بـ Todos. على سبيل المثال، نركز على الاختبار الأول الذي يتحقق من الحالة الابتدائية. (ملاحظة: على ويندوز، قد تحتاج إلى إضافة 127.0.0.1 localhost إلى الملف etc/hosts): it('should handle initial state', () => { expect(todos(undefined, {})).toEqual([ { text: 'Use Redux', completed: false, id: 0 } ]); }); واستبدل هذا الاختبار بما يلي: it('should handle initial state', () => { expect(todos(undefined, {})).toEqual([ { text: 'Use Yeoman', // <=== هنا completed: false, id: 0 } ]); }); عندما نعيد تنفيذ الاختبارات عبر الأمر npm test، ينبغي أن نرى أن الاختبارات تفشل في هذه الحالة. ملاحظة: إذا كنت تريد تشغيل الاختبارات تلقائيًا بعد إجراء أي تعديل، يمكنك استخدام npm run test:auto بدلًا من ذلك. افتح src/app/reducers/todos.js ثم ضع الشيفرة التالية مكان الحالة الابتدائية (initial state): const initialState = [ { text: 'Use Yeoman', completed: false, id: 0 } ]; رائع! لقد أصلحت الاختبار: تسهِّل كتابة اختبارات الوحدة (unit tests) تحديد الأخطاء كلّما أصبح تطبيقك أكبر فأكبر وكلّما انضمّ المزيد من المطورين إلى فريقك. تجعل ميزة الاعتماد على السقالة (scaffolding) في Yeoman كتابة اختبارات الوحدة أسهل، لذا لن يكون لك عذر إذا لم تكتب اختباراتك بيديك! ;-) الخطوة 7: الاستفادة من التخزين المحلي لحفظ المهام (todos) دعنا نعيد النظر في مشكلة العناصر التي لا تثبت (تعاد إلى حالتها الأولية) عندما يُحدَّث المتصفح من خلال تطبيق mytodo مع React/Redux. تنويه: إذا لم يكن الثبات والتخزين المحلي مشكلةً بالنسبة لك أو كان وقتك ضيقًا، فيمكنك تخطي هذه الخطوة والانتقال مباشرة إلى الخطوة 8، "الاستعداد للإنتاج". تثبيت حزمة npm يمكننا استخدام وحدة Redux أخرى تسمى "redux-localstorage" تتيح لنا تنفيذ التخزين المحلي بسرعة وسهولة. نفِّذ الأمر التالي لتثبيتها: npm install --save redux-localstorage@rc استخدام redux-localstorage يجب إعداد مخزن Redux وضبطه لاستخدام التخزين. افتح الملف src/app/store/configStore.js واحذف كل محتواه وضع الشيفرة التالي مكانه: import {compose, createStore} from 'redux'; import rootReducer from '../reducers'; import persistState, {mergePersistedState} from 'redux-localstorage'; import adapter from 'redux-localstorage/lib/adapters/localStorage'; export default function configureStore(initialState) { const reducer = compose( mergePersistedState() )(rootReducer, initialState); const storage = adapter(window.localStorage); const createPersistentStore = compose( persistState(storage, 'state') )(createStore); const store = createPersistentStore(reducer); if (module.hot) { // Enable Webpack hot module replacement for reducers module.hot.accept('../reducers', () => { const nextReducer = require('../reducers').default; store.replaceReducer(nextReducer); }); } return store; } إذا عاينت تطبيقك في المتصفح، سترى أن هناك عنصرًا واحدًا "Use Yeoman" في قائمة مهام todo. يعمل التطبيق على تهيئة مخزن مهام todos إذا كانت مساحة التخزين المحلية فارغة ولم نضف فيها أي عناصر حتى الآن. جرب إضافة بعض العناصر إلى القائمة: الآن عندما تُحدِّث المتصفح، نلاحظ أن العناصر موجودة وثابتة. أمرٌ جيدٌ! يمكننا التأكّد من ثبات بياناتنا في التخزين المحلي عبر التحقق من لوحة الموارد (Resources) في أدوات المطور Chrome DevTools واختيار Local Storage في الجانب الأيسر: اكتب اختبارات الوحدة تريد تحديًا إضافيًا؟ حسنًا لك ذلك؛ أعد زيارة اختبارات الوحدة في الخطوة 6 وفكّر في كيفية تحديث اختباراتك الآن إذ تستخدم الشيفرة التخزين المحلي. الخطوة 8: الاستعداد لمرحلة الإنتاج هل أنت مستعد لعرض تطبيقك الجميل؟ دعنا نحاول بناء نسخة جاهزة للإنتاج نستطيع تسليمها للعميل مثلًا. تحسين الملفات من أجل الإنتاج لإنشاء نسخة نهائية من تطبيقنا، نحتاج إلى: فحص الشيفرة بحثا عن أي أخطاء محتملة عبر الأداة lint. تجميع واختصار السكريبتات والأنماط الخاصة بنا لحفظها. تفسير أي مُخرَجات للمعالجات الأولية (preprocessors) التي نستخدمها. وإجمالًا جعل تطبيقنا رشيقًا. ما يثير الدهشة هو أننا نستطيع فعل كل ما سبق فقط بتنفيذ الأمر البسيط التالي: npm run build إنّ تطبيقك الرشيق الجاهز للإنتاج متوفرٌ الآن في المجلد dist في جذر مجلد المشروع mytodo الخاص بك. هذه هي الملفات التي يمكنك وضعها على خادمك باستخدام FTP أو أي خدمة نشر أخرى. بناء ومعاينة التطبيق الجاهز للإنتاج هل تريد معاينة تطبيقك الجاهز للإنتاج محليًا؟ إليك مجرد سكربت npm بسيط آخر: npm run serve:dist سيعمل على بناء مشروعك وإطلاق خادم ويب محلي. إنّه رائع حقًّا! ختام الورشة، تهانينا! كما ترى، يمكن أن يتيح لك Yeoman الكثير والمزيد من الأدوات الخيارات، فيدعم تنصيب السقالات بناء تطبيقات Angular وبعض الإطارات الأخرى التي لم نتطرق لها هنا. على سبيل المثال، يدعم مولد Fountain Angular كذلك إنشاء أنابيب (pipes) وتوجيهات (directives) وخدمات (services) ومكونات (components) جديدة لك. يمكن توليد مكونات جديدة ببساطة وسهولة عبر تنفيذ الأمر: yo fountain-angular2:component componentName، والذي سيؤدي إلى إنشاء ملف المكون الخاص بك وإضافة شيفرة componentName.spec.js جديدة لاختبار الوحدة أيضًا. العثور على المزيد من المولدات الفرعية يمكنك في أي وقت استخدام الأمر: yo --generators للاطلاع على جميع المولدات الفرعية لمولدات Yeoman المثبَّتة. وماذا بعد ذلك؟ Yeoman دائم التطور. احرص على زيارة الموقع yeoman.io للحصول على مزيد من المعلومات ومتابعة Yoman@ على تويتر لمواكبة المستجدات. ساعدتنا مولدات Fountain على كتابة هذا التطبيق Todo بسرعة وأناقة. تابع YeomanFountain@ للبقاء على اطلاع على الميزات الجديدة والإصدارات الجديدة. React هو مكتبة جافا سكريبت لبناء واجهات المستخدم. اطلع على توثيق React في موسوعة حسوب للتعرف على هذه المكتبة أكثر. Angular2 إطار عمل للتطوير على كافة المنصّات. Webpack عبارة عن وحدة مجمعة (module bundler) نموذجية تأخذ الوحدات النمطية ذات الاعتماديات وتولد أصول ثابتة (static assets) تمثل تلك الوحدات. *JSPM حزمة إدارة متصفح. حمّل أي تنسيق للوحدة (ES، و AMD، و CommonJS، وglobals) مباشرة من أي سجل مثل npm و GitHub مع إدارة تبعية حديثة الإصدار (flat versioned dependency management). هذا كل ما ينبغي ذكره الآن بخصوص Yeoman. المصادر Getting Started With Yeoman Let's Scaffold A Web App With Yeoman
  6. لقد كان هناك دائمًا جدل مستمر حول ما إذا كنا بحاجة إلى توسيع مفهوم DevOps من أجل جلب الأمان بوضوح. بعد كل شيء، من الواضح أن DevOps كانت دائمًا اختزالًا لمجموعة واسعة من الممارسات الجديدة باستخدام أدوات جديدة (غالبًا ما تكون مفتوحة المصدر) ومبنية على ثقافات أكثر تعاونًا. ولم لا نتجه نحو DevBizOps لتحسين التوافق مع احتياجات السوق؟ أو DevChatOps للتشديد على نظام اتصال أفضل وأسرع؟ ومع ذلك، كما كتب جون ويليس في وقت سابق من هذا العام عند وقوفه على المصطلحات الخاصة بـالDevSecOps: "نأمل أنه في يوم من الأيام سنكون في عالم ليس علينا أن نستخدم فيه كلمة DevSecOps، وسيكون الأمن جزءًا لا يتجزأ من جميع مناقشات تقديم الخدمة. حتى ذلك اليوم، وفي هذه المرحلة، استنتاجي العام هو أنها مجرد ثلاث حروف جديدة (Sec). والأهم من ذلك أن الاسم يميز حقًا مشكلتنا في عالم لا نقوم فيه بعمل رائع في مجال أمن المعلومات." فلماذا لا نقوم بعمل رائع في مجال أمن المعلومات؟ وماذا يعني القيام بعمل رائع في سياق DevSecOps؟ لم نتمكن من القيام بعمل كبير في مجال أمن المعلومات على الرغم من (أو ربما بسبب) الإنتاج الواسع للبرامج المعقدة التي تعالج المشاكل الضيقة. لكننا أيضًا قمنا بعمل جيد بما فيه الكفاية خلال تلك الفترة عندما كان الدفاع ضد التهديدات يركز على تأمين محيط العمل فقط، وكانت اتصالات الشبكة محدودة، وكان معظم المستخدمين موظفين يستخدمون أجهزة توفرها الشركة. لا تصف هذه الظروف بدقةٍ حقيقة معظم المنظمات منذ عدة سنوات حتى الآن. لكن الحقبة الحالية، التي لم تجلب مفهوم DevSecOps فحسب، بل حتى الأنماط الهيكلية للتطبيقات الجديدة، وممارسات التطوير، وعدد متزايد من التهديدات، تحدد وضعًا طبيعيًا جديدًا وقاسيًا يتطلب وتيرة تغيير أسرع. ليس تغيير منظومة الأمان مرتبطا بالDevSecOps منعزلة، ولكن الأمر يتطلب أمنًا معلوماتيًا بمقاربات جديدة. أمعن النظر في هذه المجالات الخمسة. 1. الأتمتة (Automation) إن السمة المميزة لـ DevOps بشكل عام هي الأتمتة بأكبر قدر ممكن. ويتعلق الأمر جزئياً بالسرعة. إذا كنت ستتحرك بسرعة (دون الإضرار بالأشياء)، فستحتاج حتمًا إلى عمليات قابلة للتكرار تُنفذ دون تدخل بشري كبير. في الواقع، تعد الأتمتة مدخلًا مهمًا لـDevOps، حتى في المؤسسات التي لا تزال تعمل في الغالب على التطبيقات القديمة المتجانسة. وتمثل أتمتة العمليات الروتينية المرتبطة بالتكوينات أو الاختبارات باستخدام أدوات سهلة الاستخدام مثل Ansible دفعةً سريعةً لبدء الطريق إلى DevOps. ليست DevSecOps مختلفة عن هذا المفهوم، فالأمن اليوم هو عملية مستمرة وليس نقطة تفتيش منفصلة في دورة حياة التطبيق، أو حتى فحصًا أسبوعيًا أو شهريًا. عندما يُعثر على الثغرات ويُصدر البائع إصلاحاته، يكون من المهم أن تُطبّق بسرعة لكي تنتهي عمليات استغلال هذه الثغرات الأمنية قريبًا. 2. التحرّك نحو اليسار (Shift left) غالبًا ما يُنظر إلى الأمن التقليدي كحارس بوابة في نهاية عملية التطوير. افحص جميع الصناديق وسيمرّ تطبيقك إلى مرحلة الإنتاج وإلّا حاول مرة أخرى. تُعرف فرق الأمن بأنها لا تكثر الكلام. وبالتالي، لم لا نحرك الأمن مبكرًا نحو اليسار (في الرسم النموذجي من اليسار إلى اليمين لمسلسل التطوير)؟ قد يصرّ الأمنيون على الرفض، ولكن عواقب إعادة الصياغة في مرحلة مبكرة من التطوير هي بالتأكيد أقل بكثير مما يكون عليه الحال عندما يكون التطبيق كاملًا وجاهزًا للتسليم. لا أحب مصطلح "التحرّك نحو اليسار" فذلك يعني أن الأمان لا يزال مجرّد حدثٍ لمرة واحدة نُقل لمرحلة مبكّرة. يجب أن يكون الأمان عملية مؤتمتة إلى حد كبير في كل مكان في دورة حياة التطبيق، من سلسلة التوريد إلى عملية التطوير والاختبار على طول الطريق حتى النشر. 3. إدارة التبعيات (Manage dependencies) أحد التغييرات الكبيرة التي نراها في تطوير التطبيقات الحديثة هو أنك غالبًا لا تكتب معظم الكود. ويعدّ استخدام المكتبات والأطر مفتوحة المصدر مثالًا واضحًا على ذلك. لكن يمكنك أيضًا استخدام الخدمات الخارجية من موفري الخدمات السحابية العامة أو مصادر أخرى. في كثير من الحالات، ستغطي هذه الأكواد والخدمات الخارجية على ما تكتبه بنفسك. نتيجة لذلك، تحتاج منظومة DevSecOps إلى تركيز جادٍّ على سلسلة التوريد الخاصة بالبرنامج. هل تحصل على برنامجك من مصادر موثوقة؟ هل هو مُحدّث؟ هل هو مدمج في عمليات الأمان التي تستخدمها لكودك الخاص؟ ما هي السياسات التي تطبقها في أيّ أكوادٍ وأيّ واجهات لبرمجة التطبيقات قد تستخدمها؟ هل يتوفر الدعم التجاري للمكونات التي تستخدمها لشيفرة المنتج الخاص بك؟ لن تكون هناك مجموعة من الإجابات تناسب جميع الحالات. قد تكون مختلفة في حالة "إثبات الجدوى" عنها في حالة الإنتاج على نطاق واسع. ولكن، كما كان الحال في التصنيع لفترة طويلة (هناك العديد من أوجه الشبه بين DevSecOps وكيفية تطور التصنيع)، تبقى سلامة سلسلة التوريد أمرًا بالغ الأهمية. 4. الرؤية (Vision) لقد تحدثت كثيرًا عن الحاجة إلى الأتمتة خلال جميع مراحل دورة حياة التطبيق. هذا يجعلنا نفترض أنه يمكننا رؤية ما يجري في كل مرحلة من تلك المراحل. تتطلب منظومة DevSecOps الفعالة بالضرورة أدوات فعالة حتى يتضح ما يجب على الأتمتة أن تقوم به. وتندرج هذه الأدوات في عدد من الفئات. هناك مقاييس طويلة الأمد وعالية المستوى تساعدنا في معرفة ما إذا كانت عملية DevSecOps الشاملة تعمل بشكل جيد. وهناك أدوات إنذار حساسة تتطلب تدخلًا بشريًا فوريًا (إذا كان نظام المسح الأمني معطّلًا!). وهناك إنذارات، مثل الفحص الفاشل، تتطلب علاجًا أو إصلاحًا. وهناك سجلات للعديد من البارامترات التي نلتقطها من أجل التحليل لاحقًا (ما الذي يتغير بمرور الوقت؟ وما الذي يتسبب في هذا الفشل؟). 5. الخدمات مقابل الوحدات المتراصة رغم أنه يمكن تطبيق ممارسات DevSecOps على العديد من هياكل تصميمات التطبيقات، إلا أنها تكون أكثر فاعلية من خلال المكونات الصغيرة والموضوعة بشكل فضفاض يتيح تحديثها وإعادة استخدامها دون فرض تغييرات في أماكن أخرى من التطبيق. يمكن أن تكون هذه المكونات في أنقى صورها خدمات مصغرة أو وظائف، لكن المبادئ العامة تنطبق حيثما كان لديك خدمات مقترنة بشكل فضفاض تتواصل عبر الشبكة. يقدم هذا النمط بعض التحديات الأمنية الجديدة. يمكن أن تكون التفاعلات بين المكونات معقدة ويمكن أن تكون المساحة المعرّضة للهجوم أكبر لأن هناك الآن المزيد من نقاط الدخول إلى التطبيق عبر الشبكة. من ناحية أخرى، يدلّ هذا النمط من الهياكل على أن الأمن والمراقبة الآليين يتمتعان أيضًا برؤية أكثر دقة لمكونات التطبيق لأنها لم تعد مدفونة بعمق داخل تطبيق متراصٍّ. لا تنغمس كثيرًا في مصطلح DevSecOps، ولكن عليك أن تتذكر أن الأمن يتطور لأن الطريقة التي نكتب بها وننشر التطبيقات تتطور. ترجمة وبتصرف للمقال ‎5 ways DevSecOps changes security لغوردون هاف
  7. يعرف كل مطور أهمية اتباع أفضل ممارسات الأمان. لكننا في كثير من الأحيان نتصرف باقتصاد ولامبالاة، ربما لأنه يتعين علينا العمل بجد حتى تترسخ تلك الممارسات الأمنية. لسوء الحظ، يكون هذا مثل رؤية سلوك أمني سيء جدًا لدرجة لا يُمحى فيها من أدمغتنا. لقد رأيت الكثير من حالات ممارسات الأمان السيئة أثناء مسيرتي مديرًا للأنظمة، لكن الأمور الثلاثة التي سأصفها هنا أساسية ويجب على كل مطور برمجيات تجنبها. من المهم الإشارة إلى أنني رأيت الشركات الكبيرة والمطورين ذوي الخبرة يرتكبون هذه الأخطاء، لذلك لا يمكنك أن تربط هذه الأخطاء بالمهندسين المبتدئين. 1. لا تشفر كلمات المرور، بل جزّئها في وقت سابق من حياتي المهنية، عملت لدى شركة تستخدم نظامًا إداريًا يحتوي على بعض المعلومات المهمة. في أحد الأيام، طُلب مني إجراء مراجعة أمنية للشبكة والبرنامج الذي يُخزّن معلوماتنا المهمة. أمضيت بضع دقائق في التجول قبل أن أقرر استخدام برنامج وايرشارك لتحليل حركة المرور في الشبكة. استخدمت جهازي المحلي، وسجلت الدخول إلى نظام المعلومات، فلاحظت شيئًا غريبًا. على الرغم من أن هذا كان قبل انتشار بروتوكول SSL، إلا أنني لم أتوقع أن أرى البيانات بنص عادي يحتوي على بايتات مثل "اسم المستخدم" و "كلمة المرور". عند الفحص الدقيق، بدا أن النظام كان يرسل اسم المستخدم الخاص بي وسلسلة عشوائية، لم تكن كلمة المرور الخاصة بي، عبر الشبكة. لم أستطع ترك الأمر كذلك. لقد حاولت تسجيل الدخول مرة أخرى، إلا أنه في هذه المرة أدخلت كلمة المرور الخاصة بي خاطئة عن قصد. لم أغيرها كاملة، بل حرفا واحدًا فقط. ما كنت أتوقعه هو سلسلة عشوائية مختلفة تمامًا تمثل كلمة المرور. بدلاً من ذلك، تغيّر البايتان الأولان فقط. كان هذا مثيرًا للاهتمام. على الرغم من أنني كنت قليل الخبرة نسبيًا، فقد علمت أنه إذا تجزّأ تمثيل كلمة المرور الخاصة بي كما كان مفترضًا، فسيكون الأمر مختلفًا تمامًا، ولن يكون الاختلاف في حرفين فقط. تبًّا، فحتى مخطط تشفير جيد سيفعل ذلك. لكن هذا، مع ذلك، لم يفعل ذلك على الإطلاق. لقد جربت مرتين أخريين كلمات مرور خاطئة. أمضيت الساعتين التاليتين مسلّحا ببعض الأوراق وقلم رصاص في اكتشاف مخطط فك التشفير. في نهاية الساعتين، كان لديّ نص بايثون يمكن أن يأخذ أي كلمة مرور "مشفرة" ويفك تشفيرها للكشف عن كلمة المرور الأصلية، وهو أمر لا ينبغي لأحد أن يفعله. أنا متأكد من أن الشخص الذي تخيل مخطط التشفير هذا لم يفكر أبدًا في أن شخصًا ما سوف يجلس ساعتين ويستطيع حلّه، لكنني فعلت ذلك. لماذا؟ لأنني أستطيع ذلك. إذا كان عليك تخزين كلمات المرور للمقارنة، فلا تشفرها مطلقًا إذ يُحتمل دائمًا أن يجد شخص ما خوارزمية أو مفتاح فك التشفير. ليس للتجزئة (hash) انعكاس مباشر، مما يعني أنه لا يمكن لأحد عكسها ما لم يكن لديه بالفعل جدول مع التعيين من النص العادي إلى التجزئة (أو أن يخمنه ببساطة). لا تؤثر معرفة آلية التجزئة على سلامة البيانات، بينما يضر بها انكشاف مخطط ومفاتيح التشفير. 2. لا تضع أبوابا خلفية سرية في البرنامج كجزء من متابعة برنامج تابع لجهة خارجية، كنت أدعم بعض المستخدمين الذين أخبروني أن تسجيلات الدخول الخاصة بهم لا تعمل. كانت هذه خدمة مدفوعة الأجر مقدمة من بائع، لكن قبل أن أتعامل مع أحد كانت أكثر مكالمات الدعم إزعاجًا تحت عنوان "لا يعمل تسجيل الدخول الخاص بي"، اعتقدت أنني سأحاول ذلك بنفسي. لقد كان الأمر صحيحًا، لم تعمل تسجيلات الدخول. كان النظام عبارة عن منصة لإدارة التعلم عبر الإنترنت، والتي دفعنا مقابلها جزءًا صغيرًا من قدراتها الكبيرة. عندما بحثت بفضول في صفحة تسجيل الدخول، لفت انتباهي شيء ما. بدا لي حرف واحد في إحدى الكلمات مختلفًا. ربما كان خطًا مختلفًا للكتابة، أي شكلًا مختلفًا قليلاً لحرف "o". ولأنني أنا دون غيري، فتحت الصفحة بطريقة عرض المصدر، ولاحظت وجود رابط مرتبط بهذا الحرف المحدّد. لقد أُخفي الرابط عن قصد بحيث لا يتغير مؤشر الفأرة عند التمرير فوقه. لهذا حمّلت هذا الرابط الغامض بحذر شديد في نافذة متصفح جديدة. وفجأة ، قابلتني شاشة تعرض بالتفصيل مجموعة كاملة من أجهزة الحواسيب، وتمنحني سيطرة كاملة على ما يمكنها القيام به والقدرة على إيقاف تشغيلها، وإعادة تشغيلها، وأخذ لقطات للشاشة، سمِّها ما شئت. اتصلت ببائع البرنامج وطلبت التحدث إلى تقني المعلومات. بعد المرور على بعض الأشخاص، وصلت أخيرًا إلى شخصٍ يعرف مسبقًا ما الذي كنت أتحدث عنه. قال لي: "أوه نعم! لقد وضعنا ذلك في مكان يسهل الوصول إليه، ولم يعثر عليه أحد حتى الآن قبلك. سنقوم بإزالته على الفور". قبل أن ننهي المكالمة، سألني سؤالًا أخيرًا:" لماذا بدأت تبحث في HTML؟". كانت إجابتي بسيطة: "لأنني أستطيع". إن الأمر لا يستحق المخاطرة بوضع منفذٍ خلفيٍّ جميلٍ في أي نظام، لأنك قد تراهن بآخر دولار لديك وسيجده شخص ما. بغض النظر عن مدى الغموض، غالبًا ما يؤدي تحليل الشفرة، وحتى البحث الفضولي السطحي، إلى أكثر النتائج غرابةً وإثارة للاهتمام. 3. فعِّل تصديق هوية المستخدمين في كل صفحة، وليس فقط على صفحة تسجيل الدخول في مرحلة ما من حياتي المهنية، شاركت في مشروع لتطوير البرمجيات نفّذه مطوّر متمرس. بعد أن شعرت قليلاً بقلّة الحيلة أمام هذا التطبيق المميز، أخبرت مديري أننا سنحتاج إلى مراجعة أمنية معمقة للشيفرة. وطُلب مني النظر على أي حال لمعرفة ما يمكن أن أجده. بدأت اللعب مع التطبيق، وسجلت الدخول، وعرضت بعض البيانات. ثم وجدت شيئًا مثيرًا للاهتمام حقًا. إذا وضعت إشارة مرجعية على أحد عناوين URL التي ألج إليها كثيرا في النظام، فيمكنني فقط نسخها ولصقها في متصفح آخر، وقضي الأمر! سأكون هناك دون الحاجة إلى تسجيل الدخول. سألت المطور: "لماذا لا تُسجّل الدخول في كل صفحة؟ إذا أدخلت عنوان URL لصفحة ما في النظام، فيمكنني الوصول إليها دون تسجيل الدخول". فسألني: "لماذا تفعل ذلك؟". أجبته: "لأنني أستطيع". لا تترك أي شيء للصدفة حتى المطورون المتمرسون قد يرتكبون هذه الأخطاء. يعتقدون أن لا أحد سيحاول مطلقًا الخوض في نظام لا يستطيع الوصول إليه فعليًا. المشكلة هي أن الناس سوف يبحثون بفضول، وسوف يحفرون. نصيحتي الجوهرية التي أود أن أنقلها هنا لأي شخص مهمته مراعاة الأمان فقط هي: لا تترك أي شيء للصدفة. هناك أشخاص مثلي، يحبون الحفر في الأشياء ومعرفة علّة وكيفية عملها. ولكن هناك أيضًا عدد كبير من الأشخاص الذين سيحفرون لاستغلال عيوبك ونقاط ضعفك. لماذا؟ لأنهم يستطيعون! ترجمة وبتصرف للمقال ‎3 security tips for software developers لبيت سافايج
  8. أنت تعمل على الانتقال إلى منظومة DevOps وتطبيقها في مؤسستك بالكامل أو في جزءٍ منها فقط: حسنًا! ها قد حقّق شخص ما في مكان ما قفزة نوعية. لنفترض، لأغراض هذا المقال، أن لديك موافقة من الإدارة: مهما كانت العقبات التي ينبغي عليك تجاوزها وكيفما كانت الجبال التي تحتاج لتسلقها للحصول على ذلك الجواب بـ "نعم". لقد حصلت على موافقة على الأدوات ووضعت كل الإجراءات والعمليات على الطاولة، والآن كل ما عليك القيام به هو إقناع الناس بالاندماج في المنظومة. يجب أن يكون هذا الأمر سهلا، أليس كذلك؟ نتمنى لو يكون كذلك. يتضح أنه ليس كل الناس مستنيرين مثلك أنت قارئ هذا المقال. لا يحب الناس كلّهم التغيير، وإذا كان هناك شيء واحد يمكنك التأكد منه، فهو هذا الأمرُ. ستحقق منظومة DevOps التغيير لمؤسستك: كيف عليك أن تعمل؟ وماذا تفعل؟ وكيف تتفاعل مع الأشخاص الآخرين داخل الفريق وخارجه؟ سوف أَصِفُ هنا خمسة أنواع من الأشخاص أو الأدوار الذين قد يعارضون عملية الانتقال إلى DevOps، كما سأعرض بعض الأفكار حول التكتيكات الممكنة للمساعدة في تحفيزهم للاندماج فيها. ومع ذلك، يجب أن نتذكر أنك قد لا تتمكن من تعبئة الجميع، وقد تكون هناك أسباب وجيهة لعدم رغبة الناس في تغيير ما يقومون به، بما في ذلك حقيقة أن ما يقومون به في الوقت الحالي قد يعمل بشكل جيد، سواء بالنسبة لهم أو للمنظمة. هذا لم يُخترَع من أجلنا: الخوف من المجهول "لقد فعلنا هذا على مدار الأعوام الماضية (سنة أو سنتان أو خمس أو عشر أو خمس وعشرون سنة)، وكان هذا الأمر ينجح دائمًا حتى اليوم". لقد سمعنا جميعًا عبارات كهذه. وقد يكون هذا صحيحًا أو قد لا يكون كذلك، ولكن إذا قررت إدارتك أنه يجب إجراء الانتقال إلى DevOps حتى لو كانت الممارسات الحالية تعمل، فمن الأرجح أن يكون هناك إدراك أن الأمور يمكن أن تكون أكثر كفاءةً أو سرعةً أو أمانًا. إن إحدى النقاط المُحدِّدَة لهذا النوع من الأشخاص أو الأدوار هي أنه يتصرف في كثير من الأحيان كفريق. وغالبًا ما تعتاد الفرق على طريقة معينة للقيام بالأشياء وعلى استقرار في الأدوار والروتينات التي تناسبها. وبالتالي فما تقترحه أنت هنا يمثل إزعاجًا للفريق ويجعل الناس يفعلون أشياء مختلفة. يجب أن تفكر في كيفية تحقيق أقصى استفادة من الفريق كما هو موجود الآن، أو ربما بنقل أعضاء ذلك الفريق معًا أو بإبداء نوع من الاحتفال بنجاحهم، بدلاً من اقتراح التغيير و تعليله بأنهم فشلوا بطريقة أو بأخرى. مجالي: الخوف من فقدان السيطرة هذا نوع من الأشخاص أعرفه تمامًا على المستوى الشخصي بحكم خلفيتي الأمنية. غالبًا ما يشعر الأشخاص الذين حصلوا على مستوى عالٍ من الخبرة في ميدان أو مجال معين بالتهديد عندما يُطلب منهم تغيير طريقة عملِهم أو تطبيقِ معارفهم. سيشعرون غالبًا بأنهم مطالبون بالتخلي عن السيطرة و بـ "تخفيف" خبراتهم في عالم جديد فيه "كلّ شخص هو الخبير". ما يهمّ التأكيد عليه في هذا السياق هو أنه بدلاً من تخفيف خبراتهم، تعدّ هذه فرصة لتطبيقها على مجموعة واسعة من العمليات. ينبغي على خبراء الاختبار أن يشرحوا للمطورين وأفراد العمليات، على سبيل المثال، كيف يمكن عرض منهجيات الاختبار في مجالاتهم. عادةً ما ينظر الخبراء بإيجابيةٍ إلى مسألة عرضهم أمام جمهور أوسع، وعلى الرغم من أنه سيكون هناك دائمًا شخصيات من نوع "البرج العاجي" تكافح من أجل التفاعل في إطار أكثر جماعية، فإن استخدام هؤلاء بطرق يأخذون فيها دور "الاستشاري" قد يوفر فرصًا إيجابيةً. متشبث بأسلوبي: الخوف من الجديد رغم أنه يشبه إلى حد بعيد شخصية "لم يخترع من أجلنا"، إلا أنه يعد فردًا أكثر من كونه سمة جماعية. قد تبدو معرفة ما ستكون عليه مهامك على أساس يومي تافهة للبعض ولكنها قد تكون مريحةً للغاية بالنسبة للكثيرين، وهذا هو السبب في أنهم قد لا يرغبون في الانتقال إلى عالم يبدو "أكثر حرية" وغير منظّمٍ. لا يمكن أن يكون الجميع مثل ذلك النوع من الموسوعيين الذين ينجحون في فهم جميع الأجزاء المختلفة من دورة DevOps. الخبر السار هنا هو أنك ستظل بحاجة إلى أشخاص مستعدين للاستقرار في مهام محددة وإكمالها بطرق معينة. في الواقع، على الرغم من وجود مخاوف مبدئية حول الانتقال إلى بيئة مختلفة للعمل، فإن توضيحك لأعضاء الفريق أنه سيكون لديهم قدر لا بأس به من التحكم في كيفية أدائهم لمهام معينة قد يكون رسالةً إيجابيةً عند محاولة مساعدة هذا النوع من الأفراد. ونأمل أن يساهم تضمينك للتدريب، رسميًا كان أو غير رسمي، كجزء من تحولك إلى DevOps وكذا الفرص المتاحة لتعلم مهارات جديدة (وبالتالي زيادة حركية الأفراد وفرص العمل) أيضًا كحوافز للتغيير. مدراء الأفراد: الخوف من فقدان السلطة يتمتع المديرون في العديد من المؤسسات، وخاصة تلك التي تتمتع بتسلسل هرمي قويٍّ ومتطوّرٍ، بقدر كبير من التحكم في كيفية انتشار موظفيهم وطبيعة مهامهم وكيفية إدارة تقدمهم الوظيفي. كل هذه الأمور يمكن أن تكون مباشِرة خلافًا لمقاربة DevOps التي تعدّ أكثر انفتاحًا. بالنسبة للمديرين الذين بنوا إمبراطوريتهم الصغيرة بالتحكم في تقاريرهم الرئيسية و الفرعية مثل البيادق حول لوحة الشطرنج، سيكون الانتقال إلى DevOps تحدّيًا كبيرًا. أما بالنسبة للمديرين الذين يحرصون على تطوير أعضاء فرقهم ليصبحوا موظفين أكثر خبرة، والذين يقيسون نجاحهم بعدد الفرق الأخرى التي تطلب إعارة تقاريرها إلى فرقهم، والذين يستمتعون كذلك برؤية مهارات جديدة وبالتقدم الوظيفي، ستكون DevOps بالتأكيد فرصةً مثيرةً. من الراجح أن يكون أسلوب العصا و الجزرة جزءًا من أي حلٍّ لمشكلة المديرين الذين يقاومون الإدارة التنفيذية. يمكن أن تتضمن الجزرة تغيير كيفية مكافأة المديرين وفقًا لآلية تتبنى هذه السلوكيات الجديدة، في حين قد تتضمن العصا تجريد فرقهم من بعض أعضائها أو إعادة تحديد دور هؤلاء المديرين. النقابات: الخوف من عدم اليقين في بعض المصانع والمناطق، هناك نقابات قوية. تتمثل المهمة الأساسية للنقابات في حماية العمال من الاستغلال من قبل الإدارة التي قد تحاول فرض تغييرات على العمال لن تعود عليهم بفائدة. تشتبه النقابات بشكل افتراضي ومفهومٍ كذلك في أي تغييرات تدخلها الإدارة، لذا فإن أي انتقال إلى DevOps تباركه الإدارة قد يثير مخاوف ومقاومة النقابات وأعضائها. في بعض الحالات، قد يكون الموظفون قد وصفوا بعناية أدوارهم الوظيفية التي تجعل من الصعب تقديم طرقٍ للعمل يتوقع منهم فيها القيام بدور أكثر موسوعيةً وتعلم مهارات جديدة، وهذان كلاهما من خصائص DevOps. والخبر السار هنا هو أن DevOps يمكن أن توفر المزيد من التحكم لأعضاء الفريق، بطرق مختلفة كثيرة، مما يقلل إلى حد ما من السيطرة التي تمارسها وظيفة الإدارة. سيكون توضيح ذلك والتأكد من إجراء عمليات الفحص المناسبة لحماية الوظائف أحد المفاتيح الرئيسية لإقناع النقابات وأعضائها بأن هذا تغيير جيد بالنسبة لهم. والشيء الآخر الذي كان يجب أن يحدث، بالطبع، هو أنه كان ينبغي على الإدارة إدماجهم مبكرًا في العملية للتأكد من انخراطهم من البداية، بدلاً من اتخاذ قرارٍ "نبت" فجأة في اللحظة الأخيرة. أفكار ختامية مع تقدمنا نحو مستقبل جديد مشرق، تجدر الإشارة إلى أن الخير العام للجميع لا يترجم دائمًا إلى تغيير إيجابي لكل فرد. يصعب القول أن بناء شبكات الصرف الصحي ليس خيرًا عامًّا، لكنه يؤذي من كانت وظيفتهم الحرص على نظافة الشوارع. نأمل ألا ترى انتقالك إلى DevOps كإنشاء مجموعة جديدة من شبكات الصرف الصحي لمؤسستك، ولكن انتبه إلى أولئك الذين قد يكون التغيير بالنسبة لهم صعبًا ومضطربًا. يمكن أن يكون هناك تكلفة بشرية لأي تطوير مهما حسنت نيته. بالنسبة لي، أهم نقطة ينبغي تذكرها هي أنه عندما يصبح الأشخاص دفاعيين، بل وأحيانًا عدوانيين، يكون ذلك عمومًا لأنهم يشعرون بالتهديد، وفي كل هذه الحالات التي فحصناها، قد يكون التغيير مهدِّدًا بالفعل. إن هؤلاء الناس هم زملاؤك. وهُم أناس أيضًا، ويجب معاملتهم باحترام وتقدير كأشخاص، وليس فقط كأدوار أو عقبات يتعين التغلب عليها. في بعض الحالات، قد يكون الحفاظ على الوضع الراهن في أجزاء خاصة من مؤسستك الخيار الأكثر أمانًا، في الوقت الحالي على الأقل. ترجمة وبتصرف للمقال Who will push back the most on a move to DevOps?‎ لمايك بورسيل
  9. عندما تُنشئ خادم أوبونتو 18.04 لأول مرة، فهناك بعض خطوات الإعداد التي ينبغي عليك اتخاذها مبكّرًا كجزء من الإعداد الأساسي. سيزيد ذلك من أمان الخادم وسهولة استخدامه وسيمنحك أساسًا قويًا لاتخاذ إجراءات لاحقة. رغم أنه يمكنك إكمال هذه الخطوات يدويًا، إلا أنه في بعض الأحيان يكون من الأسهل برمجة العمليات عبر سكربت لتوفير الوقت وتفادي الأخطاء البشرية. يشرح هذا الدليل كيفية أتمتة الخطوات الموجودة في دليل إعداد الخادم الأولي في سكربت. ماذا يفعل السكربت؟ يعدّ هذا السكربت بديلًا للتشغيل اليدوي من خلال الطريقة الموضحة في دليل إعداد خادم أوبونتو 18.04 الأولي ودليل إعداد مفاتيح SSH على أوبونتو 18.04. تؤثر المتغيرات التالية على كيفية عمل السكربت: USERNAME: اسم حساب المستخدم العادي الذي ستُنشأ وتمنح له صلاحيات sudo. COPY_AUTHORIZED_KEYS_FROM_ROOT: تحدّد ما إذا كنت تريد نسخ أصول مفتاح SSH من الحساب الجذري root إلى حساب sudo الجديد. OTHER_PUBLIC_KEYS_TO_ADD: مجموعة من السلاسل النصية التي تمثل مفاتيح عامة أخرى تُضاف إلى الحساب sudo. يمكن استخدام هذه بالاختيار بين إضافتها أو جعلها بديلًا لنسخ المفاتيح من الحساب الجذري root. يجب عليك تحديث هذه المتغيرات حسب الحاجة قبل تشغيل السكربت. عند تنفيذ السكربت، تُنفّذ الإجراءات التالية: إنشاء حساب مستخدم عادي مع امتيازات sudo باستخدام الاسم الذي يحدده المتغير USERNAME . إعداد إطار لكلمة المرور الأولية للحساب الجديد: إذا كان الخادم معدًّا لمصادقة الهوية بكلمة المرور، فستُنقل كلمة المرور الإدارية الأصلية التي وُلِّدت لحساب root إلى حساب sudo الجديد. حينها تكون كلمة المرور للحساب الجذري مقفلة. إذا كان الخادم معدًّا لمصادقة الهوية بمفتاح SSH، فستُعيّن كلمة مرور فارغة لحساب sudo. تُعلّم كلمة مرور المستخدم sudo بعلامة "منتهي الصلاحية" مما يوجب تغييرها عند أول تسجيل للدخول. يُنسخ ملف Authorized_keys من الحساب الجذري إلى مستخدم sudo إذا عُيِّن المتغير COPY_AUTHORIZED_KEYS_FROM_ROOT على "صحيح". تُضاف أي مفاتيح معرّفة في OTHER_PUBLIC_KEYS_TO_ADD إلى ملف Authorized_keys للمستخدم sudo. يُعطّل التصديق SSH المستند إلى كلمة المرور في الحساب الجذري root. يُفعّل جدار الحماية UFW مع السماح باتصالات SSH. كيف يُستخدَم السكربت؟ يمكن تنفيذ السكربت بطريقتين: عن طريق إضافته إلى حقل بيانات مستخدم الخادم أثناء الإنشاء أو عن طريق تسجيل الدخول بحساب root وتنفيذه بعد التشغيل. عبر بيانات المستخدم عند إنشاء Droplet على DigitalOcean، يمكنك تحديد بيانات المستخدم، وهو سكربت يُنفّذ أثناء تشغيل الخادم الأولي من أجل إجراء إعدادٍ إضافي. إذا كنت تُنشئ Droplet من لوحة التحكم، فيمكنك تحديد خانة الاختيار "بيانات المستخدم" في قسم تحديد خيارات إضافية. سيظهر لك مربع نصي حيث يمكنك لصق السكربت: إذا كنت تُنشئ Droplet باستخدام واجهة برمجة تطبيقات DigitalOcean، فيمكنك تمرير السكربت باستخدام سمة user_data بدلاً من ذلك. إذا كنت تُنشئ Droplet باستخدام أداة سطر الأوامر doctl، فيمكنك تمرير السكربت باستخدام خيار ‎--user-data-file: $ doctl compute droplet create ... --user-data-file /path/to/script بغض النظر عن الطريقة التي تستخدمها لإضافة بيانات المستخدم، سيُنفّذ السكربت في أول مرة يُشغّل فيها الخادم الجديد. قد تضطر إلى الانتظار لبضع دقائق حتى تكتمل العملية، ولكن بعد ذلك، يمكنك تسجيل الدخول إلى الخادم الخاص بك عبر حساب المستخدم sudo للحصول على أي إعداد إضافي. عند تسجيل الدخول لأول مرة، سيُطلب منك تغيير كلمة المرور الخاصة بك. سينهي الخادم جلسة SSH الحالية بمجرد تقديم بيانات الاعتماد الجديدة الخاصة بك وتأكيدها. بعد ذلك، يمكنك إعادة SSH مرة أخرى مثل العادة. تنفيذ السكربت بعد التشغيل إذا كنت لا ترغب في استخدام بيانات المستخدم، يمكنك أيضًا تشغيل السكربت يدويًا عبر SSH بمجرد تشغيل الخادم. إذا نزّلت السكربت على جهاز الكمبيوتر المحلي الخاص بك، يمكنك تمرير السكربت مباشرةً إلى SSH بكتابة ما يلي: $ ssh root@servers_public_IP "bash -s" -- < /path/to/script/file ينبغي أن تكون الآن قادرًا على تسجيل الدخول باستخدام حساب sudo الخاص بك من أجل أي إعداد إضافي. إذا لم تُنزّل السكربت على جهاز الحاسوب المحلي، فابدأ بتسجيل الدخول إلى الحساب root على الخادم الخاص بك: $ ssh root@servers_public_IP بعد ذلك، نزِّل السكربت الأولي على الخادم: $ curl -L https://raw.githubusercontent.com/do-community/automated-setups/master/Ubuntu-18.04/initial_server_setup.sh -o /tmp/initial_setup.sh افحص السكربت للتأكد من تنزيله بشكل صحيح و حدِّث أي متغيرات ترغب في تغييرها: $ nano /tmp/initial_setup.sh عندما تكون راضيًا عن المعطيات، شغّل السكربت يدويًا باستخدام bash: $ bash /tmp/initial_setup.sh ينبغي أن تكون الآن قادرًا على تسجيل الدخول باستخدام الحساب ذي الصلاحيات sudo لإتمام أي إعدادٍ إضافي. محتويات السكربت يمكنك العثور على السكربت لإعداد الخادم الأولي في مخزن الإعداد التلقائي لمؤسسة DigitalOcean Community GitHub. لنسخ محتويات السكربت أو تنزيلها مباشرةً، انقر فوق الزر (Raw) أعلى النص، أو انقر هنا لعرض المحتويات الأولية مباشرة. لقد أدرجت المحتويات كاملة أيضًا هنا لتسهيل العملية: #!/bin/bash set -euo pipefail ######################## ### SCRIPT VARIABLES ### ######################## # اسم حساب المستخدم العادي الذي ستُنشأ وتمنح له صلاحيات # Name of the user to create and grant sudo privileges USERNAME=sammy # الجديد sudo إلى حساب root من الحساب الجذري SSH تحدّد ما إذا كنت تريد نسخ أصول مفتاح # Whether to copy over the root user's `authorized_keys` file to the new sudo # user. COPY_AUTHORIZED_KEYS_FROM_ROOT=true # sudo مجموعة من السلاسل النصية التي تمثل مفاتيح عامة أخرى تُضاف إلى الحساب # Additional public keys to add to the new sudo user # OTHER_PUBLIC_KEYS_TO_ADD=( # "ssh-rsa AAAAB..." # "ssh-rsa AAAAB..." # ) OTHER_PUBLIC_KEYS_TO_ADD=( ) #################### ### SCRIPT LOGIC ### #################### # ومنحه الصلاحيات sudo إنشاء حساب المستخدم # Add sudo user and grant privileges useradd --create-home --shell "/bin/bash" --groups sudo "${USERNAME}" # تحقق من توفّر الحساب الجذري على كلمة مرور # Check whether the root account has a real password set encrypted_root_pw="$(grep root /etc/shadow | cut --delimiter=: --fields=2)" if [ "${encrypted_root_pw}" != "*" ]; then # تُنقل كلمة المرور الإدارية الأصلية التي وُلِّدت لحساب الجذري إلى الحساب الجديد. حينها تُقفل كلمة المرور للحساب الجذري # Transfer auto-generated root password to user if present # and lock the root account to password-based access echo "${USERNAME}:${encrypted_root_pw}" | chpasswd --encrypted passwd --lock root else # حذف كلمة مرور غير صالحة للمستخدم في حالة استخدام المفاتيح بحيث يمكن تعيين كلمة مرور جديدة دون تقديم قيمة سابقة # Delete invalid password for user if using keys so that a new password # can be set without providing a previous value passwd --delete "${USERNAME}" fi # إنهاء صلاحيات المستخدم العادي لإجباره على تغييرها # Expire the sudo user's password immediately to force a change change --lastday 0 "${USERNAME}" # sudo للمستخدم SSH إنشاء مجلد # Create SSH directory for sudo user home_directory="$(eval echo ~${USERNAME})" mkdir --parents "${home_directory}/.ssh" # نسخ ملف المفاتيح من الحساب الجذري إذا كان ضروريًا # Copy `authorized_keys` file from root if requested if [ "${COPY_AUTHORIZED_KEYS_FROM_ROOT}" = true ]; then cp /root/.ssh/authorized_keys "${home_directory}/.ssh" fi # إضافة المفاتيح الإضافية المتوفرة # Add additional provided public keys for pub_key in "${OTHER_PUBLIC_KEYS_TO_ADD[@]}"; do echo "${pub_key}" >> "${home_directory}/.ssh/authorized_keys" done # SSH ضبط تكوينات ملكية وصلاحيات # Adjust SSH configuration ownership and permissions chmod 0700 "${home_directory}/.ssh" chmod 0600 "${home_directory}/.ssh/authorized_keys" chown --recursive "${USERNAME}":"${USERNAME}" "${home_directory}/.ssh" # إيقاف تسجيل الدخول للحساب الجذري باستعمال كلمة المرور # Disable root SSH login with password sed --in-place 's/^PermitRootLogin.*/PermitRootLogin prohibit-password/g' /etc/ssh/sshd_config if sshd -t -q; then systemctl restart sshd fi # SSH بعد إضافة استثناءات UFW تفعيل جدار الحماية # Add exception for SSH and then enable UFW firewall ufw allow OpenSSH ufw --force enable خاتمة يمكن أن يوفر لك إعداد الخادم الأولي تلقائيًا بعض الوقت ويمنحك أساسًا جيدًا لمزيد من الإعداد. إذا كانت هناك خطوات إضافية ترغب في اتخاذها، فيمكنك إما تسجيل الدخول بعد تشغيل السكربت للمتابعة يدويًا، أو إضافة الخطوات في نهاية السكربت لأتمتة العملية. ترجمة -وبتصرف- للمقال Automating Initial Server Setup with Ubuntu 18.04 لصاحبه Justin Ellingwood
  10. لا يدرك معظم الناس1 تمامًا مقدار المتعة التي في الأمان، أو بالضبط كيف تجعلك الخبرة الأمنية مثيرًا بالنسبة للأشخاص الآخرين2. نحن نعلم أنها شيقة وجذابة وممتعة، لكنهم لا يعلمون ذلك. لهذا السبب، عندما يتوجه مسؤولو الأمن إلى الأشخاص الآخرين (دعنا نسميهم "أشخاصًا عاديين" لأغراض هذه المقالة)، ويقولون لهم إنهم يفعلون شيئًا خاطئًا، ولا يمكنهم إطلاق منتجهم، أو نشر طلباتهم، أو أنه يجب عليهم التوقف عن استلام طلبات المبيعات على الفور وربما خلال اليومين المقبلين حتى يتم إصلاح ذلك، عندها قد لا يتفاعل هؤلاء الأشخاص العاديون دائمًا بمستوى الامتنان الذي نعتقد أنّه مناسب. في بعض الأحيان، في الواقع، سيعرضون ردودًا سلبية، قد تكون حتى شخصية، على هذه الاقتراحات. تكمن المشكلة في أنّ أفراد الأمن يعرفون كيف ينبغي أن تكون الأمور، و هذا آمن. لقد تلقوا التدريب وحضروا الدورات وقرأوا المقالات وتصفحوا الكتب الأمنية الضخمة3، وكل هذه المصادر تؤكّد بوضوح تامٍّ: يجب أن يكون كل شيء آمنًا. تعني كلمة "آمن" عمومًا "مغلقًا"، خاصة إذا كان أفراد الأمن لم يشاركوا بشكل كاف في إجراءات التصميم والتنفيذ والعمليات. يريد الناس العاديون، من ناحية أخرى، فقط أن تعمل الأشياء. هناك انفصال جوهري بين وجهتي النظر هاتين لأننا لن نستطيع الإصلاح إلا إذا كان الأمن هو المطلب الأساسي لأي مشروع من بدايته وحتى نهايته4. ليس الأشخاص العاديون الآن أغبياء. إنهم يعلمون أن الأمور لا تعمل دائمًا بشكل مثالي؛ لكنهم يرغبون في عملها أكبر قدر ممكن. وهذه هي الفجوة التي نحتاج إلى تخطيها. لقد تحدثت من قبل عن التدهور المُتحكّم فيه كمفهوم، وهذا جزء من القصة. أحد الأشياء التي ينبغي لأفراد الأمن أن يكونوا مستعدين للقيام بها هو توضيح أن هناك مخاطر يمكن التخفيف منها. بالنسبة لأفراد الأمن، يجب التخفيف من هذه المخاطر من خلال "الإغلاق". إنّه من السهل إيقاف الخطر إذ يمكنك فقط إيقاف تشغيل النظام، ولن يوجد خطر من إساءة استخدامه. ولكن بالنسبة للعديد من الأشخاص، هناك مخاطر أخرى: مثال على ذلك أن المؤسسة قد تتوقف في الواقع عن العمل تمامًا لأن بعض أفراد الأمن قد أغلقوا نظام الطلبات. إذا كانوا قد عرضوا عليّ خيار الموازنة بين مخاطرة التوقف عن تلقي الطلبات مقابل مخاطرة فقدان بعض بيانات الشركة الداخلية، فهل كنت سأقوم بالمخاطرة الأولى؟ حسنا نعم، قد أقدم عليها. ولكن إذا لم يُقدّم لي الاختيار، ولم تُوضّح لي المخاطرة، فلن يكون لدي خيار. هذا هو نوع الكلمات التي أودّ سماعها إذا كنت أدير أعمالًا. ليس هذا فقط هو نوع المخاطر الممكنة. فأن تأتي مثلًا إلى اجتماعِ المشروع قبل أسبوعين من إطلاقه وتعلن أنه لا يمكن نشر المشروع "لأن المحادثات على واجهة برمجة التطبيقات هذه تتم دون تصديق على الهوية" ليس أمرًا جيّدًا على الإطلاق لأي أحد. باعتباري مطوّرًا، فلديّ على أيّة حال مفردات مختلفة وهواجس مختلفة عن تلك الخاصة بمالك العمل. ماذا لو أنه بدلًا من العبارة التالية: "تحتاج إلى استخدام التّصديق على الهوية على واجهة برمجة التطبيقات هذه وإلّا لن تستطيع المتابعة"، يطرح مسؤول الأمان السؤال كالتالي: "ماذا سيحدث إذا كانت البيانات التي تُقدّم على واجهة برمجة التطبيقات هذه غير صحيحة، أو يقدّمها شخص ينوي تعطيل عمل النظام؟" وفقًا لتجربتي ، يهتمّ معظم المطورين ويلتزمون بالتشغيل الصحيح للنظام الذي يعملون عليه والبيانات التي يعالجها. في الغالب، تثير الأسئلة التي تُظهر التأثير المحتمل لانعدام الأمن ردود فعل إيجابية أكثر من "مناقشة" بدائية تنتهي أساسًا بالرفض. لا تفهمني خطأً؛ إن هناك أوقاتًا نحتاج فيها، كأفراد أمن، لأن نكون حازمين ومتشبثين بأسلحتنا5. ولكن في النهاية، فإن مالكي الأنظمة أو المنظمات أو وحدات الأعمال أو الموارد هم الذين يتخذون القرار النهائي. إن مهمتنا هي التحدث إليهم بكلمات يمكنهم فهمها والتأكد من أنهم مطلعون جيدًا قدر الإمكان و نتفادى أن يكون جوابهم مجرد "لا". أعني بذلك "أولئك المساكين الذين لا يقرؤون هذه المنشورات، على عكسك، عزيزي القارئ الذكي". يبدو أن زوجتي، للأسف، تندرج في هذه الفئة. الكتب التي عادة ما يكون على غلافها صورة قفلٍ. ونتمنى لك التوفيق في ذلك. مجازًا فقط، فأنا لا أقبل نقل أي أسلحة إلى مكان العمل بما في ذلك الأسلحة النارية. ترجمة وبتصرف للمقال Talking to normal people about security لمايك بورسيل
  11. في خضم السباق المحموم نحو الرقمنة، أصبحت فرق التطوير تمثّل العمود الفقري للعديد من المؤسّسات. لقد أصبح يتعين على أفرادها إلى جانب فرق العمليات القيام بمهمّات أكثر من أي وقت مضى. غالبًا ما تقود هذه الفرق الابتكار والتغيير في نفس الوقت الذي تحافظ فيه على النظام القديم وتضمن أداء المنتجات أو الخدمات باستمرار. إن المؤسّسات التي تسمح لفرق التطوير والعمليات لديها بالمرونة والسرعة في التحرك واستثمار الفرص تكون في الغالب مؤسّسات ناجحة، وهذا ما يجعل العديد من المنظمات تعطي الأولوية لبناء وتعزيز ثقافة DevOps. تجمع ثقافة DevOps بين فريق التطوير (DEVelopment) وفريق العمليات (OPerationS) في هيكل واحد سعياً لإنشاء البرامج بسرعة و بأقل نسبة من الأخطاء. إن ثقافة DevOps هي تحوّل كبير من الثقافة التقليدية لتكنولوجيا المعلومات؛ فبدلاً من أن يعمل فريقا التطوير والعمليات بشكل منفصل، تسهّل ثقافة DevOps التواصل بينهما من خلال جعلهما يعملان على أهداف مشتركة. ويتطلب الأمر أن يفهم كل منهما الأهداف ويتمكّنا من العمل سويًا لإنجاح الأعمال. يمكن أن تساهم الثقافة السليمة لدى فريق DevOps في عوائد ضخمة للمؤسسة. أفادت دراسة شملت 4600 فريق لتكنولوجيا المعلومات أن أولئك الذين يتبنون ثقافة DevOps نشروا برامج أكثر مائتي مرة من الفرق ذات الأداء المنخفض. لقد أمضوا نصف الوقت اللازم فقط لإصلاح مشكلات الأمان، وحققوا زمن استردادٍ أقلّ لبرامجهم ، وكان معدل فشل التغيير لديهم أقلّ ثلاث مرات. وبالتالي، يمكن لجميع المنظمات تقريبًا أن تجد بعض المزايا في تبني ثقافة DevOps، ولكن ماهي هذه الثقافة؟ وما هي تجلياتها؟ احرص على قياس أداء فريقك ومساءلته وكن شفافًا إنه من المهمّ للغاية، في كل مرحلة، وضع مؤشرات أداء رئيسية واضحة (KPIs). يجب أن يعرف أعضاء الفريق دائمًا ما هو مُتوقّع منهم وكيف يلائم المشروع الكلي. لا تؤدي هذه الشفافية إلى تحسين التواصل فحسب، بل يمكن أن تفيد أيضًا في مساءلة الفريق. في الماضي، كانت العديد من الشركات تميل إلى عزل العمّال عن الأهداف و التصورات العامّة. ولا تتمّ مشاركة عناصر المشروع إلا على أساس "الحاجة إلى المعرفة". لكن فرق DevOps المميزة تخطت هذا المفهوم بشكل كامل. يجب أن يعلم الجميع كيف تعمل الأنظمة وكيف تتوافق الأشياء معًا. توفر أدوات التعاون مثل Microsoft Azure DevOps Server وبدائل أخرى ذات مصادر مفتوحة للفرق صورة واضحة لمراحل المشروع خلال التخطيط والتطوير والاختبار والنشر. ينبغي أن تتأكد من أن كل عضو في الفريق يفهم الهدف المشترك. كلما زاد فهم أعضاء الفريق لدورهم ومدى ملاءمته للآخرين، زادت كفاءة أدائهم. أنت بهذا تريد أعضاء الفريق أن يعملوا بنوع من المراقبة المتبادلة عبر المجموعات الوظيفية. أتمِت ما تستطيع يتمثل جزء كبير من ثقافة DevOps في التشغيل التلقائي قدر الإمكان وتوحيد منصات الإنتاج. يساعد التقييس والأتمتة في جعل عمليات النشر أكثر قابلية للتنبؤ بها وأقل عرضة للأخطاء البشرية. اعمل على أتمتة أي شيء يمكنك كجزء من سيرورة العمل، بما في ذلك البنية التحتية القابلة للتطوير والالتزام ومسلسل التسليم المستمر. على سبيل المثال، تسمح أدوات مثل Docker لفرق التطوير بأتمتة عمليات نشر التطبيقات بسرعة ملحوظة. من خلال تقليل المهام اليدوية والمتكررة، ستزيد من تطوّرك وسرعة اختبارك مع تقليل الأخطاء بشكل ملموس. بالإضافة إلى ذلك، من خلال التخلص من المهام الشاقة والمتكررة، ستحرّر أيضًا فريقك ليستطيع العمل على مهام رفيعة المستوى وتقلّل من التعب والإرهاق لديه. اخلق ثقافة التعاون يمكن أن يكون اعتماد ثقافة DevOps فرصة لكسر الجدران بين المستوى الإداري ووحدات العمل تمامًا. في بعض الأحيان يكون لفريق التطوير وفريق العمليات أولويات مختلفة، وهذا جيد، لكن يجب أن تعمل الشركات على إنشاء جسر تواصل بينهما. في ثقافات تكنولوجيا المعلومات الأخرى، يُقسّم تطوير البرامج لتحقيق السرعة عن طريق عزل أعضاء الفريق إلى أجزاء من المشاريع. يركز فريق التطوير على البرامج الجديدة والمبتكرة، بينما يعمل فريق العمليات على تخفيف المخاطر والحفاظ على النظام. لكن يمكن أن تخلق هذه الأولويات بعض الصدامات. تعمل ثقافة DevOps على مدّ الجسور بين هذه الأولويات عبر التواصل المبكر والمستمر. من خلال الجمع بين الفرق من بداية تطوير البرنامج، يمكنهم تحديد المخاطر والأخطاء والأعطاب قبل إرسال البرنامج إلى فرق العمليات. لن تنتظر الفرق حتى النهاية لتجتمع معًا ثم تُحدّد المشكلات التي كان يمكن حلها في وقت مبكر من دورة التطوير. تعني هذه المقاربة التشاركية أنه يمكن تطوير البرنامج بشكل أسرع مع وجود نسبة أقل من الأخطاء. بالإضافة إلى التحول الثقافي، ستحتاج الفرق إلى أدوات تطوير DevOps جديدة، مثل سجلات JFrog و Go ، والتي تتيح التقسيم والتعاون. إذ توفّر أدوات مثل هذه رؤية أوضح فضلا عن التواصل بين أعضاء الفريق. يخلق وجود مهام العمليات والتطوير عند نفس الفريق التعاون بين أفراده. بالإضافة إلى تعزيز الشعور الإيجابي بالفريق وأهميته، يمكن لثقافة DevOps أيضًا مساعدة أعضاء الفريق على تنمية مهاراتهم على المستوى الفردي أو إظهار مواهب أخرى. من خلال الجمع بين التطوير والعمليات، يكون قادة الفريق قادرين على تحديد طريقة تفكير الناس خارج مجال خبرتهم المحددة. يمكن أن يساعد تحدي أعضاء الفريق في التفكير فيما وراء أهدافهم ومعالجة المشكلات بشكل تعاوني الأفراد على إضافة مهارات أو رؤى إضافية إلى العملية الإجمالية. وقد يساعد هذا القادة في العثور على أعضاء الفريق اليوم الذين يستطيعون أن يصبحوا قادة فرق الغد. ضع أهدافاً واقعية وشفافة لا يوجد شيء أكثر إحباطًا لفرق DevOps من الأهداف غير الواقعية. إذا شعروا أن ما يطلب منهم القيام به أمر مستحيل، فمن المحتمل ألا يقدموا لك قصارى جهدهم. ومن خلال زيادة التواصل والرؤية بين الفرق، سيتمكن المديرون من وضع أهداف واقعية يمكن تحقيقها بشكل معقول. علاوة على ذلك، يفهم أفراد DevOps أيضًا بالعمل معًا جنبًا إلى جنب أداء الفريق بأكمله. عندها يكونون قادرين على معرفة أين تتأخر المشروعات أو ما إذا كانت تتقدم بشكل صحيح في إطار المسلسل برمّته. إن التخلي عن فكرة الفرق المنفصلة يمكّن الأفراد من التدخل والمساعدة عندما تكون أي لبنة رئيسية في خطر. من خلال رؤية العملية بكاملها، يكون حماسهم والتزامهم بالمشروع أكبر وتكون قدرتهم على إحداث تغيير إيجابي عند الحاجة وضمان تسليم المزيد من المشاريع في الوقت المحدد أعلى. هيّئ بيئة مشتركة للتعلّم والتحسين المستمر تتّسم أفضل فرق DevOps بالمرونة وتبحث باستمرار عن طرق للتحسّن. ويتجلى جزء مهمّ من التحسين المستمر في تكوين حلقات رسمية وغير رسمية للتواصل. يكتسي هذا الأخذ والعطاء أهمية بالغة بين الفرق والفروع المتخصّصة. فبالتواصل المنتظم بين وحدات الإنتاج والتطوير والتصميم والإدارة، يمكنك تقليل الوقت اللازم للتطوير. كما أن هذا يُمكّن كلّ فرد في فريق DevOps من التعرف على دوره في المنتج الإجمالي. يحب الناس أن يكونوا جزءًا من الفرق الناجحة التي تحقّق أهدافها وتتجاوزها باستمرار. إن النجاح يولد النجاح. وفي الوقت نفسه، من الأرجح أن يغادر أعضاء الفريق الذين لا يشعرون بالتحدي في عملهم أو الحصول على تقدير لمساهمتهم. لثقافة DevOps مزايا متنوعة ختامًا، تعدّ الفرق السريعة والمرنة والمبتكرة حيوية لنجاح الأعمال، ويمكن لثقافة DevOps أن تساعد في دفعها قُدماً نحو الأمام. فهي توفر تواصلًا أقوى، وترسم أهدافًا موحدة وشفافة، وتضع جداول زمنية واقعية. من خلال تشجيع الأتمتة وتوحيد العمليات، تُتيح DevOps أيضًا إنتاج برامج أسرع بأخطاء أقلّ. كما أنها تساهم في إيجاد أعضاء فريق سعداء ومتمكّنين يستطيعون المساهمة بأساليب جديدة. ربّما يكون اعتماد ثقافة DevOps هو الميزة التنافسية التي تحتاج إليها مؤسستك. ترجمة -وبتصرف- للمقال Why every dev team should adopt a DevOps culture in 2019 لصاحبه Matt Shealy
  12. تعرف على devopssec

    إن مفهوم DevSecOps كممارسة أو كشكل من أشكال الفن هو تطوير لمفهوم DevOps. لكي تفهم DevSecOps بشكل أفضل، ينبغي أولاً أن يكون لديك فهم كافٍ لما تعنيه DevOps، لذا ننصحك بالاطلاع على مقالات هذه السلسلة إن لم يكن لديك معرفة بماهية DevOps. وُلِدت ثقافة DevOps من دمج ممارسات التطوير (Development) والعمليات (Operations) وفك العزلة بينهما وتوحيد التركيز وتحسين الكفاءة والأداء لكلا الفريقين وللمنتج كذلك. لقد تشكّل مفهوم جديد للتعاون مع تركيز DevOps على صنع منتجات وخدمات تسهُل صيانتها وتعمل على أتمتة الوظائف العملية. إنّ الأمن حصن رئيسيّ مشترك لدى العديد من المؤسّسات. ويركّز المفهوم الأمنيّ على حماية المؤسسة، وهذا يعني أحيانًا إنشاء حواجز أو سياسات تبطئ من تنفيذ خدمات أو منتجات جديدة لضمان فهم كل شيء جيدًا وتنفيذه بأمان وعدم ظهور أي خطر على المؤسسة هي في غنى عنه. بالنظر إلى الطابع الاستثنائي للحصن الأمنيّ وإلى الاحتكاكات التي يمكن أن يظهرها، يعمل أفراد التطوير والعمليات أحيانًا في التفافٍ على الحصن الأمنيّ متجنّبين إياه من أجل تحقيق أهدافهم. في بعض الشركات، يخلق الحصن اعتقادًا بأن الأمن هو مسؤولية كاملة لفريق الأمن وأن الأمر متروك له لمعرفة ما هي العيوب أو المشكلات الأمنية التي يمكن ظهورها كنتيجة للمنتج. جاء مفهوم DevSecOps ليعمل على دمج نظام الأمان داخل منظومة DevOps. من خلال تعزيز الأمن أو بناءه في الدور التطويري أو العملياتي، أو من خلال تضمين الدور الأمني في مهامّ الفريق الهندسي، يجد الأمان نفسه في المنتج بشكل طبيعي ومقصود. يتيح ذلك للشركات إصدار منتجات وتحديثات جديدة بسرعة أكبر وبثقةٍ تامةٍ أنّ الأمان مضمّن كفايةً في المنتج. كيف تنسجم البرامج المتينة مع DevSecOps؟ يعدّ إنشاء البرامج المتينة (rugged software) جانبًا من جوانب ثقافة DevOps أكثر من كونه ممارسة منفصلة، وهو يكمّل ويعزز ممارسة DevSecOps. إن المنتج المتين مثله مثل شيء تصلّب و قَوِيَ عودُهُ من خلال التجارب و الخبرات. من المهم أن نلاحظ أن البرامج المتينة ليست بالضرورة آمنة بنسبة 100 ٪ (على الرغم من أنها قد تكون كذلك في وقت ما). ومع ذلك، فقد صُمّمت للتعامل مع مُعظم ما يمكن أن تواجهه. تتمثل المبادئ الأساسية لنشاط البرامج المتينة في تعزيز المنافسة والتجريب والفشل المتحكم فيه والتعاون. كيف تبدأ في DevSecOps؟ يتضمن الانطلاق في منظومة DevSecOps نقل متطلبات الأمان والتنفيذ إلى أقرب مرحلة ممكنة في عملية التطوير. إنّه يخلق في نهاية المطاف تحولًا في الثقافة يصبح معه الأمن مسؤولية الجميع، وليس فقط فريق الأمن. ربّما تكون قد سمعت بعض الفرق تتحدث عن "التحرّك نحو اليسار" (shift left). إذا بسطت مسلسل التطوير في خط أفقي لتضمين المراحل الرئيسية لتطور المنتج، من المرحلة البدئية إلى التصميم والبناء والاختبار وحتى التشغيل، فإن هدف الدور الأمني هو الاندماج في أقرب مرحلة ممكنة من هذه السلسلة. يسمح ذلك بتقييم المخاطر بشكل أفضل وتلطيفها وتخفيفها بشكل طبيعي. يعمل مفهوم "التحرّك نحو اليسار" على نقل هذه المشاركة إلى أقصى اليسار في هذا الخطّ الأفقي. تبدأ هذه الرحلة بثلاثة عناصر أساسية: التفويض التمكين التعليم يعني التفويض، في رأيي، تخفيف السيطرة والسماح للفرق باتخاذ قرارات مستقلة دون خوف من الفشل أو الارتداد. لكن التحذير الوحيد هنا هو أن المعلومات في غاية الأهمية لاتخاذ قرارات مستنيرة. من أجل تحقيق التفويض، يعتبر دعم الاستثمار والتنفيذ والذي يمكن القيام به من خلال المبيعات الداخلية والعروض التقديمية ووضع مقاييس لتحديد عوائد هذا الاستثمار أمرًا ضروريًا لكسر الحواجز القديمة وفكّ العزلة بين الفرق. سيساعدك بالتأكيد دمج الأمان في مهام فرق التطوير والعمليات وزيادة التواصل والشفافية في بدء الرحلة إلى DevSecOps. يسمح هذا التكامل والتعبئة للفرق بالتركيز على نتيجة واحدة تتجلى في بناء منتج تتشارك فيه المسؤولية وتتعاون على تطويره وأمانه بطريقة فعالة وموثوقة. سيأخذك هذا بعيدا في الطريق نحو تحقيق التفويض. إنه يجعل المسؤولية عن المنتج مشتركة بين الفرق التي تعمل على إنشائه ويضمن إمكانية فصل أي جزء من المنتج والحفاظ على أمانه. يتجلى التمكين في وضع الأدوات والموارد المناسبة في أيدي الفرق. يتعلق الأمر بخلق ثقافة مشاركة المعرفة من خلال المنتديات والتجمعات غير الرسمية. من المرجّح أن يساهم إنشاء ثقافةٍ تركز على الأتمتة وعلى وجوب ترميز المهام المتكررة إلى تخفيف العبء التشغيلي وتعزيز الأمان. يتجاوز هذا السيناريو مجرد توفير المعرفة بل يتعلق الأمر بإتاحة الوصول إلى هذه المعرفة بشكل كبير من خلال قنوات ووسائل متعددة توفرها العديد من الأدوات بما يتيح استخدامها ومشاركتها بأي طريقة تفضلها الفرق أو الأفراد. قد تعمل إحدى الوسائط بشكل أفضل في مرحلة كتابة الشيفرة بينما يكون غيرها مناسبًا في مراحل أخرى. اجعل الأدوات بسيطة وسهلة الوصول ودع الفريق يستخدمها بفعالية. سيكون لفرق DevSecOp المختلفة تفضيلات مختلفة، لذلك اسمح لهم بالاستقلال كلما أمكن ذلك. يعدّ هذا تمرينًا دقيقًا للتوازن لأنك تريد في الوقت ذاته وفرة في الإنتاج وقدرة على مشاركة المنتجات. سيساعد التعاون والمشاركة في اختيار وتجديد هذه الأدوات على تقليل الحواجز بين الفرق. أخيرًا، يدور مفهوم DevSecOps حول التدريب وبناء الوعي، و هذا ربّما هو الأمر الأهمّ في كل ما قلناه. تعد الاجتماعات واللقاءات الاجتماعية و العروض التقديمية الرسمية داخل المؤسسة طرقًا رائعة للأفراد لتلقين ومشاركة ما تعلّموه. في بعض الأحيان تبرز هذه التحديات أو المخاوف أو المخاطر المشتركة التي قد لا يلاحظها الآخرون. إن المشاركة والتدريب وسيلتان فعالتان للتعلّم ولإرشاد الفرق. وفقًا لتجربتي، تظلّ ثقافة كل مؤسسة فريدة من نوعها، لذلك لا يمكنك اتباع النهج القائل "مقاس واحد يناسب الجميع". تواصل مع فرقك واكتشف الأدوات التي يريدون استخدامها. اختبر مختلف المنتديات والتجمعات واعرف ما هو أفضل لثقافتك. ابحث عن التعليقات واسأل الفرق عمّا ينجح وعمّا يعجبهم ولماذا. تكيّف وتعلّم وكن إيجابيًا ولا تتوقف أبدًا عن المحاولة، وعلى الأغلب سوف يحالفك النجاح دائمًا. ترجمة وبتصرف للمقال ?What is DevSecOps لبريت هونولدت و آرون رينهارت