أتمتة مهام المشروع باستخدام Bash على Linux

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

الحل العملي هو أتمتة المهام عبر Bash: أوامر موحدة، نتائج ثابتة، وسرعة أعلى في التشغيل والصيانة. في هذا الدرس سنبني Workflow بسيط وقابل للتوسع.

لماذا Bash Automation مهمة للمشاريع؟

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

الخطوة 1: تنظيم مجلد السكربتات داخل المشروع

ابدأ بهيكل بسيط يسهل صيانته:

mkdir -p scripts
chmod 755 scripts

مثال عملي على البنية:

project/
  scripts/
    deploy.sh
    backup.sh
    healthcheck.sh
  app/
  README.md

الخطوة 2: قالب Bash احترافي وآمن

اعتمد هذا القالب كبداية لأي سكربت:

#!/usr/bin/env bash
set -euo pipefail

log() {
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*"
}

main() {
  log "Start task"
  # Your commands here
  log "Task completed"
}

main "$@"

السطر set -euo pipefail مهم جدا لأنه يوقف السكربت عند أي فشل بدل الاستمرار في حالة غير آمنة.

الخطوة 3: سكربت نشر بسيط مع اختبار قبل إعادة التشغيل

#!/usr/bin/env bash
set -euo pipefail

PROJECT_DIR="/var/www/myapp"

cd "$PROJECT_DIR"
git pull origin main
npm ci
npm test
sudo systemctl restart myapp

echo "Deploy done successfully"

احفظه في scripts/deploy.sh ثم نفّذ:

chmod +x scripts/deploy.sh
./scripts/deploy.sh

الخطوة 4: سكربت نسخ احتياطي تلقائي

#!/usr/bin/env bash
set -euo pipefail

BACKUP_DIR="/opt/backups"
SOURCE_DIR="/var/www/myapp"
STAMP="$(date +%F-%H%M)"

mkdir -p "$BACKUP_DIR"
tar -czf "$BACKUP_DIR/myapp-$STAMP.tar.gz" "$SOURCE_DIR"
find "$BACKUP_DIR" -type f -name "myapp-*.tar.gz" -mtime +7 -delete

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

الخطوة 5: جدولة السكربتات باستخدام cron

مثال: تشغيل النسخ الاحتياطي يوميا على 02:30:

crontab -e
30 2 * * * /var/www/myapp/scripts/backup.sh >> /var/log/myapp-backup.log 2>&1

متى cron يكفي ومتى تحتاج أداة أكبر؟

نوع المهمة	الخيار المناسب
مهمة دورية بسيطة (backup/log cleanup)	cron غالبا يكفي
مهام مرتبطة بخدمات النظام	systemd timers خيار أقوى
Pipeline بناء واختبارات ونشر	يفضل CI/CD (GitHub Actions, GitLab CI...)

Best Practices لأتمتة Bash في الإنتاج

• لا تخزن كلمات المرور أو المفاتيح داخل السكربت
• تحقق من وجود الملفات والأوامر قبل التنفيذ
• سجّل الخطوات المهمة في ملفات log واضحة
• استخدم أكواد خروج صحيحة عند الفشل
• اختبر على staging قبل production

Checklist قبل اعتماد أي Bash Script

1. السكربت قابل للتنفيذ عبر chmod +x
2. set -euo pipefail مفعلة
3. المسارات معرفة كمتغيرات واضحة
4. الـ logs محفوظة ويمكن الرجوع لها
5. تم الاختبار في بيئة آمنة قبل الإنتاج

تمرين سريع (15 دقيقة)

داخل مشروع تجريبي، نفذ هذا التسلسل:

mkdir -p scripts
cat > scripts/healthcheck.sh << 'EOF'
#!/usr/bin/env bash
set -euo pipefail
systemctl is-active nginx
echo "Nginx is healthy"
EOF
chmod +x scripts/healthcheck.sh
./scripts/healthcheck.sh

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

الأسئلة الشائعة (FAQ)

هل Bash كاف لكل أنواع الأتمتة؟

يكفي جدا للمهام التشغيلية اليومية، لكن workflows الكبيرة قد تحتاج CI/CD.

هل يمكن تشغيل سكربتات Bash بدون root؟

نعم، ويفضل ذلك. استخدم أقل صلاحيات ممكنة، وفعّل sudo فقط عند الضرورة.

كيف أعرف أن السكربت آمن؟

عبر التحقق من المدخلات، منع الأسرار داخل السكربت، وتسجيل الأخطاء بوضوح.