مقدمة
هندسة (DevOps) تعني مجموعة من الممارسات التقنية التي تضم (Dev) أو المعروفة بـDevelopment و (Ops) أو المعروفة بـ IT Operations من أجل عمل ميكنة (automation)، وبالتالي زيادة قدرة الشركات على تسليم الخدمات والتطبيقات في أوقات قياسية وسريعة.
يشترك كل من فرق الـclient-side و الـserver-side ليصبحان فريق واحد تحت مظلة الـDevOps، حيث يقوم المهندسون بالمساهمة في جعل متابعة عملية التطوير تتم بشكل آلي، وفي بعض الحالات، يشارك فريق للجودة وأمن المعلومات خلال دورة التطوير للتطبيق، ما يجعلنا نطلق عليها اسم DevSecOps
مميزات DevOps ونقاط قوتها
-
السرعة الخارقة في تسليم الخدمات أو التطبيقات للعملاء في وقت قياسي:
تحرك بسرعة عالية حتى تتمكن من الابتكار للعملاء بشكل أسرع ، والتكيف مع الأسواق المتغيرة بشكل أفضل ، وزيادة الكفاءة في تحقيق نتائج. يمكّن نموذج DevOps المطورين وفرق العمليات من تحقيق هذه النتائج. على سبيل المثال ، تتيح الخدمات الصغيرة micro-services والتسليم المستمر Continuous Delivery للفرق امتلاك الخدمات ومن ثم إصدار التحديثات لها بشكل أسرع. -
سرعة عملية التطوير وإصدار نسخ جديدة لتطبيقاتك:
زيادة معدل إنتاج الإصدارات، حتى تتمكن من الابتكار وتحسين منتجك بشكل أسرع. كلما كان بإمكانك إطلاق ميزات جديدة وإصلاح الأخطاء بشكل أسرع ، زادت سرعة الاستجابة لاحتياجات عملائك وبناء ميزة تنافسية. -
الدقة والاعتمادية على الكود الأولي للمشروع:
تأكد من جودة تحديثات التطبيقات وتغييرات البنية الأساسية حتى تتمكن من تقديمها بشكل موثوق به بوتيرة أسرع مع الحفاظ على تجربة إيجابية للمستخدمين. -
تجهيز نظام للمساهمات بشكل أفضل:
قم ببناء فرق أكثر فاعلية في إطار نموذج DevOps، والذي يؤكد على قيم مثل الملكية والمساءلة. يتعاون المطورون وفرق العمليات بشكل وثيق ، ويتشاركون في العديد من المسؤوليات ، ويجمعون بين سير العمل. وهذا يقلل من عدم الكفاءة ويوفر الوقت (على سبيل المثال ، تقليل فترات التسليم بين المطورين والعمليات ، وكتابة التعليمات البرمجية التي تأخذ في الاعتبار البيئة التي يتم تشغيلها فيها). -
ضمان الالتزام بالمعايير الدولية للأمان
أقسام وممارسات DevOps
- البناء أو التركيب المستمر Continuous Integration
- التسليم المتواصل Continuous Delivery
- الخدمات المصغرة Microservices
- المتابعة والمراقبة Monitoring and Logging
- التواصل والتعاون Communication and Collaboration
سنقوم بالتركيز على البناء المستمر Continuous Integration، وإذا كنت لا تعرف ماذا يعنى ذلك، لا تقلق 
فالتدوينة ستساعدك خطوة بخطوة 
نكتفي بالنظريات هنا، ونجرب معا كيفية عمل DevOps ونبدأ بالمتطلبات:
1- حساب Github
2- الرغبة في تجربة شئ جديد
الكثير منا على الأقل جرب استخدام قيت هاب Github لمرة واحدة.
يحتاج المطورون عمل commits لحفظ الأكواد الجديدة من الضياع
مع كل commit يرسل متابعة آلية automated workflow على سيرفر البناء المستمر (CI server)
والذي بدوره يبلغ المطورين بشكل مستمر عن وجود مشاكل بالتحديثات الجديدة على الكود
بهذا الشكل، نستطيع تجنب كوارث قد تحدث عند دمج الأكواد الخاصة بالمشروع، والتي ستكلف وقت ومجهود وهدر للأموال بشكل كبير لحلها 
الخطوات
كما بالشكل، قمت بعمل new repository
رابط المستودع: https://github.com/sniperadmin/gh-actions-tutorial
سأستخدم في هذه التجربة مشروع بسيط بـ vuejs، لكن بالطبع يمكنك رفع أي مشروع بأي تقنية كـ Django أو Rust أو غيرها…
بعد رفع المشروع، نختر Actions
ستظهر لنا نافذة المحرر:
نلاحظ معا أن الملف بصيغة yml أو yaml => هي ليست لغة، هي عبارة عن مجموعة أوامر فقط يستطيع المبرمج فهمها،
هذه الأوامر -كما أشرنا سابقا- تكون لسيرفر البناء المستمر CI server
على سبيل المثال: نستطيع عمل test، أو تشغيل localhost server، أو عمل build أو رفع المشروع على هوست مثلا بشكل آلي
تخيل كم مرة نقوم بهذه الأشياء يدويا باستخدام أوامر الـterminal 
الآن لنتصفح المثال المرفق لكيفية كتابة أول workflow:
# This is a basic workflow to help you get started with Actions
name: CI Name # هنا نضع اسم العملية
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on: # نستخدمها لضبط توقيت بدء العملية
push: # هنا تبدأ العملية عند رفع الكود على الفرع الرئيسي ماستر
branches: [ master ]
pull_request: # وهنا تبدأ العملية عند عمل طلب سحب
branches: [ master ]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs: # كل عملية تتكون من عدة وظائف
# This workflow contains a single job called "build"
build-for-production: # هنا نعطي أي اسم يعبر عن الوظيفة التي سيقوم بها السيرفر
# The type of runner that the job will run on
runs-on: ubuntu-latest # نظام تشغيل السيرفر، وهنا يوجد خيارات كثيرة مرفقة بالصورة أسفل الكود
# Steps represent a sequence of tasks that will be executed as part of the job
steps: # هنا الخطوات أو المهمات التي سيقوم بها السيرفر
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2 # هذه الخطوة مهمة حيث تقوم بتوجيه السيرفر إلى الفولدر أو المشروع الحالي
# Runs a single command using the runners shell
- name: Run a one-line script # اسم المهمة الأولى
run: echo Hello, world! # الأمر الخاص بالمهمة الأولى
# Runs a set of commands using the runners shell
- name: Run a multi-line script # اسم المهمة الثانية
run: |
echo Add other actions to build, # الأوامر الخاصة بالمهمة الثانية
echo test, and deploy your project.
هذا المثال يوضح شكل الملف الذي سنكتب فيه التعليمات للسيرفر
نلاحظ الأمر runs-on: – إليكم أنظمة التشغيل المتاحة لسيرفر الـCI
بالمثال قد اخترنا ubuntu-latest
يمكننا كتابة workfow بكل سهولة مع الأخذ في الاعتبار أن ملفات الworkflow تكون في المكان الصحيح وهو:
/.github/workflows
سيقوم السيرفر بالبحث عن فولدر .github ويستطيع التعرف على الملفات الداخلية وتشغيلها
بعد أن تعرفنا على طريقة كتابة الworkflow بشكل مختصر، سأبدأ بكتابة أوامر بسيطة لمستودعي الخاص
كما نعلم، جميع أوامر فريمووركات الجافاسكريبت تكون في ملف package.json
لنلق نظرة على الملف الخاص بي:
سأقوم بعمل build للمشروع من أجل إنتاج نسخة الproduction والتي ستكون في فولدر اسمه dist وفيه صفحة html وملفات الجافاسكريبت
قبل البداية، سنأخذ فرع branch من الماستر حتى لا نتعامل مع الماستر بشكل مباشر
git checkout -b add-yaml
ونكتب الworkflow:
# This is a basic workflow to help you get started with Actions
name: Build CI # هنا نضع اسم العملية
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on: # نستخدمها لضبط توقيت بدء العملية
push: # هنا تبدأ العملية عند رفع الكود على الفرع الرئيسي ماستر
branches: [ master ]
pull_request: # وهنا تبدأ العملية عند عمل طلب سحب
branches: [ master ]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs: # كل عملية تتكون من عدة وظائف
# This workflow contains a single job called "build"
build-for-production: # هنا نعطي أي اسم يعبر عن الوظيفة التي سيقوم بها السيرفر
# The type of runner that the job will run on
runs-on: ubuntu-latest # نظام تشغيل السيرفر، وهنا يوجد خيارات كثيرة مرفقة بالصورة أسفل الكود
# Steps represent a sequence of tasks that will be executed as part of the job
steps: # هنا الخطوات أو المهمات التي سيقوم بها السيرفر
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2 # هذه الخطوة مهمة حيث تقوم بتوجيه السيرفر إلى الفولدر أو المشروع الحالي
# Runs a single command using the runners shell
- name: install npm # اسم المهمة الأولى
run: npm i # الأمر الخاص بالمهمة الأولى
# Runs a set of commands using the runners shell
- name: check npm version and build # اسم المهمة الثانية
run: |
npm --version # الأوامر الخاصة بالمهمة الثانية
npm run build
طبعا يمكن كتابة كل أوامر npm في مكان واحد، لكن أردت عرض كيفية كتابتها بأكثر من شكل
الآن نخبر github أن يحفظ لنا التعديلات ويرفعها على المستودع:
git add .
git commit -m "add workflow"
git push -u origin add-yaml
الآن تم رفع الكود الجديد حسب ما ظهر في الـterminal:
$ git push -u origin add-yaml
Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (5/5), 1.26 KiB | 1.26 MiB/s, done.
Total 5 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote:
remote: Create a pull request for 'add-yaml' on GitHub by visiting:
remote: https://github.com/sniperadmin/gh-actions-tutorial/pull/new/add-yaml
remote:
To https://github.com/sniperadmin/gh-actions-tutorial
* [new branch] add-yaml -> add-yaml
Branch 'add-yaml' set up to track remote branch 'add-yaml' from 'origin'.
نتوجه إلى قيت هاب:
كما نرى في الشكل التالي، السيرفر الآن يعمل:
يمكنك النقر على details لمعرفة المزيد
وكما نشاهد قد أتم السيرفر المهمة!
في حالة المثال، المهمة اكتملت بشكل ناجح (نعرفها من العلامة 
)
إذا كان هناك أخطاء، فببساطة نعدل الأخطاء ونقوم بعمل push للكود الجديد على نفس الفرع وننتظر السيرفر
بالطبع يمكننا عمل أشياء خرافية بهذه الأداة العبقرية:(كعمل deploy على هوست بشكل آلي، كل ما عليك فقط هو الاهتمام بالكود، وقيت هاب سيتولى تحديث الموقع 
)
رابط المستودع: https://github.com/sniperadmin/gh-actions-tutorial
مصادر أخرى للمزيد حول ملفات yaml:
https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions
رائع كل شيئ يمشي كما هو متوقع … شكرا نصر على المقال الرائع
مش موجود
