اقتباس

ستحقق DevOps بالتأكيد التغيير لمؤسستك، ولن يحب الجميع هذا التغيير. إليك كيف تتعامل مع أولئك الذين يقاومون هذا التحوّل المحتوم.

أنت تعمل على الانتقال إلى منظومة DevOps وتطبيقها في مؤسستك بالكامل أو في جزءٍ منها فقط: حسنًا! ها قد حقّق شخص ما في مكان ما قفزة نوعية. لنفترض، لأغراض هذا المقال، أن لديك موافقة من الإدارة: مهما كانت العقبات التي ينبغي عليك تجاوزها وكيفما كانت الجبال التي تحتاج لتسلقها للحصول على ذلك الجواب بـ "نعم". لقد حصلت على موافقة على الأدوات ووضعت كل الإجراءات والعمليات على الطاولة، والآن كل ما عليك القيام به هو إقناع الناس بالاندماج في المنظومة. يجب أن يكون هذا الأمر سهلا، أليس كذلك؟ نتمنى لو يكون كذلك.

يتضح أنه ليس كل الناس مستنيرين مثلك أنت قارئ هذا المقال. لا يحب الناس كلّهم التغيير، وإذا كان هناك شيء واحد يمكنك التأكد منه، فهو هذا الأمرُ. ستحقق منظومة DevOps التغيير لمؤسستك: كيف عليك أن تعمل؟ وماذا تفعل؟ وكيف تتفاعل مع الأشخاص الآخرين داخل الفريق وخارجه؟

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

هذا لم يُخترَع من أجلنا: الخوف من المجهول

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

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

مجالي: الخوف من فقدان السيطرة

هذا نوع من الأشخاص أعرفه تمامًا على المستوى الشخصي بحكم خلفيتي الأمنية. غالبًا ما يشعر الأشخاص الذين حصلوا على مستوى عالٍ من الخبرة في ميدان أو مجال معين بالتهديد عندما يُطلب منهم تغيير طريقة عملِهم أو تطبيقِ معارفهم. سيشعرون غالبًا بأنهم مطالبون بالتخلي عن السيطرة و بـ "تخفيف" خبراتهم في عالم جديد فيه "كلّ شخص هو الخبير".

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

متشبث بأسلوبي: الخوف من الجديد

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

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

مدراء الأفراد: الخوف من فقدان السلطة

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

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

النقابات: الخوف من عدم اليقين

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

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

أفكار ختامية

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

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

ترجمة وبتصرف للمقال Who will push back the most on a move to DevOps?‎ لمايك بورسيل

اقتباس

يرغب الناس العاديون عموما أن تعمل الأشياء لا أكثر.

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

في بعض الأحيان، في الواقع، سيعرضون ردودًا سلبية، قد تكون حتى شخصية، على هذه الاقتراحات.

تكمن المشكلة في أنّ أفراد الأمن يعرفون كيف ينبغي أن تكون الأمور، و هذا آمن. لقد تلقوا التدريب وحضروا الدورات وقرأوا المقالات وتصفحوا الكتب الأمنية الضخمة³، وكل هذه المصادر تؤكّد بوضوح تامٍّ: يجب أن يكون كل شيء آمنًا. تعني كلمة "آمن" عمومًا "مغلقًا"، خاصة إذا كان أفراد الأمن لم يشاركوا بشكل كاف في إجراءات التصميم والتنفيذ والعمليات. يريد الناس العاديون، من ناحية أخرى، فقط أن تعمل الأشياء. هناك انفصال جوهري بين وجهتي النظر هاتين لأننا لن نستطيع الإصلاح إلا إذا كان الأمن هو المطلب الأساسي لأي مشروع من بدايته وحتى نهايته⁴.

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

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

ليس هذا فقط هو نوع المخاطر الممكنة. فأن تأتي مثلًا إلى اجتماعِ المشروع قبل أسبوعين من إطلاقه وتعلن أنه لا يمكن نشر المشروع "لأن المحادثات على واجهة برمجة التطبيقات هذه تتم دون تصديق على الهوية" ليس أمرًا جيّدًا على الإطلاق لأي أحد.

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

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

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

إن مهمتنا هي التحدث إليهم بكلمات يمكنهم فهمها والتأكد من أنهم مطلعون جيدًا قدر الإمكان و نتفادى أن يكون جوابهم مجرد "لا".

1. أعني بذلك "أولئك المساكين الذين لا يقرؤون هذه المنشورات، على عكسك، عزيزي القارئ الذكي".
2. يبدو أن زوجتي، للأسف، تندرج في هذه الفئة.
3. الكتب التي عادة ما يكون على غلافها صورة قفلٍ.
4. ونتمنى لك التوفيق في ذلك.
5. مجازًا فقط، فأنا لا أقبل نقل أي أسلحة إلى مكان العمل بما في ذلك الأسلحة النارية.

ترجمة وبتصرف للمقال Talking to normal people about security لمايك بورسيل

اقتباس

ربّما يكون اعتماد ثقافة DevOps هو الميزة التنافسية التي تحتاج إليها مؤسستك

في خضم السباق المحموم نحو الرقمنة، أصبحت فرق التطوير تمثّل العمود الفقري للعديد من المؤسّسات. لقد أصبح يتعين على أفرادها إلى جانب فرق العمليات القيام بمهمّات أكثر من أي وقت مضى. غالبًا ما تقود هذه الفرق الابتكار والتغيير في نفس الوقت الذي تحافظ فيه على النظام القديم وتضمن أداء المنتجات أو الخدمات باستمرار. إن المؤسّسات التي تسمح لفرق التطوير والعمليات لديها بالمرونة والسرعة في التحرك واستثمار الفرص تكون في الغالب مؤسّسات ناجحة، وهذا ما يجعل العديد من المنظمات تعطي الأولوية لبناء وتعزيز ثقافة 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

اقتباس

تبدأ رحلة الغوص في مجال ال DevSecOps (اختصارٌ للعبارة Development Security Operations التي يُقصد بها إدماج الممارسات الأمنية في صلب عمل فريقي التطوير والعمليات) بالتفويض والتمكين والتعليم. إليك كيف تستطيع الانطلاق فيها.

إن مفهوم DevSecOps كممارسة أو كشكل من أشكال الفن هو تطوير لمفهوم DevOps. لكي تفهم DevSecOps بشكل أفضل، ينبغي أولاً أن يكون لديك فهم كافٍ لما تعنيه DevOps، لذا ننصحك بالاطلاع على مقالات هذه السلسلة إن لم يكن لديك معرفة بماهية DevOps.

وُلِدت ثقافة DevOps من دمج ممارسات التطوير (Development) والعمليات (Operations) وفك العزلة بينهما وتوحيد التركيز وتحسين الكفاءة والأداء لكلا الفريقين وللمنتج كذلك. لقد تشكّل مفهوم جديد للتعاون مع تركيز DevOps على صنع منتجات وخدمات تسهُل صيانتها وتعمل على أتمتة الوظائف العملية.

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

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

جاء مفهوم DevSecOps ليعمل على دمج نظام الأمان داخل منظومة DevOps. من خلال تعزيز الأمن أو بناءه في الدور التطويري أو العملياتي، أو من خلال تضمين الدور الأمني في مهامّ الفريق الهندسي، يجد الأمان نفسه في المنتج بشكل طبيعي ومقصود.

يتيح ذلك للشركات إصدار منتجات وتحديثات جديدة بسرعة أكبر وبثقةٍ تامةٍ أنّ الأمان مضمّن كفايةً في المنتج.

كيف تنسجم البرامج المتينة مع DevSecOps؟

يعدّ إنشاء البرامج المتينة (rugged software) جانبًا من جوانب ثقافة DevOps أكثر من كونه ممارسة منفصلة، وهو يكمّل ويعزز ممارسة DevSecOps. إن المنتج المتين مثله مثل شيء تصلّب و قَوِيَ عودُهُ من خلال التجارب و الخبرات.

من المهم أن نلاحظ أن البرامج المتينة ليست بالضرورة آمنة بنسبة 100 ٪ (على الرغم من أنها قد تكون كذلك في وقت ما). ومع ذلك، فقد صُمّمت للتعامل مع مُعظم ما يمكن أن تواجهه.

تتمثل المبادئ الأساسية لنشاط البرامج المتينة في تعزيز المنافسة والتجريب والفشل المتحكم فيه والتعاون.

اقتباس

يقول ستيفان سترايشسبير: تتيح DevSecOps للمؤسسات تقديم برامج آمنة بطبيعتها بسرعةِ DevOps.

كيف تبدأ في DevSecOps؟

يتضمن الانطلاق في منظومة DevSecOps نقل متطلبات الأمان والتنفيذ إلى أقرب مرحلة ممكنة في عملية التطوير. إنّه يخلق في نهاية المطاف تحولًا في الثقافة يصبح معه الأمن مسؤولية الجميع، وليس فقط فريق الأمن.

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

تبدأ هذه الرحلة بثلاثة عناصر أساسية:

• التفويض
• التمكين
• التعليم

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

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

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

يتجلى التمكين في وضع الأدوات والموارد المناسبة في أيدي الفرق. يتعلق الأمر بخلق ثقافة مشاركة المعرفة من خلال المنتديات والتجمعات غير الرسمية.

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

سيكون لفرق DevSecOp المختلفة تفضيلات مختلفة، لذلك اسمح لهم بالاستقلال كلما أمكن ذلك. يعدّ هذا تمرينًا دقيقًا للتوازن لأنك تريد في الوقت ذاته وفرة في الإنتاج وقدرة على مشاركة المنتجات. سيساعد التعاون والمشاركة في اختيار وتجديد هذه الأدوات على تقليل الحواجز بين الفرق.

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

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

ترجمة وبتصرف للمقال ?What is DevSecOps لبريت هونولدت و آرون رينهارت

Cachet عبارة عن صفحة حالة (Status Page) ذاتية الاستضافة كبديل للخدمات المستضافة مثل StatusPage.io و Status.io. تُساعد على توفير معلومات حول وقت تشغيل (uptime) ووقت توقف (downtime) التطبيق الخاص بك ومشاركة المعلومات حول أي انقطاع. خير مثال عن ذلك هو صفحة حالة خدمات ومنتجات حسوب التي توضح ببساطة حالة جميع المواقع التابعة لها.

وقد تمت برمجتُها بلغة PHP، لذا إن سبق لك تثبيت حزمة LAMP أو LEMP، فإنها سهلة التثبيت. تتميّز بواجهة نظيفة ومستجيبة ما يمكّن من تشغيلها على جميع اﻷجهزة. في هذا الدرس، سنقوم بضبط صفحة حالة بواسطة Cachet على Debian.

مجموعة البرامج التي سنستعملها هي كالتالي: -Cachet من أجل صفحة الحالة نفسها. -Composer لإدارة اعتماديات PHP الخاصة بـCachet -SQLite كقاعدة بيانات لتخزين بيانات Cachet -Nginx لتقديم صفحة الحالة

لاحظ أن Cachet لا تراقب المواقع والخوادم لوقت التوقف (downtime)، إذ تسجل اﻷحداث فقط، والتي يمكن تحديثها يدويا أو عن طريق الواجهة البرمجية الخاصة بـ Cachet. إذا كنت تبحث عن حلول لمراقبة تطبيقات الويب، تفقد هذا الدرس.

المتطلبات

تحتاج إلى ما يلي لمُتابعة هذا الدرس:

• خادوم Debian 8 معد عن طريق اتباع هذا الدّرس، مع مستخدم إداري بامتيازات sudo غير المستخدم الجذر. تعمل Cachet بـ 512MB من الذاكرة العشوائية، ويفضل 1GB أو اكثر من أجل أداء أفضل.
• اسم نطاق مؤهل بشكل كامل (FQDN) مع سجل A يوجه نطاقك نحو عنوان IPv4 خادومك. يمكن شراؤه على Namecheap أو الحصول عليه مجانا على Freenom، يمكنك اتباع درس اسم الاستضافة hostname هذا لتفاصيل إعداد سجلات DNS.
• Nginx مُنصّب ومُعدّ بواسطة Let's Encrypt. يمكن تثبيته عن طريق اتباع هذا الدرس بعدها أعدَّ Let's Encrypt باتباع الخطوتين اﻷوليين من هذا الدرس الخطوات المتبقية يمكن تجاوزها ﻷننا سنقوم بإنشاء ملف إعدادات Cachet خاص بنا.
• Composer مثبت باتباع الخطوات 1 و 2 من هذا الدرس.
• Git منصّب باتباع الخطوة الأولى من هذا الدّرس لسحب الشيفرة المصدرية الخاصة بـCachet من موقع GitHub.
• خادوم SMTP، لتتمكن Cachet من إرسال رسائل بريد إلكتروني حول الوقائع إلى المشتركين ومذكِّرات كلمة المرور إلى المستخدمين المنشئين في واجهة Cachet. يمكن استخدام Postfix كخادوم SMTP للإرسال فقط (Send-Only) بُمساعدة درس كيفية تثبيت وتهيئة Postfix كخادوم SMTP للإرسال فقط باستخدام أوبونتو 14.04. أو يمكن استخدام مزود طرف ثالث مثل Mailgun.

الخطوة اﻷولى: إنشاء مستخدم Cachet

أول ما يجب القيام به هو إنشاء حساب مستخدم مستقل لتشغيل Cachet. سيحمل هذا الإجراء حماية وعزلا إضافيين.

sudo useradd --create-home --shell /bin/bash cachet

سينشئ الأمر مستخدمًا باسم cachet مع مجلد المنزل في ‎/home/cachet، والذي ستُضبَط صدفته إلى ‎/bin/bash. الخيار الافتراضي هو ‎/bin/sh، إﻻ أنه لا يوفر ما يكفي من المعلومات في المحث (prompt) الخاص به. سيكون المُستخدم بلا كلمة مرور مع امتيازات حصرية للمكونات التي ستستعملها Cachet.

بعد إنشاء المستخدم لنقم بتثبيت اعتماديات PHP.

الخطوة الثانية: تثبيت اعتماديات PHP

نحتاج إلى تثبيت اعتماديات Cachet، والتي هي عبارة عن عدد من حزم PHP إضافة إلى wget و unzip، والتي يستعملها Composer لتنزيل وفك ضغط مكتبات PHP:

sudo apt-get install \
  php5-fpm php5-curl php5-apcu php5-readline \
  php5-mcrypt php5-apcu php5-cli php5-gd php5-sqlite\
  wget unzip

يمكنك معرفة المزيد حول أي من الحزم من خلال قائمة إضافات PHP الرّسميّة.

لنقم اﻵن بضبط php-fpm، مسيّر عمليات FastCGI. والذي سيستعمله Nginx للتوسّط بين الطّلبات نحو Cachet.

قم أولا بإنشاء الملف الذي سيستضيف المعلومات من أجل Cachet والتي يحتاجها php-fpm. افتح /etc/php5/fpm/pool.d/cachet.conf بالمحرّر nano أو أي محرر آخر:

sudo nano /etc/php5/fpm/pool.d/cachet.conf

قم بلصق التالي:

[cachet]
user = cachet
group = cachet
listen.owner = www-data
listen.group = www-data
listen = /var/run/php5-fpm-cachet.sock
php_admin_value[disable_functions] = exec,passthru,shell_exec,system
php_admin_flag[allow_url_fopen] = off
request_terminate_timeout = 120s
pm = ondemand
pm.max_children = 5
pm.process_idle_timeout = 10s
pm.max_requests = 500
chdir = /

احفظ ثم أغلق الملف. يمكنك قراءة المزيد من المعلومات حول هذه اﻹعدادات في درس كيف تستضيف مجموعة مواقع بشكل آمن باستخدام Nginx و Php-fpm على أوبنتو 14.04 . ولكن إليك ما يقوم به كل سطر في هذا الملف:

• [cachet] هو اسم المُجمِّع (pool). إذ يجب على كل مُجمِّع أن يمتلك اسمًا فريدًا.
• user وgroup هما مستخدم لينكس والمجموعة التي سيشتغل الحوض الجديد تحتها. وهي نفسها ما أعددناه مع المستخدم الذي أنشأناه في الخطوة اﻷولى.
• listen.owner و listen.group تُعرِّف ملكِيّة المُنصت، أي مقبس المُجمِّع php-fpm الجديد. يجب على Nginx من أن يتمكن من قراءة هذا المقبس، ولذلك نستخدم مُستخدم ومجموعة www-data.
• listen يخصّص مسار ملف مقبس فريد لكل مُجمِّع.
• php_admin_value يسمح بضبط قيم إعدادات PHP مخصّصة. نستعمله هنا لتعطيل الدّوال التي يمكنها تشغيل أوامر لينكس (exec,passthru,shell_exec,system).

• php_admin_flag يشبه php_admin_value، إﻻ أنه مجرد مستبدل للقيم المنطقية (boolean switch) أي on و off. سنقوم بتعطيل الدّالة allow_url_fopen التي تمكّن برمجيات PHP من فتح ملفات بعيدة والتي قد تستعمل من طرف مهاجم.

• خيار pm يسمح بضبط أداء الحوض. نقوم بضبطه على ondemand والذي يوفر توازنا لإبقاء مُستويات استعمال الذاكرة منخفضة. إذا كنت تمتلك ذاكرة كبيرة، عندها يمكن ضبطه على القيمة static. إن كنت تمتلك معالجا قويا ذا سلاسل (threads) عديدة، فعندها قد يكون dynamic خيارا أفضل.

• يجب أن تكون قيمة الخيار chdir جذر نظام الملفّات /. ولا يجب تغيير قيمة هذا الخيار إلا إذا كنت تستخدم خيارا مهما آخر (مثل chroot).

أعِد تشغيل php-fpm لتطبيق التغييرات:

sudo systemctl restart php5-fpm

مكّن خدمة php-fpm لكي تشتغل تلقائيا عند إعادة تشغيل الخادوم إن لم تفعل ذلك بعد:

sudo systemctl enable php5-fpm

بعد تثبيت حزم PHP العامة، لنقم بتنزيل Cachet.

الخطوة الثالثة: تنزيل Cachet

الشفرة المصدرية لـCachet مستضافة على GitHub ما يجعلها سهلة التنزيل، والتثبيت، وأيضا -كما سنرى لاحقا- ترقيتها باستخدام Git.

يجب اتباع الخطوات المتبقية بصفة المستخدم cachet، لذلك قم بالانتقال له:

sudo su - cachet

انسخ شفرة Cachet المصدرية إلى مجلد جديد باسم www:

git clone https://github.com/cachethq/Cachet.git www

بعد ذلك، انتقل إلى المجلد الجديد الذي تتواجد به الشفرة المصدرية لـ Cachet:

cd www

ابتداءً من هذه المرحلة، لديك سجل تطور Cachet بأكمله، بما في ذلك فروع و وسوم Git. يمكنك تفقد آخر إصدار مستقر في صفحة إصدارات Cachet، ولكن يمكنك كذلك رؤية وسوم Git في هذا المجلد.

في فترة نشر هذا الدرس، آخر إصدار مستقر ل Cachet هو v2.3.11. استعمل Git للانتقال إلى وسم هذا اﻹصدار:

git checkout v2.3.11

بعد ذلك سنمر إلى التعرف على ملف إعدادات Cachet.

الخطوة الرابعة: إعداد Cachet

تتطلب Cachet ملف إعدادات يسمى env.، والذي يعتبر ضروريا لتشغيل Cachet. يمكنك بداخله ضبط متغيرات البيئة التي تستعملها Cachet لضبطها. لِنقُم بنسخ مثال اﻹعدادات الذي يأتي مع Cachet ونُبْقِ على الأصلي احتياطا:

cp .env.example .env

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

بالنسبة لقاعدة البيانات، سنستعمل SQLite. باعتبارها سهلة الاستخدام ولا تتطلب تثبيت أي مكونات إضافية على خادوم.

لننشئ أولا الملف الفارغ الذي سيستضيف قاعدة البيانات:

touch ./database/database.sqlite

بعد ذلك، افتح الملف env. باستعمال nano أو محرر النصوص المُفضل لديك لضبط إعدادات قاعدة البيانات:

nano .env

ولأننا سنستعمل SQLite، فسنحتاج لحذف كثير من الإعدادات. حدد موقع مقطع الإعدادات الذي يبدأ بالمقطع DB_‎.

جزء من الملف ‎.env الأصلي:

. . .
DB_DRIVER=mysql
DB_HOST=localhost
DB_DATABASE=cachet
DB_USERNAME=homestead
DB_PASSWORD=secret
DB_PORT=null
DB_PREFIX=null
. . .

احذف كل شيء باستثناء السطر DB_DRIVER، وغيّر قيمته من mysql إلى sqlite. بعد تعديل ملف‎.env:

. . .
DB_DRIVER=sqlite
. . .

ملاحظة: يمكنك تفقد خيارات قاعدة بيانات Cachet للحصول على جميع أسماء مُشغّلات قواعد البيانات الممكنة إذا كنت تستعمل قاعدة بيانات أخرى مثل MySQL أو PostgreSQL.

بعدها، تحتاج إلى ملء تفاصيل خادوم SMTP الخاصّ بك في إعدادات MAIL_*‎ المُتعلّقة بضبط البريد الإلكتروني:

. . .
MAIL_HOST=smtp.example.com
MAIL_PORT=25
MAIL_USERNAME=smtp_username
MAIL_PASSWORD=smtp_password
MAIL_ADDRESS=notifications@example.com
MAIL_NAME="Status Page"
. . .

ما يعني:

• MAIL_HOST عنوان URL خادوم البريد اﻹلكتروني الخاصّ بك.
• MAIL_PORT المنفذ الذي ينصت عليه خادوم البريد اﻹلكتروني (عادة 25 ).
• MAIL_USERNAME اسم مستخدم حساب SMTP (عادة ما يكون البريد اﻹلكتروني بأكمله).
• MAIL_PASSWORD كلمة مرور حساب SMTP.
• MAIL_ADDRESS عنوان البريد الإلكتروني الذي سترسل منه التنبيهات للمشتركين.
• MAIL_NAME هو الاسم الذي سيظهر في الرسائل المرسلة إلى المشتركين. انتبه إلى أن أي قيمة بها مسافة يجب أن توضع بين علامتي تنصيص مزدوجتين.

يمكنك الاطلاع على المزيد حول برامج تشغيل بريد Cachet على شيفرة mail.php المصدرية وتوثيق البريد الإلكتروني من Laravel.

بعد الانتهاء من تحرير الملف، احفظه وأغلقه؛ بعد ذلك، تحتاج إلى ضبط قاعدة بيانات Cachet.

الخطوة الخامسة: تهجير قاعدة البيانات

تتم إدارة مكتبات PHP التي تعتمد عليها Cachet باستخدام Composer. أولا، كن متيقنا أنك في المجلد الصحيح:

cd /home/cachet/www

ثم قم بتشغيل Composer وثبّتب جميع المتطلبات باستثناء تلك التي تستعمل لأغراض التطوير. اعتمادا على سرعة الإنترنت لديك، قد يتطلب اﻷمر بعض الوقت:

composer install --no-interaction --no-dev -o --no-scripts

أنشئ مخطط قاعدة البيانات وشغل التهجير:

php artisan migrate

تنبيه: في الإصدار المستقر اﻷخير (2.3.11)، هناك علة عند استخدام SQLite والتي تلزمك بتشغيل أمر التهجير migrate قبل أي شيء آخر.

اكتب yes عندما تُسأل عمّا إذا أردت تنفيذ الأمر بالفعل. سيكون المُخرج مُشابها لما يلي:

**************************************
*     Application In Production!     *
**************************************

 Do you really wish to run this command? (yes/no) [no]:
 > yes

Migration table created successfully.
Migrated: 2015_01_05_201324_CreateComponentGroupsTable
...
Migrated: 2016_06_02_075012_AlterTableMetricsAddOrderColumn
Migrated: 2016_06_05_091615_create_cache_table

اﻷمر التالي php artisan app:install، يأخذ نسخة احتياطية لقاعدة البيانات، يشغل التهجير، ويولد تلقائيا مفتاح التطبيق (أي قيمة APP_KEY في الملفّ .env) والذي تستعمله Cachet لجميع تشفيراتها.

تحذير: لا تغّير أبدا قيمة APP_KEY التي توجد في الملف ‎.env بعد تثبيت وتشغيل Cachet في بيئة الإنتاج، إذ سيؤدي ذلك إلى فقدان كل بياناتك المشفرة. استعمل اﻷمر php artisan app:install مرة واحدة فقط. ولهذا السّبب يُفضّل الإبقاء على نسخة احتياطية من الملفّ ‎.env.

أكمل التثبيت:

php artisan app:install

سيكون المُخرج مُشابها لما يلي:

Clearing settings cache...
Settings cache cleared!
. . .
Clearing cache...
Application cache cleared!
Cache cleared!

كخطوة استباقية أخيرة، فرّغ مخزن Cachet المؤقت لتفادي أخطاء HTTP 500:

rm -rf bootstrap/cache/*

واﻵن بعد تهيئة قاعدة البيانات، يمكننا إعداد طابور مهام Cachet.

الخطوة السادسة: إعداد طابور المهام (Task Queue)

تستعمل Cachet طابورا لجدولة المهام التي تحتاج للعمل بشكل غير متزامن (asynchronously)، مثل إرسال رسائل البريد اﻹلكتروني. الطريقة المقترحة هي استعمال Supervisor، وهو مُسيّر عمليات يوفر واجهة ثابتة يُمكن من خلالها مُراقبة العمليات والتحكم بها.

تأكد أولا من تسجيلك الخروج من جلسة المستخدم cachet وتحوّل إلى مستخدمك ذو صلاحيات sudo غير المُستخدم الجذر:

exit

ثبّت Supervisor:

sudo apt-get install supervisor

ثم أنشئ الملف الذي يحتوي على المعلومات التي يحتاجها Supervisor من Cachet. للقيام بذلك، افتح الملفّ /etc/supervisor/conf.d/cachet.conf:

sudo nano /etc/supervisor/conf.d/cachet.conf

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

أضف المحتوى التالي مع التّأكد من تعديل مجلد Cachet واسم المستخدم إذا استعملت أسماء أخرى (السّطران directory=/home/cachet/www/ و user=cachet):

[program:cachet-queue]
command=php artisan queue:work --daemon --delay=1 --sleep=1 --tries=3
directory=/home/cachet/www/
redirect_stderr=true
autostart=true
autorestart=true
user=cachet

احفظ وأغلق الملف، ثم أعد تشغيل Supervisor:

sudo systemctl restart supervisor

مكن خدمة Supervisor لكي تشتغل تلقائيا عند إعادة تشغيل الخادوم:

sudo systemctl enable supervisor

قاعدة البيانات وطابور المهام جاهزان، المكون التالي الذي يجب ضبطه هو خادوم الويب.

الخطوة السابعة: ضبط Nginx

سنستعمل Nginx على شكل خادوم ويب وسيط سيتواصل مع php-fpm. قسم المتطلبات أعلاه به درس لكيفية إعداد Nginx بشهادة TLS من Let's Encrypt.

لنضف ملف إعدادات Nginx الذي يحتاج إليه Cachet. افتح ملفّ /etc/nginx/sites-available/cachet.conf بمُحرّر النصوص nano أو بأي محرر آخر:

sudo nano /etc/nginx/sites-available/cachet.conf

هذا هو النص الكامل للملف، والذي يجب عليك نسخه ولصقه. مع إبدال example.com باسم النطاق الخاص بك. وظيفة كل قسم موصوفة بشكل مُفصّل أسفله.

server {
    server_name  example.com;
    listen 80;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443;
    server_name  example.com;

    root /home/cachet/www/public;
    index index.php;

    ssl on;
    ## Location of the Let's Encrypt certificates
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ## From https://cipherli.st/
    ## and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
    ssl_ecdh_curve secp384r1;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
    ## Disable preloading HSTS for now.  You can use the commented out header line that includes
    ## the "preload" directive if you understand the implications.
    #add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    ssl_buffer_size 1400;

    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    location / {
        try_files $uri /index.php$is_args$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php5-fpm-cachet.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_index index.php;
        fastcgi_keep_conn on;
    }
}

إليك ما يقوم به كل جزء من هذا الملف.

كتلة server اﻷولى توجه حركة مرور HTTP نحو HTTPS:

server {
    server_name example.com;
    listen 80;
    return 301 https://$server_name$request_uri;
}
. . .

كتلة server الثانية تحتوي على معلومات خاصة حول هذا الضّبط، مثل تفاصيل SSL وإعدادات php-fpm.

تعليمة root تُخبر Nginx عن مكان تواجد مجلد الجذر الخاصّ بـ Cachet. يجب أن تشير القيمة إلى مجلد public، وبما أننا نسخنا Cachet إلى /home/cachet/www/ فسيُصبح السّطر root /home/cachet/www/public;‎.

. . .
server {
    listen 443;
    server_name  example.com;

    root /home/cachet/www/public;
    index index.php;
    . . .
}

شهادات SSL تتواجد داخل مجلد Let's Encrypt، والتي يجب أن تُسمى انطلاقا من اسم نطاقك:

. . .
server {
    . . .
    ssl on;
    ## Location of the Let's Encrypt certificates
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    . . .
}

باقي خيارات SSL مأخوذة مُباشرة من درس Nginx و Let's Encrypt:

. . .
server {
    . . .
    ## From https://cipherli.st/
    ## and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
    ssl_ecdh_curve secp384r1;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
    ## Disable preloading HSTS for now.  You can use the commented out header line that includes
    ## the "preload" directive if you understand the implications.
    #add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    ssl_buffer_size 1400;

    ssl_dhparam /etc/ssl/certs/dhparam.pem;
    . . .
}

قسم location ~ \.php$‎ يخبر Nginx عن كيفيّة تقديم ملفات PHP. الجزء اﻷهم هو اﻹشارة إلى ملف مقبس Unix الذي استعملناه عندما أنشأنا الملفّ ‎/etc/php5/fpm/pool.d/cachet.conf. أي الملفّ ‎/var/run/php5-fpm-cachet.sock بالتحديد.

. . .
server {
    . . .
    location / {
        try_files $uri /index.php$is_args$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php5-fpm-cachet.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_index index.php;
        fastcgi_keep_conn on;
    }
}

احفظ وأغلق الملف إن لم تفعل ذلك مسبقا.

واﻵن بعد إنشاء إعدادات Cachet لـNginx، أنشئ وصلة رمزية (symlink) يُشير إلى المُجلد sites-enabled، إذ هنا يبحث Nginx عن ملفات اﻹعدادات لاستعملها:

sudo ln -s /etc/nginx/sites-available/cachet.conf /etc/nginx/sites-enabled/cachet.conf

أعد تشغيل Nginx لتطبَّق التّغييرات:

sudo systemctl restart nginx

ومكّن خدمة Nginx لكي تشتغل تلقائيا عند إعادة تشغيل الخادوم:

sudo systemctl enable nginx

هذا كلّ ما في اﻷمر، إذا كتبت الآن اسم نطاقك في المتصفح، سوف تظهر لك صفحة ضبط Cachet.

لنُلقِ نظرة على هذه الصّفحة.

الخطوة الثامنة: إنهاء الضّبط المبدئي لـCachet

يتمّ إنهاء ما تبقى من خطواتِِ لإعداد Cachet في الواجهة الرسوميّة (GUI) على مُتصفّحك، ما يشمل إعداد اسم الموقع و المنطقة الزمنية باﻹضافة إلى إنشاء حساب المدير. هناك ثلاث خطوات (إعداد البيئة، صفحة الحالة، وحساب المدير )، ويمكنك تغيير اﻹعدادات لاحقا في لوحة التحكم الخاصّة بـ Cachet.

ضبط البيئة

ضبط البيئة هي أول خطوة من إعدادات الضّبط.

تنبيه : إصدار Cachet الذي نستخدمه به علة تتمثل في عدم ظهور إعدادات البريد اﻹلكتروني على صفحة إعدادات البيئة، حتى لو قمت بضبطها مسبقا في env. سيتم حل هذا في اﻹصدار 2.4.

يجب ملء الحقول كما يلي :

• Cache Driver يجب أن يكون (ACP(u.
• Session Driver يجب أن يكون (ACP(u.
• Mail Driver يجب أن يكون SMTP.
• Mail Host يجب أن يكون عنوان بريد خادومك اﻹلكتروني. -Mail From Address يجب أن يكون عنوان البريد اﻹلكتروني الذي سترسل منه التنبيهات إلى المشتركين.
• Mail Username يجب أن يكون مستخدم حساب SMTP (عادة بريدك اﻹلكتروني بأكمله). -Mail Password يجب أن يكون كلمة مرور حساب SMTP.

اضغط Next للذهاب إلى الخطوة التالية.

ضبط صفحة الحالة

في هذا القسم، سنضبط اسم الموقع، نطاق الموقع، المنطقة الزمنية، واللغة. مُلاحظة : تدعم Cachet العديد من اللغات، لكنها مشروع مجتمعي، ما يعني أنه قد تكون هناك نصوصً غير مترجمة في اللغات المغايرة للإنجليزية. يمكنك إلقاء نظرة على لائحة اللغات المدعومة، والنسبة المئوية للمحتوى المُترجَم (للأسف، فقد تُرجم 34% فقط إلى اللغة العربية في وقت ترجمة هذا الدّرس).

يجب ملء الحقول كما يلي:

• Site Name: الاسم الذي سيظهر على لوحة التحكم
• Site Domain: اسم النطاق FQDN الذي اخترته لـ Cachet
• Select your timezone: اختر منطقة زمنية بناء على جمهورك. UTC خيار افتراضي جيد.
• Select your language: اختر لغة واجهة Cachet.
• Show support for Cachet: إذا اخترت هذا الخيار، ستظهر عبارة "Powered by Cachet” على تذييل (footer) لوحة التحكم العامّة.

اضغط Next للذهاب إلى الخطوة التالية.

ضبط حساب المدير

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

إنهاء الضبط

على صفحة إنهاء الضبط Complete Setup، سيتم إعلامك بأنه قد تمّ إعداد Cachet بنجاح. يمكنك اﻵن الضغط على "Go to the dashboard” لتسجيل الدخول بمعلومات المدير خاصتك وزيارة لوحة تحكم Cachet.

بعد إنهاء الخطوات السّابقة، فإنّCachet اﻵن مضبوطة وتعمل بشكل كامل. الخطوة اﻷخيرة توضِّح كيفية ترقيتها في المستقبل.

الخطوة التاسعة: ترقية Cachet.

استعمال Git يجعل أمر الترقية سهلا للغاية عند صدور إصدار جديد من ـ Cachet. إذ كل ما عليك فعله هو الانتقال إلى الوسم المناسب وتشغيل تهجير قاعدة البيانات.

مُلاحظة: من الجيد دائما أخذ نُسخة احتياطيّة لـ Cachet وقاعدة بياناتها قبل محاولة ترقية اﻹصدار. وفي SQLite كل ما عليك فعله هو نسخ الملف database/database.sqlite إلى مكان آخر.

أوﻻ، تحوَّل إلى المستخدم cachet وانتقل إلى المُجلد الذي نُصِّبتْ فيه Cachet:

sudo su - cachet
cd /home/cachet/www

يمكنك تشغيل صفحة الصيانة إن اخترت ذلك:

php artisan down

اجلب شفرة Cachet الحديثة من GitHub:

git fetch --all

استعرض لائحة بجميع الوسوم المُتاحة:

git tag -l

سوف تظهر لك جميع الوسوم الحديثة التي تبدأ بحرف v. قد تلاحظ أنّ بعضا منها عبارة عن نُسخ تجريبيّة بيتا (beta) أو في حالة ترشيح للإطلاق (Release Candidate) أو ما يُعرف اختصارا بإصدارات RC. وﻷننا نعمل مع خادوم إنتاج (production server)، فيمكنك تجاهل هذه النّسخ واستعمال النّسخ المُستقرّة. يمكنك أيضا زيارة صفحة إصدارات Cachet لمعرفة أحدث وسم.

إن رغبت في استعمال وسم للترقية، استعمل Git للانتقال إليه. على سبيل المثال، إذا رغبت في ترقيّة Cachet إلى اﻹصدار 2.4.0، فستسعمل الأمر التّالي:

git checkout v2.4.0

أزل خبيئة Cachet قبل الاستمرار:

rm -rf bootstrap/cache{,t}/*

تاليا، قم بترقية اعتماديات Composer، والتي تحتوي عادة على إصلاح للعلل، تحسينات في اﻷداء، وميزات جديدة:

composer install --no-interaction --no-dev -o --no-scripts

أخيرا، شغّل التهجير:

php artisan app:update

إذا شغّلت صفحة الصيانة، فيمكنك اﻵن تمكين الوصول مجددا:

php artisan up

اﻹصدار الجديد من Cachet سيعمل كما يجب.

خاتمة

قمتَ اﻵن بإعداد Cachet مع SSL مدعومة بقاعدة بيانات SQLite وتعلمتَ كيفية صيانتها وترقيتها باستخدام Git. يمكنك كذلك اختيار قواعد بيانات أخرى مثل MySQL أو PostgreSQL. لتعلم المزيد حول خيارات Cachet، تفقّد التوثيق الرسمي.

ترجمة -بتصرّف- للمقال How To Create a Status Page with Cachet on Debian 8 لصاحبته Achilleas Pipinellis.

إزالة بعض الالتباس حول مفهوم DevOps.

يتعرف الكثير من الناس على DevOps للمرّة الأولى عند رؤيتهم لإحدى انتاجاتها وتساؤلهم عن كيفية حدوث ذلك. إذ أنه ليس من الضروري فهم فيما إذا كان شيء ما يشكل جزءًا من DevOps للبدء بتنفيذه، لكن معرفة ذلك – ومعرفة ما الذي يجعل من DevOps استراتيجية مهمة- يمكن أن تشّكل الفارق بين كونك قائدًا أو تابعًا في مجالٍ ما.

ربما سمعت عن بعض النتائج المدهشة التي تُنسب إلى DevOps، مثل بيئات الإنتاج عالية المرونة والتي يمكنها التعامل مع الآلاف من الإصدارات يوميًا بينما تدور أداة "Chaos Monkey" (وهي أداة برمجية طُوّرت بواسطة مهندسي Netflix لاختبار مرونة واسترداد خدمات Amazon Web Services [اختصارًا AWS] الخاصة بهم) حول هذه الاصدارات لفصل الأشياء بشكل عشوائي. هذا أمر مثير للإعجاب، ولكنه في حد ذاته يُمثل حالة عمل ضعيفة، مثقلة بشكل أساسي بإثبات سلبي (proving a negative): أن بيئة DevOps مرنة لأنه لم يُلاحظ فشل خطير ... حتى الآن.

يوجد الكثير من الالتباس حول مفهوم DevOps ولا يزال الكثير من الناس يحاولون فهم ذلك. إليك مثال عن شخص ما عبر حسابي على موقع التواصل الاجتماعي LinkedIn:

اقتباس

حضر هذا الشخص مؤخرًا عددًا من جلسات DevOps حيث بدا أن بعض المتحدثين يشيرون إلى Agile على أنها مجموعة فرعية من DevOps. و كان فهمي بشكل أو بآخر عكس ذلك تمامًا.

أود سماع أراءك. برأيك ما هي العلاقة بين Agile و DevOps؟

هل DevOps هي مجموعة فرعية من Agile؟ أم Agile هي مجموعة فرعية من DevOps؟ أم ان DevOps هي امتداد لـ Agile، تبدأ حيث ينتهي Agile؟ أم هل DevOps هو الإصدار الجديد من Agile؟

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

جذور DevOps في التصميم الرشيق (lean) والتصميم المرن (agile)

تُعد DevOps أسهل للفهم إذا بدأنا باستراتيجيات هنري فورد وتحسينات نظام إنتاج تويوتا لنموذج فورد. وضمن هذا التاريخ ظهور منهجية التصميم الرشيق (lean)، والتي دُرست جيدًا. قام جيمس ب. ووماك ودانييل جونز في كتاب Lean Thinking بتلخيصها إلى خمسة مبادئ:

1. تحديد القيمة المرغوبة من قبل العميل.
2. تحديد سلسلة القيم لكل منتج يوفر هذه القيمة ويلغي جميع الخطوات المهدورة اللازمة حاليًا لتوفيره.
3. جعل تدفق المنتج متواصلًا من خلال خطوات القيمة المضافة المتبقية.
4. ادخال السحب بين جميع الخطوات التي يكون فيها التدفق المستمر ممكنًا.
5. إدارة نحو الاكتمال بحيث ينخفض باستمرار عدد الخطوات ومقدار الوقت والمعلومات اللازمة لخدمة العملاء.

تسعى منهجية التصميم الرشيق إلى إزالة الهدر باستمرار وزيادة تدفق القيمة إلى العميل. يمكن التعرف عليها بسهولة وفهمها من خلال مبدأ أساسي للتصميم الرشيق وهو مبدأ: تدفق القطعة الواحدة. يمكننا القيام بعدد من الأنشطة لمعرفة السبب في أن تحريك قطعة منفردة في كل مرة أسرع من تحريك قطع متعددة دفعة واحدة؛ إن لعبة Penny Game و لعبة الطائرة Airplane Game أمثلة على ذلك. ففي لعبة Penny، إذا استغرقت دفعة الـ 20 بنس دقيقتين للوصول إلى العميل، فسيحصل على كامل الدُفعة بعد دقيقتين من الانتظار. بينما إذا نقلت بنس واحد في كل مرة، فسيحصل العميل على أول بنس في غضون خمس ثوانٍ ويستمر في الحصول عليهم بنس تلو الآخر حتى يصل البنس العشرين بعد 25 ثانية تقريبًا.

وهذا يعتبر فرقًا كبيرًا، ولكن ليس كل شيء في الحياة بسيط ويمكن التنبؤ به كما هو الحال هنا في مثال البنس في لعبة بيني. ومن هنا أتت «المنهجية المرنة» (agile). بالتأكيد نرى مبادئ Lean تنسحب على فرق Agile عالية الأداء، ولكن هذه الفِرق تحتاج إلى ما هو أكثر من مبادئ Lean للقيام بعملها.

تركز عملية التصميم المرن Agile من أجل التمكن من التعامل مع عدم القدرة على التنبؤ وتباين مهام تطوير البرامج النموذجية، على المعرفة الصحيحة والتشاور والقرار والعمل على ضبط المسار في مواجهة الوقائع المتغيرة باستمرار. على سبيل المثال، تزيد الأطر الرشيقة (مثل «فريق سكروم» [scrum]) من الوعي بالمهام مثل الجاهزية اليومية والمراجعة الزمنية. فإذا أصبح فريق سكروم مدركًا لحقيقة جديدة، فإن الإطار يسمح له ويشجعه على ضبط المسار إن لزم الأمر.

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

حجم الدفعة الأمثل

يساعد فهم اقتصاديات حجم الدُفعات على فهم قوة DevOps في تطوير البرمجيات. تأمل الرسم التوضيحي الأمثل لمنحنى U التالي من كتاب دونالد راينترسن مبادئ تدفق تطوير المنتجات Principles of Product Development Flow:

يمكن تفسير ذلك بتشبيه حول التسوق في البقالية. افترض أنك بحاجة إلى شراء بعض البيض وتعيش في مكان يبعد 30 دقيقة من المتجر. إن شراء بيضة واحدة (أقصى اليسار على الرسم التوضيحي) في المرة الواحدة يعني رحلة لمدة 30 دقيقة في كل مرة تريد فيها شراءها. هذه هي تكلفة المعاملة (transaction cost). قد تمثل تكلفة الحجز (holding cost) البيض التالف وشغل المساحة في الثلاجة لفترة من الزمن. التكلفة الإجمالية (total cost) هي تكلفة المعاملة مضافًا إليها تكلفة الحجز في الثلاجة. يفسر منحنى U هذا السبب، بالنسبة لمعظم الناس، بإن شراء أكثر من 12 بيضة (دزينة) في وقت واحد هو الحجم الأمثل للدفعة. إذا كنت تعيش بجوار المتجر، فستكلفك القليل من المشي إلى هناك، وربما تشتري كرتونًا أصغر حجمًا في كل مرة لتوفير مساحة في الثلاجة والاستمتاع بالبيض الطازج.

يمكن لهذا الرسم التوضيحي لتحسن منحنى U توضيح سبب زيادة الإنتاجية بشكل كبير في تحويلات المنهجية المرنة الناجحة. تأمل في تأثير تحويل agile على صنع القرار في المنظمة. تكون سلطة اتخاذ القرار مركزية في المنظمات الهرمية التقليدية. هذا يؤدي إلى اتخاذ عدد أكبر من القرارات وبتواتر أقل ومن قبل عدد أقل من الأشخاص. حيث ستعمل المنهجية المرنة (agile) على تقليل تكلفة معاملات المؤسسة بشكل فعال لاتخاذ القرارات من خلال تطبيق اللامركزية على القرارات إلى المكان الذي تكون فيه المعرفة والمعلومات متوفرة بشكلها الأمثل: أي إلى فرق agile ذات الوثوقية العالية والتنظيم الذاتي.

توضح الرسوم المتحركة التالية كيف يؤدي خفض تكلفة المعاملة إلى تغيير الحجم الأمثل للدُفعة إلى اليسار. لا يمكنك التقليل من قيمة المؤسسة في اتخاذ قرارات أسرع بشكل متكرر.

أين تكون DevOps أكثر ملائمة؟

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

تُفهم DevOps بشكل أكثر تقليدية كطريقة لهدم جدران الالتباس بين فرق التطوير dev والعمليات ops. تُطوّر فرق التطوير في هذا النموذج ميزات جديدة، بينما تحافظ فرق العمليات على استقرار النظام وتشغيله بسلاسة. يحدث الالتباس لأن الميزات الجديدة من التطوير تُحدث تغييرًا في النظام، مما يزيد من خطر توقف الخدمة والذي لا يشعر فريق العمليات بالمسؤولية عنه -لكن عليه التعامل معه على أي حال. لا تكتفي DevOps فقط بمحاولة جعل الناس يعملون معًا فحسب، بل أيضًا بمحاولة إجراء تغييرات أكثر تكرارًا في بيئة معقدة وبشكل آمن.

يمكننا إلقاء نظرة على أبحاث Ron Westrum للبحث في موضوع تحقيق السلامة في المنظمات المعقدة. فقد وجد عند البحث عن سبب كون بعض المنظمات أكثر أمانًا من غيرها أن ثقافة المنظمة هي التي تنبئ بسلامتها. وحدّد ثلاثة أنواع من الثقافة: «المرضيّة أو غير المُتوقعة» (Pathological)، و«البيروقراطية» (Bureaucratic)، و«الابداعية» (Generative). فوجد أن الثقافة المرضيّة كانت تنبئ بسلامة أقل وأن الثقافة الإبداعية كانت تنبئ بمزيد من السلامة (على سبيل المثال، عدد أقل بكثير من حوادث الطيران أو وفيات المستشفى عن طريق الخطأ في مجالات بحثه الرئيسية).

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

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

التدفق وردود الأفعال (التغذية الراجعة) والتعلم

لا تتوقف DevOps عند هذا الحد. لقد كنا نتحدث بشكل رئيسي عن تحقيق DevOps لتدفق ثوري، ولكن يتم زيادة تضخيم أنشطة lean و agile من خلال جهود مماثلة تحقق حلقات تغذية راجعة أسرع كما تحقق تعلمًا أسرع. يشرح المؤلفون في كتاب DevOps Handbook بالتفصيل كيف يُنجز DevOps وفوق تدفقه السريع القياس عن بُعد عبر كامل تدفق القيمة لديه للتغذية الراجعة السريعة والمتواصلة. ستستفيد علاوة على ذلك فرق DevOps عالية الأداء باستمرار من التعلم والتحسين المستمر في أسس مؤسساتها، وذلك من خلال الاستفادة من رشقات «كايزن» (kaizen) الرشيقة و«الأثر الرجعي» (retrospectives) لـسكروم، مما سيؤدي إلى تحقيق ثورة في التصنيع في مجال تطوير منتجات البرمجيات.

ابدأ بتقييم DevOps

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

يجب على الفريق مع مرور بعض الوقت إعادة تقييم الأبعاد نفسها لقياس التحسينات وتحديد مجالات تركيز جديدة عالية التأثير مجدّدا بأفكار جديدة من الفريق.

سنلقي النظر في الجزء الثاني من هذه المقالة على نتائج استبيان DevOps في مجتمع «دروبال» (Drupal) ونرى أين يمكننا إيجاد المكاسب السريعة.

ترجمة وبتصرف للمقال: Why DevOps is the most important tech strategy today لصاحبه: Kelly Albrecht.

اقرأ أيضًا

• المقال السابق: رحلة المطور عبر DevOps
• كامل مقالات السلسلة.

انتهت أيام فرق التطوير وفرق العمليات المنعزلة.

ما علاقة المطوًر «بور سوتر» (Burr Sutter وكتابه، The Phoenix Project؟

كما أوضح سوتر في حديثه المقتضب الذي استمر لمدة خمس دقائق في مؤتمر All Things Open 2016، فإنهم يشتركون في شغفهم بالتقنيين العمليين – وهم المطورون الذين يصممون شيفرات رائعة والمشغلون الذين يقومون بتطوير البنية التحتية لتشغيلها.

وتابع سوتير قائلًا أن أيام فِرق التطوير وفرق العمليات المنعزلة انتهت، وأن مستقبل البرامج أن يعمل الجميع معا لإنشاء أعمال ذات قيمة أفضل وبشكل أسرع.

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

أخبر سوتر المدير التنفيذي أنّه وبالنظر إلى نطاق المشروع والقيود الزمنية المفروضة فإن الفريق "لن يكون لديه وقت حتى للنوم." فكان رد رئيسه تقريبًا: «يمكنك النوم عندما تكون ميتًا».

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

قال سوتر: "لقد فهمنا سريعًا أن السبيل الوحيد للخروج من هذا المأزق هو في المتابعة والمضي قدمًا – كلنا معًا– المطورين، وموظفي العمليات، ومديري قواعد البيانات، وموظفينا- الفريق بأكمله".

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

أوصى سوتر في الختام بكتابين من أشهر كتب جين كيم هما: The Phoenix Project و The DevOps Handbook.

ترجمة وبتصرف للمقال: A developer's journey through DevOps.

اقرأ أيضًا

• المقال التالي: لماذا تعد DevOps الاستراتيجية التقنية الأكثر أهمية اليوم
• المقال السابق: أفضل 5 لغات برمجة لـ DevOps
• كامل مقالات السلسلة.

نجمع هنا خمسًا من أفضل لغات البرمجة لـ DevOps وبعضًا من الموارد التعليمية المفيدة لكلٍ منها.

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

لا تُعد معرفة كيفية تجميع الخوادم وتكدسها مهارة في الطلب في هذه المرحلة. فمعظم مشاريع الأعمال لا تبني مراكز بيانات مادية لها. وبدلاً من ذلك، تُصمم وتبني مقدِرات الخدمة التي تُستضاف في البيئات السحابية العامة. تُهيئ البنية التحتية وتُنشر وتُدار من خلال التعليمات البرمجية. وهذا هو جوهر تصميم الـ DevOps - فعندما تتمكن المؤسسة من تحديد بنيتها التحتية في سطور من التعليمات البرمجية، يصبح عندها أتمتة معظم المهام (إن لم تكن جميعها) في مركز البيانات أمرًا ممكنًا.

تتيح المستويات المتقدمة للأتمتة تمكين أنشطة «التركيب المتواصل / التسليم المتواصل» (Continuous Integration /Continuous Delivery CI/CD) التي لم تكن متاحة من قبل. تجعل مهام سير عمل CI / CD هذه من التسليم عملية سلسة خالية من الاحتكاك – حيث يستطيع المطور دفع شفرته إلى مستودع مصدري، وتتولى البنية التحتية تلقائيًا نشرها لدعم عمليات الاختبار التي يمكن أن تدفع تطبيق ما حتى مرحلة الإنتاج تلقائيا دون تدخل بشري. فعمل تقني يزحف تحت قبة أرضية مرتفعة لتوصيل كابلات الشبكة الجديدة لم يعد ضمن المسار الحرج لنشر تطبيق الإنتاج.

تقوم فرق البنية التحتية الآن بتحويل قدراتها بعيدًا عن خوادم الأرفف والتكديس إلى دعم قنوات CI / CD، مما يعني شيفرة التعلم. تُنشر ملفات القوالب المضمنة في YAML والبرامج النصية لنشر البنية التحتية في بايثون والتطبيقات في جافا سكريبت من خلال القنوات المحددة في Groovy. تقترب شيفرة التطبيق نفسه من البنية التحتية. يمكن الآن لمطوري التطبيقات إنشاء «إجرائيات» (routines) في تطبيقاتهم لتوسيع نطاق ومعالجة حالات الفشل من خلال واجهات برمجة التطبيقات الخاصة بالبنية التحتية. وهذا هو السبب في أنني بدأت في استثمار فترة جيدة من وقتي في تعلم الشيفرة.

قررت التركيز على تعلم لغات التطوير المشاركة في DevOps، واخترت خمسًا من أكثر اللغات أهمية وهي: Python و Ruby و Java Script و Go و C.

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

بايثون Python

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

Codecademy: بدأت تعلم بايثون في موقع Codecademy. الذي يُقدِّم تمهيدًا رائعًا لبايثون.

تدريب Safari Books عبر الإنترنت: انتقلتُ منه إلى المقدمة الممتازة لجيسيكا ماكلار في دورة Introduction to Python في مكتبة Safari Books Online. إن خدمة Safari مكلفة، ولكن غالبًا ما تكون هناك حسومات على مبيعات الأعضاء يمكن أن تمنحك خصمًا قد يصل إلى 50٪. تحتوي SafariBooks أيضًا على مقاطع فيديو لمؤتمرات O'Reilly، بما في ذلك المحادثات والمختبرات. حيث توفر المحادثات فرصة لإيجاد مواضيع هامّة في كل لغة.

مقاطع الفيديو الخاصة بالمؤتمرات عبر الإنترنت: ابحث عبر الإنترنت وستجد محادثات مثيرة للاهتمام في مؤتمرات مطوّري برامج مختلفة حول كيفية استخدام اللغات بطرق ربما لم تفكر فيها من قبل. تتوفر على سبيل المثال على YouTube مقاطع فيديو مؤتمر PyCon.

روبي Ruby

تُستخدم روبي في عدد من مشاريع البنية التحتية. على سبيل المثال إن تطبيق ManageIQ، هو تطبيق Ruby on Rails. كثيرا ما كنت أمازح العملاء خلال وظيفتي في Red Hat، بأنه مع ManageIQ (و CloudForms)، يكون المستخدمون على بعد 10 سطور فقط من شيفرة Ruby للقيام بأي شيء.

Codecademy: حصلت على معرفتي في روبي بشكل رئيسي من هذا الموقع، كما هو الحال مع بايثون.

التوثيق الرسمي: إن المصدر الآخر الذي ساعدني على فهم روبي بشكل عملي أكثر (أي بالنسبة لوظيفتي) هو كتاب بيتر ماكووان Mastering CloudForms Automation (متوفر بتنسيق PDF مجاني). وساعد العمل مع state machines لـ CloudForms وأتمتة سير العمل المتقدمة في تشكيل فهمي للبنى داخل روبي.

الحلقات الصوتية: استمعت أيضًا إلى Ruby on Rails Podcast، و Ruby Rogues.

جافا سكريبت JavaScript

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

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

التوثيق الرسمي: إن التوثيق الرسمي هو مرجعي الأول لأي شيء غامض يواجهني أثناء رحلتي في تعلم جافاسكربت.

الحلقات الصوتية: أستمع أيضًا إلى الملفات الصوتية التي تركز على جافا سكريبت، مثل JavaScript Jabber و FiveJS.

Go

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

golang.org: لقد بدأت مع Go، بدءًا من الجولة التعليمية الموجودة في golang.org.

قناة Google Developers على YouTube: بدأت أيضًا بمشاهدة مقاطع الفيديو على قناة Google Developers channel، بما في ذلك Go for Pythonistas و Get Started with Go و Go Programming.

تدريب Safari Books Online: ركزتُ بشكل أكبر على Go في عام 2017 لأنها تدعم عددًا من تقنيات الويب المهمة مثل Docker و Kubernetes وغيرها. يعد مسار التعلم في Safari Books Online مصدرًا رائعًا آخر، بما في ذلك Master Google's Go.

السي C

حاولت تعلم لغة C مرات عديدة. في كل مرة كنت أقترب فيها من C لم يكن لدي هدف معين في الحسبان. أردت فقط تعلم اللغة لأن الكثير من الشيفرات في العالم مكتوبة بلغة C، والعديد من« البنى» (constructs) في هذه اللغة يُعاد استخدامها في لغات أخرى. تعلمت سريعًا عند انضمامي إلى Red Hat، أن هناك مقولة موجودة في مجتمع «البرمجيات الحرة والمفتوحة المصدر» (FOSS) لفترة طويلة جدًا وهي: أفضل التوثيق هو الشيفرة نفسها.

وأدركت أنني بحاجة إلى تعلم لغة C عند محاولتي فهم مشاريع مثل KVM و libvirt و QEMU، وذلك لفهم ما يحدث في المستوى التأسيسي.

تعلم C بالطريقة الصعبة: لتعلم C تعلمت طريقة Learn C the Hard Way والتي أثبتت أنها طريقة مميَّزة للغة. أحب أسلوب كتابة المؤلف والنهج المعبر لتمارين كتابة الشيفرة. يمكنك قراءة الكتاب مجانًا عبر الإنترنت، أو شراء الكتاب للحصول على أمثلة التعليمات البرمجية وملفات الفيديوأيضًا.

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

ما هي لغات البرمجة التي تركز على تعلمها الآن؟ أخبرنا عن الموارد التي كانت أكثر فائدة لك في رحلتك البرمجية الخاصة.

ترجمة وبتصرف للمقال: Top 5 programming languages for DevOps لصاحبه:Chris Saunders.

اقرأ أيضًا

• المقال التالي: رحلة المطور عبر DevOps
• المقال السابق: ثلاث خطوات لتأمين DevOps مفتوح المصدر
• كامل مقالات السلسلة.

إنّ المفتاح الرئيسي لتأمين تطوير تطبيق ما هو "الإزاحة نحو اليسار" - انقل اختبار الأمان بعيدًا عن مرحلة الإنتاج المتأخرة وعُد إلى التصميم والتطوير.

حقيقةً، لم يعد أحد الآن يكتب شيفرته الخاصّة، أليس كذلك؟ نذهب إلى GitHub (أحد مواقع خدمات استضافة مستودعات المشاريع مفتوحة المصدر يوفر طرائق لتتبع القضايا التي تُنشِئها وتسمح للمستخدمين بإنشائها)، وننزل بعضًا من المكتبات، ونتجنب إعادة اختراع العجلات غير الضرورية، نجمع هذه العجلات بالشكل الذي يناسبنا لإنشاء برامج جديدة. ثم نُنزّل بعضًا من الأطر الأمامية لجعلها تبدو جميلةً وسريعة الاستجابة ونحن خارج السياق. وجدت خلال مراجعتي للتطبيقات، سواء تلك الموجودة في شركتي أو في شركات أخرى، أن أكثر من 90٪ من الشيفرة التي تشكل تطبيقًا هذه الأيام هي عبارة عن أشياء استعرناها، ولم نكتبها بأنفسنا.

يفحص معظمنا شيفرته بحثًا عن العيوب مستخدمًا «أدوات التحليل الثابتة» (static analysis tools)، لكن ماذا عن كل المواضيع التي لم نكتبها بأنفسنا؟ كيف يمكننا معرفة ما في داخلها بالفعل؟ وبمجرد معرفتنا لذلك، ما هي الإجراءات التي نتخذها إما لتنظيفها أو لإبقائها محدّثة؟ كيف يمكننا تجنب التعرض للاختراق لأننا ندع شيئا مفتوحًا يعمل في الخلفية باستخدامنا لتلك المكتبة القوية المزدحمة التي تفعل ذاك الشيء الجميل الذي لا يمكننا الاستغناء عنه؟

الطريقة القديمة

أُبرمج منذ 20 عامًا تقريبًا، وهي فترة طويلة وكافية لرؤية التطور بدءًا من النماذج التقليدية لتخطيط البرامج كالنماذج الشلالية أو الحلزونية إلى نماذج «البرمجة الفائقة» (Xtreme Programing)، والنماذج المرنة Agile و تطوير العمليات DevOps الآن.

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

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

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

إن الخبر الجيد هنا هو أنه الآن يوجد استراتيجيات حقيقية لإيضاح المشكلة وطرق حلها.

الطريقة الجديدة

عالم اليوم هو عالم الأتمتة و«التكرار المتواصل» (continuous iteration). نسمي هذه العملية بـ "DevOps" لأنها تمزج تطوير البرمجيات وتعريف وأتمتة البنية التحتية لإنشاء نماذج للنشر والعمليات التي تُمكّن ذاتيًا.

عندما نضيف أمانًا إلى ذلك، فإننا نطبق نفس التوقعات بأن نؤتمت كل شيء تلقائيًا ونعرّف «الأنماط» (patterns) والعمليات بحيث يمكن تكرارها باستمرار. وبهذا يكون انتهى بنا الأمر إلى ما أحب أن أسميه "DevSecOps". (DevSecOps هي اختصار لمصطلح التطوير والأمن والعمليات. هدفها هو جعل كل شخص مسؤولاً عن الأمان بهدف تنفيذ القرارات والإجراءات الأمنية بنفس المستوى والسرعة كما في قرارات وإجراءات التطوير والعمليات.)

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

كما هو الحال في DevOps، التي تُمكّن المطورين من تعريف« بُنى» (architecture) معتمدة على البرمجيات وإصدارها ونشرها باستخدام الأتمتة، تمنح DevSecOps المطورين نفس الأدوات والتقنيات والعمليات للقيام بالشيء نفسه من أجل أمان البرنامج.

الخطوة 1: البدء في التصميم

إنّ الطريقة الأكبر التي تخرج بها التطبيقات مفتوحة المصدر عن مسارها بسرعة، تتمثل في عدم التفكير في بنيّة التطبيق قبل البدء بكتابة الشيفرة. هل ما زلت تستخدم نسخة "Struts" عمرها سنتين لتطبيقك الجديد فقط لمجرد أنّها مثبّتة على جهازك المحلي مسبقًا، متبقيةً من مشاريعك العشرة السابقة التي أنجزتها؟ تأكّد في كل مرّة تبدأ فيها مشروعًا جديدًا بأنّك تستخدم الإصدار الأحدث والأكثر موثوقية من إطار العمل الذي تعتمده. استخدم أدوات مجانيّة أو أدوات غير مكلفة مثل SourceClear لتحديد «فاتورة المواد» (Bill Of Materials- BOM) في تطبيقك وكن متأكدًا من أنها تفي بالمطلوب قبل بدء العمل. سيوفر عليك لك المتاعب لاحقًا.

الخطوة 2: أتمتة كل شيء

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

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

الخطوة 3: تطوير "مواطنين جيدين" وليس "بنى جيدة"

أخيرًا، لكي يتحقق DevSecOps بالفعل، علينا العمل على تغيير طريقة التفكير حول سياسة أمن المعلومات InfoSec وعمليات النشر المتعلقة بذلك.

كانت تبدو معظم نماذج النشر التي تتضمن الأمان في الماضي كالتالي:

تصميم -> كتابة شيفرة -> اختبار التكامل -> ضمان الجودة QA -> مراجعة InfoSec -> الإنتاج. ( QA: هي اختصار للكلمتين Quality Assurance)

ولكن عندما تكون دورات DevOps مُحتملة خلال ساعات أو حتى دقائق، فكيف يمكنك مراجعة InfoSec قبل مرحلة الإنتاج؟ الجواب: ليس أنت من يفعل ذلك.

واسمحوا لي أن أصيغ السؤال على هذا النحو: إذا كان المطورون يحصلون على معلومات جيدة في وقت مبكر لأنك عملت على أتمتة تحليل الشفرة الثابتة، ووفرتَ طريقة تلقائية لإنشاء فاتورة المواد BOM لأطر عمل المصادر المفتوحة لديك، وقدّمت ذلك مبكرًا في دورة حياة تطوير البرمجيات منذ مرحلة التطوير أو حتى التصميم، فما الذي تختبره بالضبط في هذه البنية؟

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

اسأل نفسك الآن السؤال التالي، "هل تثق بهم؟"

لاحظ، إذا كنت تقدم المعلومات في وقت مبكر بما فيه الكفاية، فبإمكانك إزالة "مراجعة InfoSec" بالفعل عندما يحين وقت النشر.

ماذا؟ وهذا صحيح. يمكن ببساطة في هذه المرحلة أن تسأل عملية التحكم في التغيير الخاصة بك الأسئلة التالية:

• "هل أُكمِلت مراجعات الأمان التلقائية لهذا التطبيق في كل مرحلة من المراحل؟"
• "هل حلّ المطورون العيوب الحرجة كما هو متوقع على أسس ثابتة؟"
• "هل كان آخر تقييم مكتمل يصل إلى مستوى توقعاتنا (سياستنا)؟" إذا كان بإمكانك الإجابة بنعم على هذه الأسئلة، فإن ما عليك فعله هو الوثوق في أن فريق التطوير يعمل بشكل نموذجي (مواطنين جيدين)، والحرص على إنتاج نوعية جيدة، والتصرف بطريقة مسؤولة. سيبدو نموذجنا الجديد مشابها لهذا:

تصميم مستنير -> مراجعة الشيفرة الآلية -> ضمان الجودة -> IT -> مواطن جيد؟ -> النشر.

ترجمة وبتصرف للمقال: 3 steps to secure, open source DevOps لصاحبه: Jet Anderson.

اقرأ أيضًا

• المقال التالي: أفضل 5 لغات برمجة لـ DevOps
• المقال السابق: ما هي الغاية من DevOps؟
• كامل مقالات السلسلة.

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

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

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

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

فكّر الآن في التغييرات التي تحتاجها مؤسسة تعمل في مجال تكنولوجيا المعلومات. ربما فكّرتَ في اعتماد شيء مثل DevOps. يحتوي هذا الشيء الذي نسميه "DevOps" على ثلاثة مكونات: الأشخاص والعملية والأدوات. يمثل الناس والعملية الأساس لأي منظمة. لذلك، يتطلب اعتماد DevOps إجراء تغييرات أساسية في جوهر معظم المنظمات، وليس فقط تعلم أدوات جديدة.

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

تخلق الأداة الجديدة (أو على الأقل فكرة الأداة الجديدة) فرصة لإجراء مناقشة حول المشاكل الأساسية التي شوهت نظرة فريقك في المراقبة. حيث تتيح لك الأداة الجديدة إجراء تغييرات أكبر - تغييرات على معتقداتك وممارساتك - والتي تُعدُّ أكثر أهمية كأساس لمؤسستك.

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

إزالة الحواجز

اقتباس

;فيما يتعلق بإصلاح الأشياء، كبديل عن اتلافها، هناك مبدأ واضح وبسيط، وهو مبدأ يمكن أن يسمى بالمفارقة. يوجد في هذه الحالة نظام أو قانون معين فلنقل، من أجل البساطة، نصب سياج أو بوابة عبر الطريق. أما النوع الأكثر حداثة من المصلحين سيذهب سريعا إليه ويقول للنوع الأكثر ذكاءً من المصلحين ;لا أرى فائدة من ذلك؛ دعنا نتخلص منه". والذين سيُجيبوا عليه بالقول: ;إذا لم ترَ له استخدامًا، فلن أسمح لك بإزالته بالتأكيد. اذهب بعيدّا وفكّر. وعندما يمكنك العودة
واخباري أنك ترى له استخدامًا، فقد أسمح لك بإتلافه. "- G.K Chesterton ، 1929

لفهم الحاجة إلى DevOps، التي تحاول إعادة تجميع كيانات "الانقسام" التقليدية "للتطوير" و "العمليات"، يجب علينا أولاً أن نفهم كيف حدث الانقسام. بمجرد "معرفة استخدامه"، يمكننا أن نرى الانقسام على حقيقته- ونزيله إذا لزم الأمر.

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

يمكننا بسهولة رسم شجرة تاريخية اعتمادًا على وضع تايلور في الجذر. ظهرت من جهود تايلور المبكرة في أواخر الثمانينات من القرن الماضي برامج دراسة الحركة الزمنية وغيرها من برامج تحسين الجودة التي امتدت في عشرينيات القرن العشرين حتى يومنا هذا، حيث نرى منهجيات معايير سيجما الستة (Six Sigma) والتصنيع الرشيق (Lean) وما شابه. وتُهيمن على ثقافة الأعمال السائدة اليوم منهجيات: من من الأعلى إلى الأسفل (Top-down)، والإدارة موجَّهة النمط (directive-style management)، والمقترنة بالنهج النظامية لدراسة العملية. إنها تركز في المقام الأول على الفاعلية كمقياس رئيسي لنجاح العمال.

إذا كان تايلور هو الأصل لشجرتنا التاريخية، فإن فرعنا الرئيسي التالي في الصندوق سيكون الفريد سلون (Alfred P. Sloan) من جنرال موتورز في العشرينات من القرن الفائت. إن هيكلية Sloan التي أُنشئت في جنرال موتورز، لن تظل قويةً فقط حتى عام الـ 2000، بل أنها أيضًا ستكون النموذج الرئيسي للشركة على مدار الخمسين عامًا القادمة.

كانت جنرال موتورز في عام 1920 تعاني من أزمة في الإدارة -أو بالأحرى أزمة بسبب نقص الإدارة. كتب سلون كتابه «"الدراسة التأسيسية"» (Organizational Study) لمجلس الإدارة، مقترحًا هيكلًا جديدًا لعدد وافر من أقسام جينرال موتورز. يركّز هذا الهيكل الجديد على مفهوم "العمليات اللامركزية مع التحكم المركزي". ستعمل الآن الأقسام الفردية، المرتبطة بعلامات تجارية مثل شيفروليه وكاديلاك وبويك بشكل مستقل في حين توفر الإدارة المركزية الوسائل اللازمة لتوجيه الاستراتيجية والتحكم المالي.

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

لا تزال فكرة تايلور حول "أفضل الممارسات" - السلوكيات القياسية التبادلية والتكرارية - تحتل مكانًا في مُثُل الإدارة الحالية، حيث تقترن بالنموذج الهرمي للهيكل المؤسسي لسلون، الذي يدعو إلى انقسامات صلبة للإدارة وصوامع من أجل السيطرة القصوى.

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

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

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

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

استقطاب مستخدمين جدد ⟷ خبرة المستخدمين الحاليين

الحصول على ميزات التطبيق ⟷ تطبيق متاح للاستخدام

النجاح في المنافسة ⟷ حماية الإيرادات

إصلاح المشكلات التي تظهر ⟷ منع المشكلات قبل حدوثها

يمكننا أن نرى اليوم اعترافًا متزايدًا بين كبار قادة المنظمات بأن ثقافة الأعمال الحالية (وبالتالي مجموعة التوترات التي تنتجها) تمثل مشكلة خطيرة. في تقرير Gartner لعام 2016، قال 57 بالمائة من المشاركين أن التغيير الثقافي كان أحد التحديات الرئيسية التي ستواجه الشركة حتى عام 2020. إن ظهور أساليب جديدة مثل المنهجية المرنة و DevOps كوسيلة للتأثير على التغييرات التنظيمية يعكس هذا الاعتراف. الارتفاع في «"تكنولوجيا معلومات الظل"» (shadow IT) هو الوجه الآخر للعملة. حيث تربط التقديرات الحديثة ما يقرب من 30 في المئة من إنفاق تكنولوجيا المعلومات خارج سيطرة منظمة تكنولوجيا المعلومات.

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

المقاومة ليست عديمة الجدوى

اقتباس

"يعتقد بيرت لانس أنه يستطيع ادخار أموال طائلة للعم سام إذا تمكّن من إقناع الحكومة بتبني شعار بسيط وهو: "إذا لم يُكسر، فلا تُصلحه". ويوضح: "هذه هي المشكلة مع الحكومة: إصلاح الأشياء التي لم تُكسر بعد وعدم إصلاح الأشياء المكسورة." - Nation's Business، May 1977

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

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

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

على سبيل المثال، تشاور موقع Facebook مع عالم الأنثروبولوجيا «روبن دنبار» (Robin Dunbar) حول أسلوب تعامله المجموعات الاجتماعية، ولكنه أدرك مع نمو الشركة تأثير ذلك على المجموعات الداخلية (وليس فقط المستخدمين الخارجيين للموقع). نالت ثقافة زابوس الكثير من الثناء لدرجة أن المنظمة أنشأت قسمًا يركّز على تدريب الآخرين على وجهات نظرهم حول القيم الأساسية وثقافة الشركات. وبالطبع يعد هذا الكتاب مرافقًا لـكتاب The Open Organization، وهو كتاب يوضح كيف يمكن للمبادئ المفتوحة المطبقة على الإدارة - كالشفافية والمشاركة والمجتمع - إعادة إنشاء المنظمة بما يناسب عصرنا المترابط سريع الخطى.

حل للتغيير

اقتباس

"إذا تجاوز معدل التغيير في الخارج معدل التغيير في الداخل، تكون النهاية قريبة." - جاك ويلش، 2004

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

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

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

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

ترجمة وبتصرف للمقال: What's the point of DevOps لصاحبه: Matt Micene.

اقرأ أيضًا

• المقال التالي: ثلاث خطوات لتأمين DevOps مفتوح المصدر
• المقال السابق: ما المقصود بـ DevOps؟
• كامل مقالات السلسلة.

تُستخدَم كلمة DevOps (اختصارٌ للكلمتين Development و Operations) لوصف مجموعةٍ من أنشطة التكنولوجيا الحديثة التي تسعى إلى تقريب مطوري البرمجيات وموظفي العمليات من بعضهم بعضًا بشكلٍ أوثق بغية العمل بصورة أكثر تعاونية على نفس المشروع.

الهدف من ذلك هو خلال كسر الحواجز التقليدية الموجودة بين هذين الفريقين التقنيين، مما يمكِّن المؤسسات من تقليل الوقت وزيادة الانخراط في تقديم ونشر إصدارات جديدة من البرمجيات.

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

لماذا ينبغي اتباع استراتيجية DevOps؟

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

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

كيف أبدأ؟

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

على الرغم من أنّ DevOps يتمحور بشكل رئيسي حول الثقافة التنظيمية، فإنّ تحديد أدوات البرامج الصحيحة والمناسبة يعدّ خطوةً مهمةً أيضًا. فهل تستخدم مؤسستك أدوات للتحكم بالإصدار والمراجعة مثل Git لمساعدتك في إدارة الشيفرة البرمجية؟ هل تعتمد أدوات البناء و «التركيب المتواصل» (continuous integration) لجعل التحرك من المصدر وحتى الاختبار سلسًا قدر الإمكان؟

وماذا عن الأدوات المستخدمة لأتمتة الاختبار وتحزيم البرامج تلقائيًا، أو لاختبارات النشر والحماية؟ هل تبحث عن طرق لإدارة البنية الأساسيّة الخاصّة بك مثل الشيفرة البرمجية باستخدام «أدوات إدارة التكوين» (configuration management tools)، لتوسيع نطاق البيئات وتكرارها بسهولة؟ وماذا عن أدوات المراقبة لمتابعة كامل العملية بدءًا من التطوير وحتى الإنتاج؟ تستفيد DevOps من إيجاد الأدوات المناسبة للحفاظ على عمل فِرق التطوير والعمليات الخاصة بك معًا وتحركها بشكل أسرع

إذا كنت بحاجةٍ إلى دليل لحماية تقنية «حاويات لينكس» (Linux container)، ألق نظرة على قائمة التحقق المرجعيّة هذه: 4 خطوات لبدء رحلتك مع الحاويات.

دورة علوم الحاسوب

دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب

اشترك الآن

أين يمكنني تعلم المزيد؟

سننشر عددًا من المقالات تشرح ماهية DevOps وتُعرِّفك عليها؛ راجع الوسم «تعرف على DevOps» أو بعضًا من المقالات الأكثر شيوعًا أدناه.

• ما الهدف من DevOps؟: توضح نظرة موجزة لتاريخ DevOps الحاجة إلى التفكير بطريقة مختلفة حول العمل التعاوني في مجال تكنولوجيا المعلومات.
• 3 خطوات لحماية DevOps مفتوحة المصدر: المفتاح الرئيسي لتأمين تطوير التطبيق هو «الإزاحة نحو اليسار» (shift left) - انقل اختبار الأمان بعيدًا عن مرحلة الإنتاج المتأخرة وعُد إلى التصميم والتطوير.
• أفضل 5 لغات برمجة لـ DevOps: نجمع هنا خمسًا من أفضل لغات البرمجة لـ DevOps وبعضًا من الموارد التعليمية المفيدة لكل منها.
• رحلة المطور عبر DevOps: انتهت أيام التطوير المنعزلة لفرق التشغيل والعمليات.
• لماذا تعد DevOps الاستراتيجية التقنية الأكثر أهمية اليوم: إزالة بعض الالتباس حول مفهوم DevOps.
• تقنيات DevOps المحميّة «للخدمات المصغرة» (microservices): أحدثت الحاويات والخدمات المصغّرة ثورةً في تطوير التطبيقات وإدارة البنية التحتية.

ربما يمكنك أيضًا إيجاد الفائدة في هذه الموارد الخارجية التي توفّر المزيد من المعلومات.

• التحديث بسرعة تطبيقات المصدر المفتوح باستخدام DevOps
• 9 عبارات مفتاحية لـ DevOps
• تحديث أسرع اعتمادا على DevOps
• كتاب إلكتروني مجاني: كتاب إلكتروني مجاني: DevOps with OpenShi.

ترجمة وبتصرف للمقال: What is DevOps

اقرأ أيضًا

• المقال التالي: ما الهدف من DevOps؟

مقدمة

تأتي قواعد بيانات SQL مُثبّتة مع جميع الأوامر التي تحتاجها للإضافة، والتعديل، والحذف والاستعلام عن بياناتك. يوفّر هذا الدليل لنمط الورقة المرجعية cheat sheet مرجعًا سريعًا لبعضٍ من أوامر SQL الأكثر شيوعًا.

• كيفية استخدام هذا الدليل:
• هذا الدليل على شكل ورقة مرجعيّة فيها أمثلة منفصلة قابلة للاستخدام فرادى.
• انتقل إلى أي مقطع ذي صلة بالمهمة التي تحاول إكمالها.
• عندما ترى نصًّا مميّزًا في أوامر هذا الدليل، فضع بالحسبان أن هذا النص يشير إلى الأعمدة، والجداول، والبيانات في قاعدة البيانات الخاصة بك.
• ضُمّنت قيم البيانات في هذا الدليل في الأمثلة المُعطاة بعلامة ('). من الضروري في SQL تضمين أي قيم بيانات تحتوي على سلاسل نصية في علامات اقتباس أحادية. هذا التضمين غير مطلوب من أجل البيانات الرقمية، ولكنه لن يتسبب بأيّة مشاكل أيضًا.

يرجى ملاحظة أنّه على الرغم من كون SQL معياريّة، إلاّ أنّ معظم برامج قواعد بيانات SQL لها إضافاتها الخاصّة. يستخدم هذا الدليل MySQL كنموذج لنظام إدارة قواعد البيانات العلائقية (RDBMS)، ولكن الأوامر المقدّمة ستعمل مع برامج قواعد البيانات العلائقية الأخرى، بما في ذلك PostgreSQL و MariaDB وSQLite. سنُضمّن الأوامر البديلة عند وجود فروق مهمّة بين أنظمة إدارة قواعد البيانات العلائقية RDBMSs.

بدء مِحث أوامر قاعدة البيانات (باستخدام استيثاق Socket/Trust)

يمكن لمستخدم MySQL الجذر root الاستيثاق بدون كلمة مرور بشكل افتراضي في نظام التشغيل أبونتو Ubuntu 18.04 باستخدام الأمر التالي:

$ sudo mysql

استخدم الأمر التالي لفتح مِحث أوامر PostgreSQL. سيُسجلك هذا المثال كمستخدم postgres، والذي يتضمن صلاحيات دور المستخدم المميّز superuser role، ولكن يمكنك استبداله بأي دور مُنشئ مُسبقًا:

$ sudo -u postgres psql

بدء مِحث أوامر قاعدة البيانات (باستخدام استيثاق كلمة المرور)

إذا ُضبط مستخدم MySQL الجذر root للاستيثاق باستخدام كلمة مرور، فبإمكانك استخدام الأمر التالي:

$ mysql -u root -p

إذا أعددت مُسبقًا حساب مستخدم عادي non-root لقاعدة بياناتك، فيمكنك أيضًا استخدام هذه الطريقة لتسجيل الدخول باسم هذا المستخدم:

$ mysql -u user -p

سيُقاطعك الأمر السابق بعد تشغيله للمطالبة بكلمة المرور الخاصّة بك. إذا كنت ترغب في جعل كلمة المرور كجزء من الأمر، فأَتبعْ الخيار p- مباشرة بكلمة مرورك، بدون ترك فراغ بينهما:

$ mysql -u root -ppassword

إنشاء قاعدة بيانات

يُنشئ الأمر التالي قاعدة بيانات بإعداداتٍ افتراضيّة:

mysql> CREATE DATABASE database_name;

يمكنك إذا أردت لقاعدة بياناتك أن تستخدم مجموعة محارف وتصنيف مختلفة عن الإعدادات الافتراضيّة تحديد ذلك باستخدام الصياغة التالية:

mysql> CREATE DATABASE database_name CHARACTER SET character_set COLLATE collation;

إظهار قائمة قواعد البيانات

شغّل الأمر التالي لرؤية قواعد البيانات الموجودة في نظام MySQL أو MariaDB:

mysql> SHOW DATABASES;

يمكنك في PostgreSQL مشاهدة قواعد البيانات المُنشأة باستخدام الأمر التالي:

postgres=# \list

حذف قاعدة البيانات

شغّل الأمر التالي لحذف قاعدة بيانات بما في ذلك ضمنًا أي جداول وبيانات موجودة فيها:

mysql> DROP DATABASE IF EXISTS database;

إنشاء مستخدم

نفّذ الأمر التالي لإنشاء معرّف مستخدِم لقاعدةِ بياناتك من دون تحديد أيّ امتيازاتٍ له:

mysql> CREATE USER username IDENTIFIED BY 'password';

تَستخدم PostgreSQL بنية مشابهة، ولكنها مختلفة قليلاً، إليك الصياغة:

postgres=# CREATE USER user WITH PASSWORD 'password';

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

mysql> GRANT ALL PRIVILEGES ON *.* TO 'username'@'localhost' IDENTIFIED BY 'password';

لاحظ الكلمة المفتاحيّة PRIVILEGES في تعليمة GRANT السابقة. إن هذه الكلمة اختيارية في معظم أنظمة إدارة قواعد البيانات العلائقية، ويمكن كتابة هذه التعليمة بشكل مكافئ على النحو التالي:

mysql> GRANT ALL ON *.* TO 'username'@'localhost' IDENTIFIED BY 'password';

كن منتبهًا مع ذلك، أنّ الكلمة المفتاحيّة PRIVILEGES مطلوبة لمنح امتيازات كهذه عندما يكون وضع Strict SQL مُشغّلًا.

حذف مستخدم

استخدم الصياغة التالية لحذف اسم مستخدم قاعدة البيانات:

mysql> DROP USER IF EXISTS username;

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

اختيار قاعدة البيانات

يجب أولًا إخبار RDBMS بقاعدة البيانات التي ترغب في إنشائها في MySQL و MariaDB قبل أن تتمكن من إنشاء جدول. استخدم الصياغة التالية للقيام بذلك:

mysql> USE database;

يجب عليك استخدام الأمر التالي في PostgreSQL لاختيار قاعدة بياناتك المرغوبة:

postgres=# \connect database

إنشاء جدول

تنشئ بنية الأمر التالية جدولًا جديدًا باسم table يحوي عمودين لكل منهما نوع بياناته الخاص:

mysql> CREATE TABLE table ( column_1 column_1_data_type, column_2 column_2_data_taype );

حذف جدول

نفّذ ما يلي لحذف جدول بالكامل، بما في ذلك جميع البيانات الخاصّة به:

mysql> DROP TABLE IF EXISTS table

إدخال البيانات في جدول

استخدم الصياغة التالية لملء جدول بصف واحد من البيانات (row):

mysql> INSERT INTO table ( column_A, column_B, column_C ) VALUES ( 'data_A', 'data_B', 'data_C' );

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

mysql> INSERT INTO table ( column_A, column_B, column_C ) VALUES ( 'data_1A', 'data_1B', 'data_1C' ),  ( 'data_2A', 'data_2B', 'data_2C' ), ( 'data_3A', 'data_3B', 'data_3C' ); 

حذف بيانات من جدول

استخدم بنية الأوامر التالية لحذف صف من البيانات من جدول. لاحظ أن value يجب أن تكون القيمة الموجودة في العمود المحدد column في الصف الذي تريد حذفه:

mysql> DELETE FROM table WHERE column='value';

ملاحظة: إذا لم تُضمّن عبارة WHERE في تعليمة DELETE، كما هو موضّح في المثال التالي، فستُحذف جميع البيانات الموجودة في الجدول، ولكن لن تُحذف الأعمدة أو الجدول نفسه:

mysql> DELETE FROM table;

تغيير البيانات في جدول

استخدم الصياغة التالية لتحديث البيانات الموجودة في الصف المُعطى. لاحظ أنّ عبارة WHERE في نهاية الأمر تُخبر SQL بالصف المطلوب تحديثه. إنّ value هي القيمة الموجودة في column_A المحاذية للصفِ الذي تريد تغييره. ملاحظة: إذا أهملتَ تضمين عبارة WHERE في تعليمة UPDATE، فسيَستبدِل الأمر البيانات الموجودة في كل صف من الجدول.

mysql> UPDATE table SET column_1 = value_1, column_2 = value_2 WHERE column_A=value;

إضافة عمود

ستضيف صياغة الأمر التالية عمودًا جديدًا إلى جدول:

mysql> ALTER TABLE table ADD COLUMN column data_type;

حذف عمود

سيؤدي هذا الأمر إلى حذف عمود من جدول:

mysql> ALTER TABLE table DROP COLUMN column; 

تنفيذ الاستعلامات الأساسيّة

استخدم الصياغة التالية لعرض جميع البيانات من عمود واحد من جدول:

mysql> SELECT column FROM table;

افصلْ بين أسماء الأعمدة بفاصلة للاستعلام عن أعمدة متعددة من نفس الجدول:

mysql> SELECT column_1, column_2 FROM table;

يمكنك أيضًا الاستعلام عن كل الأعمدة في جدول عن طريق استبدال أسماء الأعمدة بعلامة النجمة (*). تعمل علامات النجمة في SQL كبدائل لتمثيل "الكل":

mysql> SELECT * FROM table;

استخدام عبارات WHERE

يمكنك تضييق نطاق نتائج استعلام عن طريق إلحاق تعليمة SELECT بعبارة WHERE، كما يلي:

mysql> SELECT column FROM table WHERE conditions_that_apply;

يمكنك على سبيل المثال الاستعلام عن جميع البيانات من صف واحد من خلال صياغة مشابهة لما يلي. لاحظ أن value يجب أن تكون قيمة محفوظة في كل من column المحدّد والصف الذي تريد الاستعلام عنه:

mysql> SELECT * FROM table WHERE column = value;

العمل مع مُعاملات المقارنة

يحدّد مُعامل المقارنة في جملة WHERE كيفيّة مقارنة العمود المحدّد بقيمة ما. فيما يلي بعض معاملات المقارنة الشائعة لـ SQL:

• = : اختبار المساواة
• != : اختبار عدم المساواة
• < : اختبار أقل من
• > : اختبار أكبر من
• <= : اختبار أقل من أو يساوي
• >= : اختبار أكبر من أو يساوي 
• BETWEEN : اختبار فيما إذا كانت القيمة ضمن مجال مُعطى
• IN : اختبار ما إذا كانت قيمة الصّف مُتضَمّنة في مجموعة من القيم المحدّدة
• EXISTS : اختبار ما إذا كانت صفوف موجودة، تبعاً للشروط المحدّدة
• LIKE : اختبار فيما إذا كانت قيمة تتطابق مع سلسلة نصيّة محدّدة
• IS NULL : اختبار القيم الفارغة
• IS NOT NULL : اختبار كافّة القيم غير الفارغة "NULL"

العمل مع محارف البدل Wildcards

يسمح SQL باستخدام محارف البدل wildcard. وهي مفيدة عندما تحاول العثور على مُدخل محدّد في جدول، ولكنك لا تكون متأكدًا تماماً من هذا المُدخل. تعتبر علامات النجمة (*) عناصر بديلة لتمثيل "الكل"، حيث تقوم بالاستعلام كل الأعمدة في جدول:

mysql> SELECT * FROM table;

تمثل علامات النسبة المئوية (٪) صفراً أو أكثر من محارف غير معروفة.

mysql> SELECT * FROM table WHERE column LIKE val%;

يُستخدم التسطير السفلي (_) لتمثيل محرف واحد غير معروف:

mysql> SELECT * FROM table WHERE column LIKE v_lue;

حساب المُدخلات في عمود

تُستخدم الدّالة COUNT لإيجاد عدد الإدخالات في عمود محدّد. ستُرجع الصياغة التالية إجمالي عدد القيم الموجودة في column:

mysql> SELECT COUNT(column) FROM table;

يمكنك تضييق نتائج دالة COUNT من خلال إضافة عبارة WHERE، كما يلي:

mysql> SELECT COUNT(column) FROM table WHERE column=value;

إيجاد قيمة المعدل في عمود

تُستخدم الدّالة AVG لإيجاد المعدل بين القيم الموجودة في عمود محدّد. لاحظ أن دالة AVG ستعمل فقط مع الأعمدة التي تحتوي على قيم رقميّة. وقد تُعيد خطأ أو 0 عند استخدامها على عمود يحمل قيم نصيّة:

mysql> SELECT AVG(column) FROM table;

إيجاد مجموع القيم في عمود

تُستخدم الدّالة SUM لإجمالي مجموع القيم الرقميّة الموجودة في عمود:

mysql> SELECT SUM(column) FROM table;

كما هو الحال مع دالة AVG، إذا نَفّذتَ الدالة SUM على عمود يحوي قيم نصيّة، فقد تُعيد خطأ أو فقط 0، وذلك اعتمادًا على نظام إدارة قواعد البيانات العلائقية خاصتك.

إيجاد القيمة الكبرى في عمود

استخدم دالة MAX للعثور على أكبر قيمة رقميّة في عمود أو القيمة الأخيرة أبجديًا :

mysql> SELECT MAX(column) FROM table;

إيجاد القيمة الصغرى في عمود

استخدم الدّالة MIN للعثور على أصغر قيمة رقميّة في عمود أو القيمة الأولى أبجديًا:

mysql> SELECT MIN(column) FROM table;

فرز النتائج باستخدام عبارات ORDER BY

تُستخدم عبارة ORDER BY لفرز نتائج الاستعلام. تُعيد الصياغة التالية للاستعلام القيم من column_1 و column_2 وتُرتّب النتائج حسب القيم الموجودة في column_1 بترتيب تصاعدي، أو بترتيب أبجدي بالنسبة لقيم السلاسل النصيّة:

mysql> SELECT column_1, column_2 FROM table ORDER BY column_1;

أتبع الاستعلام بـ DESC لتنفيذ نفس الإجراء، ولكن مع ترتيب النتائج بترتيب أبجدي تنازلي:

mysql> SELECT column_1, column_2 FROM table ORDER BY column_1 DESC;

فرز النتائج باستخدام عبارات GROUP BY

تشبه عبارة GROUP BY عبارة ORDER BY، ولكنها تُستخدم لفرز نتائج استعلام يتضمن دالة مُجمِّعة مثل COUNT أو MAX أو MIN أو SUM. ستؤدي الدوال التجميعيّة الموضّحة في القسم السابق بمفردها إلى إرجاع قيمة واحدة فقط. ويمكنك مع ذلك عرض نتائج دالة التجميع المنفّذة على كل قيمة مطابقة في العمود من خلال تضمين عبارة GROUP BY. ستَحسب الصياغة التالية عدد القيم المطابقة في column_2 وتُجمّعها بترتيب تصاعدي أو أبجدي:

mysql> SELECT COUNT(column_1), column_2 FROM table GROUP BY column_2;

أتبِعْ الاستعلام بـ DESC لتنفيذ نفس الإجراء، ولكن بتجميع النتائج بالترتيب الأبجدي التنازلي:

mysql> SELECT COUNT(column_1), column_2 FROM table GROUP BY column_2 DESC;

الاستعلام عن جداول متعددة مع عبارات JOIN

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

mysql> SELECT table_1.column_1, table_2.column_2 FROM table_1 JOIN table_2 ON table_1.common_column=table_2.common_column;

هذا مثال على عبارة INNER JOIN. ستقوم INNER JOIN بإرجاع جميع السجلات التي تحتوي على قيم متطابقة في كلا الجدولين، ولكنها لن تعرض أي سجلات لا تحتوي على قيم متطابقة. من الممكن إرجاع كافة السجلات من أحد الجدولين، بما في ذلك القيم التي لا تحتوي على مطابق في الجدول الآخر، وذلك باستخدام عبارة JOIN خارجيّة.

تُكتب عبارات JOIN الخارجية إما كـ LEFT JOIN أو RIGHT JOIN. تُرجع عبارة LEFT JOIN كافة السجلات من الجدول "الأيسر" والسجلات المطابقة فقط من الجدول "اليمين". في سياق عبارة JOIN الخارجيّة، يكون الجدول الأيسر هو المشار إليه في جملة FROM، والجدول الأيمن هو أي جدول آخر مشار إليه بعد عبارة JOIN.

سيَعرض الاستعلام التالي كل سجل من table_1 وفقط القيم المطابقة من table_2. ستظهر القيم غير المطابقة في table2 كـ NULL في مجموعة النتائج:

mysql> SELECT table_1.column_1, table_2.column_2 FROM table_1 LEFT JOIN table_2 ON table_1.common_column=table_2.common_column;

إن وظيفة عبارة RIGHT JOIN مماثلة لـ LEFT JOIN، ولكنها تُرجع جميع النتائج من الجدول الأيمن، والقيم المطابقة فقط من الجدول الأيسر:

mysql> SELECT table_1.column_1, table_2.column_2 FROM table_1 RIGHT JOIN table_2 ON table_1.common_column=table_2.common_column;

دمج تعليمات SELECT متعددة باستخدام عبارات UNION

يفيد مُعامل UNION في دمج نتائج تعليمتي SELECT (أو أكثر) في مجموعة نتائج واحدة:

mysql> SELECT column_1 FROM table UNION SELECT column_2 FROM table;

يمكن بالإضافة إلى ذلك أن تجمع عبارة UNION بين تعليمتي SELECT (أو أكثر) والتي تستعلم عن جداول مختلفة في نفس مجموعة النتائج:

mysql> SELECT column FROM table_1 UNION SELECT column FROM table_2;

الخلاصة

يغطي هذا الدليل بعضًا من الأوامر الأكثر شيوعًا في SQL المُستخدمة لإدارة قواعد البيانات، والمستخدمين، والجداول، والاستعلام عن المحتويات الموجودة في هذه الجداول. ومع ذلك، هناك العديد من تجميعات العبارات والمعاملات والتي تنتج جميعها مجموعات فريدة من النتائج. إذا كنت تبحث عن دليل أكثر شموليّة للعمل مع SQL، فإنّنا نُشجعك على مراجعة Oracle's Database SQL Reference

بالإضافة إلى ذلك، إذا كانت هناك أوامر SQL شائعة ترغب في رؤيتها في هذا الدليل، فيرجى طرحها أو تقديم اقتراحات في التعليقات أدناه.

ترجمة بتصرّف للمقال How To Manage an SQL Database لصاحبه Mark Drake

مقدّمة

إنّ TaskBoard أو "لوح المهام" هو برمجيّة مجانيّة ومفتوحة المصدر، مستوحاة من ألواح Kanban لتتبُع المهام.

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

تجعل هذا البرمجيّة التتبع البصري لتطوّر مشاريعك سهلًا كما يظهر في الصورة.

ميزات TaskBoard:

• حرّة، ومفتوحة المصدر (رخصة MIT)، وذاتيّة الاستضافة
• سهلة التثبيت
• ألواح (مشاريع) غير محدودة
• تخصيص الأعمدة داخل الألواح وتوسيع / تصغير مستمر من أجل كل مستخدم
• تسمح العناصر بالألوان المخصّصة، والتصنيفات، وتنسيق التوصيفات، والمرفقات، والتعليقات
• تعرض العناصر تاريخًا كاملًا "أرشيف" للأنشطة activities
• تعرض للمشرفين التاريخ الكامل لجميع أنشطة الألواح
• سهلة التخصيص
• تتيح إدارة أوليّة للمستخدمين (المشرف، والمستخدمين العاديين)
• لا وجود لتبعيّات خارجيّة
• إنشاء لقاعدة بيانات SQLite عند الاستخدام الأول
• واجهة برمجيّة RESTful API) RESTful)
• تبعيّات محدودة جدًا

ستشرح هذه الدورة التعليميّة كيفيّة تثبيتها على CentOS 7.

تثبيت خادم الويب Apache

ثبّت في البداية Apache على جهاز CentOS 7 من خلال تنفيذ الأمر التالي:

# yum install httpd

شغّل Apache ومكّنه من التشغيل في وقت الإقلاع وذلك بمجرد انتهائك من التثبيت:

# systemctl start httpd
# systemctl enable httpd

تثبيت PHP

يجب تثبيت php باعتبار أن TaskBoard مكتوبة بهذه اللغة. ونظرًا لأنّها تتطلب الإصدار PHP الخامس أو أكثر، فسنثبّت PHP7 باستخدام مستودع Webtatic.

أولاً، ثَبّت مستودع EPEL المطلوب من قبل Webtatic:

# yum install epel-release

حدّث:

# yum install epel-release

بالإمكان الآن تثبيت مستودع Webtatic عن طريق تنفيذ الأوامر التالية:

# rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm
# yum update

ثبّت PHP 7.1 والإضافات التي تتطلبها TaskBoard وذلك بمجرّد أن يصبح المستودع جاهزًا ويصبح بالإمكان لـ yum استخدامه:

# yum install php71w php71w-gd php71w-json php71-readline php71w-cli php71w-sqlite3

تثبيت SQLite

يستخدم TaskBoard الـ SQLite كقاعدة بيانات، مما يعني أنه بإمكاننا استخدامه دون الحاجة إلى تثبيت MySQL أو أيّة قواعد بيانات "كبيرة" أخرى.

يمكن تثبيت SQLite باستخدام أمر yum التالي:

# yum install sqlite

تثبيت TaskBoard

إنّ تثبيت TaskBoard سهلٌ للغاية، كما هو متوقع من قائمة الميزات المطوّلة المعروضة في التمهيد. يتطلب الأمر في الواقع فقط تنزيل واستخراج أرشيف TaskBoard. انتقل إلى المسار الجذر للويب في Apache:

# cd /var/www

نزّل الأرشيف هنا:

# wget https://github.com/kiswa/TaskBoard/archive/master.zip

فُك ضغطه:

# unzip master.zip

سيستَخرج unzip الأرشيف إلى دليل يدعى TaskBoard-master. يمكنك إعادة تسميته (اختياري):

# mv TaskBoard-master taskboard

ثبّت الملحقات المطلوبة بواسطة Composer:

./taskboard/build/composer.phar install

ثم غيّر مالك taskboard إلى مستخدم apache:

# chown -R apache:apache /var/www/taskboard

إنشاء مضيف افتراضي Virtual Host

أنشئ ملف مضيف افتراضي جديد لـ TaskBoard:

# $EDITOR /etc/httpd/conf.d/board.example.com.conf

ثم الصق المحتوى التالي في هذا الملف:

<VirtualHost *:80>
	ServerAdmin admin@example.com
	DocumentRoot "/var/www/taskboard"
	ServerName board.example.com
	ServerAlias www.board.example.com
	<Directory "/var/www/taskboard">
    	Options Indexes FollowSymLinks
    	AllowOverride All
    	Require all granted
	</Directory>
	ErrorLog "/var/log/httpd/board.example.com-error_log"
	CustomLog "/var/log/httpd/board.example.com-access_log" combined
</VirtualHost>

أعد تشغيل Apache:

# systemctl restart httpd

إنهاء التثبيت

للقيام بالخطوة الأخيرة لإنهاء التثبيت من خلال متصفح الويب، انتقل إلى عنوان الـ URL:

http://board.example.com

سجّل الدخول مستخدمًا كلمة admin في كل من اسم المستخدم وكلمة المرور على حد سواء. ثم غيّر كلمة مرور المسؤول administrator بعد تسجيلك للدخول مباشرةً وذلك بالانتقال إلى صفحة الإعدادات Settings.

الخلاصة

رأينا كيفيّة تثبيت TaskBoard على CentOS 7. سيُساعد بالتأكيد هذا التطبيق المعتمد على Kanban العديد من النّاس في تنظيم سير عمل مشاريعهم.

ترجمة وبتصرّف للمقال TaskBoard: Kanban-based Software on CentOS 7 لصاحبه Giuseppe Molica.

عندما تصون مستودعًا لمشروع مفتوح المصدر، فأنت تأخذ راية القائد، فلو كنتَ مؤسس أحد المشاريع التي أطلقتها للعموم ليستخدموها ويشاركوا فيها، أو كنت تعمل في فريقٍ وكنت تصون جانبًا من جوانب المشروع، فأنت تقدم خدمةً مهمةً إلى مجتمع التطوير.
وعلى الرغم من أنَّ المساهمات في المشاريع مفتوحة المصدر تكون عادةً عبر طلبيات pull وهي أمرٌ بالغ الأهمية للحفاظ على جودة البرمجيات وفائدتها للمستخدمين النهائيين، لكن المساهمين في المشروع ليس لهم نفس تأثير من يقوم بصيانته ويبلور الشكل العام للمشروع؛ فالصائنون يشاركون في صلب تطوير المشاريع مفتوحة المصدر، إذ يديرون المشروع وينظموه يوميًا ويطوروه، ويتفاعلون مع المستخدمين ويوفرون المعلومات اللازمة للمساهمين.
سنستعرض في هذا المقال بعض التلميحات عن صيانة المستودعات العامة للمشاريع مفتوحة المصدر. فالمسؤولون عن المشاريع مفتوحة المصدر عليهم مسؤوليات كبيرة تقنية وغير تقنية، والعمل كصائن للمشروع يعطي الفرصة للتعلم من الآخرين، وأخذ خبرة في إدارة المشاريع، ويسمح بمراقبة مراحل نمو المشروع وكيف أصبح المستخدمون العاديون مساهمين فعالين فيه.

اكتب توثيقًا مفيدًا

سيزيد التوثيق سهل الفهم (والذي سيؤدي إلى جعل البرنامج سهل الاستخدام) من قاعدة مستخدميك، ويساعد في تحويل المستخدمين إلى مساهمين في مشروعك.
عندما تفكر بالشيفرات التي تكتبها أثناء تطويرك للمشروع، وتكتب بعض الملاحظات الجانبية لتساعدك في دمج مختلف أجزاء مشروعك مع بعضها بعضًا، فسيسهل عليك البدء بكتابة التوثيق أثناء عملية التطوير؛ أو ربما تقرر أن تكتب التوثيق قبل برمجة التطبيق، متبعًا بذلك منهجية «التطوير الموجه بالتوثيق» (documentation-driven development) التي تقول أنَّ عليك كتابة توثيق ميزات المشروع أولًا ثم برمجة تلك الميزات اعتمادًا على توثيقها.
هنالك بضعة ملفات عليك وضعها في المجلد الرئيسي لمشروعك بجانب الشيفرات وهي:
- ملف README.md الذي يوفر ملخصًا عن المشروع وأهدافه.
- ملف CONTRIBUTING.md الذي يحتوي على تعليمات المساهمة في المشروع.
- رخصة مشروعك، والتي ستشجِّع الناس على المساهمة في موقعك، أرجو أن تراجع مقالة كيف تختار رخصة مفتوحة المصدر لبرامجك.
قد يأخذ التوثيق أشكالًا عدِّة، لذا عليك أن تضع نوعية المستخدمين المحتملين ومجال المشروع في الحسبان، فمن الممكن أن يأتي التوثيق بمختلف الأشكال ويكون موجهًا نحو فئات مختلفة من مستخدمي المشروع. قد تقرر استخدام شكل أو أكثر من الأشكال الآتية اعتمادًا على مجال عملك:

• دليل عام لتعريف المستخدمين بالمشروع
• الدروس التعليمية لعرض مختلف حالات الاستخدام
• الأسئلة الشائعة (FAQ) للإجابة عن أكثر التساؤلات شيوعًا بين المستخدمين
• مقالات عن استكشاف الأخطاء التي قد يواجهها المستخدمون وكيفية إصلاحها
• مرجع للواجهة البرمجية (API) للتطبيق تسمح للمستخدمين معرفة معلومات عن الواجهة البرمجية بسرعة
• ملاحظات الإصدار (release notes) التي تُذكَر فيها العلل المعروفة والتغييرات التي حدثت في كل إصدار
• الميزات المستقبلية لتتبع وشرح ما هي الميزات التي ستأتي في إصدارات مستقبلية.
• تسجيل مقطع فيديو لتعريف المستخدمين بمشروعك عبر الوسائط المتعددة.

قد تلائم بعض أشكال التوثيق السابقة مشروعك أكثر من غيرها، لكن توفير أكثر من شكل للتوثيق سيساعد مستخدمي مشروعك أن يفهموا كيف يتفاعلون معك فهمًا أعمق.
عليك عند كتابة التوثيق أو تسجيل مقطع فيديو أن تكون واضحًا قدر الإمكان، ومن الأفضل ألّا تكون عندك افتراضات مسبقة عن القدرات التقنية لمستخدمي مشروعك، ومن الأفضل أن تتبع منهجية Top-Down عند تأليف التوثيق، أي أن تشرح بداية الأمر ما الذي تفعله البرمجية بشكل عام (مثلًا: أتمتة أمور إدارة النظام، أو بناء موقع إلكتروني …إلخ.) قبل التعمق في التفاصيل.
وصحيحٌ أنَّ اللغة الإنكليزية هي اللغة الرائدة في عالم التقنية، لكن أبقِ في ذهنك مَن هم المستخدمون المتوقعون وما هي لغتهم الأم؛ فاللغة الإنكليزية هي خيارٌ جيدٌ إذا كانت لديك قاعدة مستخدمين واسعة ومن مختلف البلدان، لكن ضع في بالك أنَّ عدد كبيرًا ممن سيقرؤون توثيقك لا تكون اللغة الإنكليزية هي لغتهم الأم، لذا حاول استخدام لغة سهلة لا تُسبِّب لبسًا عند القراء، وإذا كان مشروعك موجّه لمنطقة أو لغة معيّنة مثل برنامج للتعرف على الكلام العربي فأنصحك حينئذٍ أن توفر التوثيق باللغة العربية.
حاول أن تكتب التوثيق كما لو كنتَ تكتب لأحد المساهمين الجدد الذين يريدون أن يطلعوا على حالة المشروع، فلا تنسَ أنَّك تريد أن يتحول المستخدمون العاديون إلى مساهمين.

تنظيم «القضايا»

القضايا (issues) هي طريقةٌ تستعمل لتتبع أو التبليغ عن العلل، أو لطلب ميزات جديدة لتضاف إلى البرنامج. توفِّر خدمات استضافة مستودعات المشاريع مفتوحة المصدر مثل GitHub و GitLab و Bitbucket طرائق لتتبع القضايا التي تُنشِئها وتسمح للمستخدمين بإنشائها. فمن المتوقع عند إطلاق مشروعك مفتوح المصدر أن تُفتَح عدِّة قضايا من قِبل مجتمع المستخدمين، لذا سيمثِّل تنظيم ووضع أولويات لهذه القضايا أمرًا مهمًا لتبيان خارطة الطريق لما عليك فعله للمشروع مستقبلًا.
ولأنَّ أي مستخدم يستطيع أن يفتح قضية، فلن تكون جميع القضايا لتبليغ العلل أو لطلب الميزات، فقد تأتيك أسئلة عبرها، أو قد تأتي طلبات لتحسينات صغيرة على واجهة المستخدم مثلًا. فمن الأفضل تنظيم هذه القضايا في أفضل شكل ممكن ومحاولة التواصل مع المستخدمين الذين أنشؤوها.
يجب أن تمثِّل القضايا مهامًا محددة عليك تنفيذها برمجيًا، لذا عليك تنظيمها حسب أهميتها. يجب أن يكون هنالك حدود للوقت والعمل الذي تنفقه أنت أو المساهمون في المشروع للقضايا المفتوحة فيه، ويمكنكم التعاون على اتخاذ القرارات والخروج بخطة قابلة للتنفيذ، وعندما تعلم أنَّك غير قادر على حل مشكلة معيّنة في الإطار الزمني المتاح لك، فيمكنك التعليق عليها وإخبار المستخدم أنَّك قرأت المشكلة وستفعل ما بوسعك تجاهها، وقد تستطيع أن تخبره بالوقت المتوقع للنظر في أمر هذه المشكلة مرةً أخرى.
أما لطلبات الميزات أو التحسينات، فيمكنك أن تسأل الشخص الذي أنشأ القضية إن كان يستطيع المساهمة في الشيفرة لتطبيق هذه الميزة، يمكنك توجيه المستخدمين إلى ملف CONTRIBUTORS.md أو إلى أيّة صفحات أخرى من التوثيق.
ولأن الأسئلة لا تمثِّل عادةً مهامًا محدَّدة، فالتعليق على السؤال لتوجيه المستخدم بلباقة إلى صفحة التوثيق هو خيارٌ ممتاز لإبقاء تفاعلك مع المستخدم احترافيًا ولطيفًا؛ وإذا لم يحتوي التوثيق على جوابٍ لهذا السؤال فحان الوقت لإضافة التوثيق الملائم، وتعبِّر عن شكرك للمستخدم لأنه دلّك على موضع النقص في التوثيق. إذا كنتَ تستقبل عددًا كبيرًا من الأسئلة عبر القضايا، فربما تفكر بإنشاء صفحة الأسئلة الشائعة (FAQ) في التوثيق، أو صفحات ويكي أو منتدى لتتيح للآخرين المساعدة والمشاركة في الإجابة عن الأسئلة.
وفي كل مرة يبلِّغ فيها أحد المستخدمين عن مشكلة، فحاول أن تكون لطيفًا معه قدر الإمكان، فتفاعل المستخدمين معك يعني أنَّ المشروع قد أعجبهم ويريدون جعله أفضل.
محاولة تنظيم القضايا ستجعل مشروعك محدثًا دومًا وسيشعر المستخدمون أنهم يأثرون فيه، لذا احذف القضايا التي تقع خارج نطاق مشروعك أو القضايا القديمة، وضع أولويات للبقية لكي يكون تقدمك في المشروع مستمرًا.

حفِّز المساهمين

كلما رحّبتَ بالمساهمين الجدد وكافأتهم على جهودهم لوجدت أنَّك تحفِّز مساهمين جدد ليشاركوا في مشروعك، ولكي تجذب المساهمين إلى المشروع فاحرص على تضمين ملف CONTRIBUTING.md في المجلد الرئيسي لمستودعك، وإشارة إلى ذاك الملف في README.md.
إذا أردتَ كتابة ملف جيد للمساهمين الجدد فيجب أن يتضمن كيفية بدء العمل على المشروع كمطوِّر، فقد تكتب دليلًا يوضح ذلك خطوةً بخطوة، أو قائمةً من الأمور التي يجب على المطورين اتباعها وتنفيذها، شارحًا كيف يمكن أن يدمجوا الشيفرة التي كتبوها بشيفرة المشروع عبر طلبية pull.
إضافةً إلى توثيق كيفية المساهمة في المشروع، فلا تنسَ أن تبقي شيفرات المشروع منظمة وسهلة القراءة، فإذا كانت الشيفرة سهلة الفهم وفيها تعليقات كثيرة تشرح ما تفعله وطريقة استخدامها موحدة ومتناسقة مع بعضها بعضًا فسيساهم ذلك في تحفيز المساهمين المحتملين على المشاركة في المشروع.
أقترح أيضًا أن تبقي على قائمة بالمساهمين، فيمكنك أن تجذب المساهمين عبر إضافتهم إلى القائمة بغض النظر عن حجم مشاركتهم (حتى تصحيح الأخطاء اللغوية هو مشاركة ومساهمة فعالة في المشروع، ويمكن أن تؤدي إلى مزيدٍ من المساهمات مستقبلًا). وهذا يعني أنَّك تقدِّر عمل المساهمين في المشروع وتشير إليهم أمام جميع مستخدمي مشروعك، مما يحمِّس بقية المستخدمين على المشاركة.

ابنِ مجتمعًا حول مشروعك

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

• التدوين
• تسجيل ونشر فيديوهات تعريفية
• إنشاء قائمة بريدية
• النشاط على مواقع التواصل الاجتماعي
• التعاون مع المشاريع الشبيهة أو المتعلقة بمشروعك والترويج لها.

عليك أن تُناسِب ترويجك للمشروع مع مجاله وعدد أعضاء الفريق الفعالين والمساهمين الذين يعملون معك.
فعندما ينمو المجتمع حول مشروعك، فيمكنك أن توفِّر مساحة أكبر للمساهمين والمستخدمين والقائمين على المشروع ليتفاعلوا، بعض تلك الخيارات تتضمن:

• برمجيات الويكي التي توفِّر توثيقًا مصانًا من المجتمع
• المنتديات لمناقشة الميزات المحتملة وللإجابة على الأسئلة
• قائمة بريدية للتفاعل مع المجتمع عبر البريد الإلكتروني

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

الخلاصة

يلعب صائن المستودع دورًا مهمًا في مجتمع البرمجيات مفتوحة المصدر الكبير. وصحيحٌ أنَّ هذا الدور يأخذ وقتًا وعملًا كبيرًا، لكن الخبرة التي تكتسبها خلال هذا العمل ستفيدك كمطوِّر وكمساهم، ولا تنسَ أنَّ الصائن اللطيف واللبق سيساعد في دفع عجلة تطوير المشروع الذي يهتم لأجله.
ترجمة –وبتصرّف– للمقال Maintaining Open-Source Software Projects لصاحبته Lisa Tagliaferri.

حقوق الصورة البارزة محفوظة لـ Freepik