أتمتة نشر تطبيقات Next.js: دليل شامل لاستخدام GitHub Actions مع AWS S3

تكمن روعة تطبيقات الويب الساكنة وخصوصاً تلك المبنية باستخدام Next.js في مرونتها الفائقة، حيث يمكن استضافتها في أي مكان تقريباً بالاعتماد على خدمة تخزين الكائنات، مثل خدمة AWS S3. لكن عملية التحديث اليدوي للملفات في كل مرة قد تكون مرهقة وتستهلك الكثير من الوقت والجهد. هنا يبرز السؤال الجوهري: كيف يمكننا الاستفادة من GitHub Actions لأتمتة عملية النشر المستمر لتطبيقاتنا على AWS S3 بكفاءة وفعالية؟

ما هي GitHub Actions؟

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

ما هي AWS S3؟

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

ما هو النشر المستمر (Continuous Deployment)؟

النشر المستمر (Continuous Deployment)، والذي يُشار إليه غالباً بالاختصار CD، هو ممارسة برمجية تهدف إلى الحفاظ على الكود في حالة قابلة للنشر بشكل دائم، ونشره تلقائياً أو في دورات قصيرة ومتكررة. في سياق استخدامنا لهذا الدليل، سنقوم بتهيئة مشروعنا بحيث يتم نشر موقع الويب الخاص بنا تلقائياً في أي وقت يتم فيه دفع تحديث جديد أو دمجه مع الفرع الرئيسي (main branch) في مستودع Git.

ما الذي سنقوم ببنائه؟

سنبدأ أولاً بإنشاء تطبيق Next.js بسيط باستخدام القالب الافتراضي، ونهيئه ليتم تجميعه كملفات ساكنة. إذا كنت لا ترغب في إنشاء مشروع Next.js، يمكنك المتابعة بملف HTML بسيط دون الحاجة لتشغيل أي أوامر بناء. لكن Next.js يمثل طريقة عصرية لبناء تطبيقات الويب الديناميكية، لذا سنبدأ من هناك. بعد تجهيز ملفات موقعنا، سنقوم بإنشاء وتهيئة حاوية S3 bucket في AWS لاستضافة موقعنا. أخيراً، سنُنشئ سير عمل جديد في GitHub Actions يقوم بتحديث ملفات الموقع تلقائياً في S3 في كل مرة يحدث فيها تغيير جديد على فرعنا الرئيسي (main branch).

الخطوة 0: إعداد مشروع Next.js جديد على GitHub

للبدء، سنستخدم القالب الافتراضي لـ Next.js. بعد الانتقال إلى المجلد الذي ترغب في إنشاء مشروعك فيه، قم بتشغيل الأمر التالي:

yarn create next-app my-static-website # or npx create-next-app my-static-website

ملاحظة: لا تتردد في استبدال my-static-website بالاسم الذي تختاره لمشروعك. سنستخدم هذا الاسم في بقية هذا الدليل. إذا انتقلت إلى هذا المجلد وقمت بتشغيل أمر التطوير، يجب أن تكون قادراً على بدء تشغيل خادم التطوير بنجاح.

cd my-static-website yarn dev # or npm run dev

بعد ذلك، دعنا نهيئ مشروعنا ليتم تجميعه بشكل ساكن. داخل ملف package.json، قم بتحديث السكربت build ليصبح كالتالي:

 "build" : "next build && next export" ,

سيقوم هذا الأمر بإخبار Next.js بأخذ الموقع وتصديره إلى ملفات ساكنة، والتي سنستخدمها لاستضافة الموقع. يمكننا اختبار ذلك عن طريق تشغيل الأمر:

yarn build # or npm run build

وبعد الانتهاء، يمكننا النظر داخل المجلد out ورؤية جميع ملفات موقعنا الجديد.

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

يمكنك متابعة التغييرات (commits) التي قمنا بها في هذه الخطوة:

• إضافة مشروع Next.js الأولي عبر Create Next App
• تهيئة Next.js لتصدير المشروع كملفات ساكنة

الخطوة 1: إنشاء ونشر مشروع Next.js يدوياً إلى حاوية S3 جديدة

للبدء بحاوية S3 الجديدة، قم أولاً بتسجيل الدخول إلى حساب AWS الخاص بك وانتقل إلى خدمة S3.

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

بمجرد تهيئة حاوية S3 كموقع ويب، يمكننا العودة إلى مجلد مشروع Next.js الخاص بنا، وتشغيل أمر البناء (build command)، ثم تحميل جميع ملفاتنا من المجلد out إلى حاوية S3 الجديدة.

وبمجرد تحميل تلك الملفات وتهيئة حاوية S3 لاستضافة موقع الويب، يجب أن نكون قادرين الآن على رؤية مشروعنا مباشراً على الويب!

الخطوة 2: إنشاء سير عمل جديد في GitHub Action لبناء مشروع Next.js تلقائياً

للبدء، سنحتاج إلى إنشاء سير عمل جديد (workflow). إذا كنت على دراية بـ GitHub Actions، يمكنك إنشاء واحد يدوياً، ولكننا سنتناول بسرعة كيفية القيام بذلك عبر واجهة المستخدم. انتقل إلى علامة التبويب Actions في مستودع GitHub الخاص بك وانقر على “set up a workflow yourself.”

يوفر GitHub قالباً أولياً يمكننا استخدامه لسير العمل الخاص بنا، على الرغم من أننا سنحتاج إلى إجراء بعض التغييرات. دعنا نقوم بما يلي:

• (اختياري): أعد تسمية الملف إلى deploy.yml
• (اختياري): أعد تسمية سير العمل إلى CD (لأنه يختلف قليلاً عن CI)
• (اختياري): أزل جميع التعليقات لتسهيل القراءة
• أزل تعريف pull_request في الخاصية on
• أزل جميع الخطوات (steps) باستثناء uses: actions/checkout@v2

لذا، في هذه المرحلة، يجب أن يتبقى لدينا ما يلي:

 name: CD on: push: branches: [ main ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2

سيقوم هذا الكود وحده بتشغيل عملية تقوم بإنشاء نسخة جديدة من Ubuntu وتستخرج الكود من GitHub في أي وقت يتم فيه دفع تغيير جديد إلى الفرع main.
بعد ذلك، بمجرد استخراج الكود الخاص بنا، نريد بناءه (build). سيسمح لنا هذا بأخذ هذا الإخراج ومزامنته مع S3. ستختلف هذه الخطوة قليلاً اعتماداً على ما إذا كنت تستخدم yarn أو npm لمشروعك.

إذا كنت تستخدم Yarn:

إذا كنت تستخدم yarn، ضمن تعريف steps، أضف ما يلي:

 - uses: actions/setup-node@v1 with: node-version: 12 - run: npm install -g yarn - run: yarn install --frozen-lockfile - run: yarn build

إذا كنت تستخدم npm:

إذا كنت تستخدم npm، أضف ما يلي:

 - uses: actions/setup-node@v1 with: node-version: 12 - run: npm ci - run: npm run build

بين هاتين المجموعتين من الخطوات، ما نقوم به هو:

• **إعداد Node.js**: هذا لكي نتمكن من استخدام npm وNode.js لتثبيت وتشغيل سكربتاتنا.
• **تثبيت Yarn (خاص بـ Yarn فقط)**: إذا كنا نستخدم yarn، نقوم بتثبيته كاعتمادية عامة (global dependency) حتى نتمكن من استخدامه.
• **تثبيت الاعتماديات**: نقوم بتثبيت اعتماديات مشروعنا ونستخدم أمراً محدداً يضمن استخدام ملف القفل (lock file) المتاح لتجنب أي ترقيات غير متوقعة للحزم.
• **البناء (Build)**: أخيراً، نقوم بتشغيل أمر البناء الخاص بنا الذي سيقوم بتجميع مشروع Next.js في المجلد out!

والآن يمكننا الالتزام بهذا الملف مباشرةً بفرعنا main، مما سيؤدي إلى بدء تشغيل جديد لسير العمل الخاص بنا والذي يمكننا رؤيته في علامة التبويب Actions.

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

يمكنك متابعة الالتزام (commit) لهذه الخطوة!

الخطوة 3: تهيئة GitHub Action لنشر موقع ويب ساكن على S3

الآن بعد أن أصبحنا نبني مشروعنا تلقائياً، نريد تحديث موقعنا على S3 بشكل آلي. للقيام بذلك، سنستخدم GitHub Action المسمى aws-actions/configure-aws-credentials بالإضافة إلى واجهة سطر الأوامر لـ AWS (AWS CLI).
سيقوم GitHub Action الذي نستخدمه بأخذ بيانات اعتماد AWS وتكوينها وإتاحتها للاستخدام طوال دورة حياة سير العمل. في الوقت الحالي، تتيح لنا نسخة Ubuntu التي يوفرها GitHub Actions استخدام AWS CLI حيث تأتي مضمنة. لذلك، سنكون قادرين على استخدام أوامر CLI مباشرة في سير العمل الخاص بنا.
بدلاً من ذلك، يمكننا استخدام S3 Sync action. ولكن باستخدام AWS CLI، نكتسب مرونة أكبر لتخصيص إعداداتنا، ويمكننا استخدامه لأوامر CLI إضافية، ومن الجيد أيضاً التعرف على AWS CLI بشكل عام.
للبدء، دعنا نضيف المقتطف التالي كخطوات إضافية في سير العمل الخاص بنا:

 - uses: aws-actions/configure-aws-credentials@v1 with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: us-east-1

ما سيفعله الكود أعلاه هو استخدام إجراء تكوين بيانات اعتماد AWS لإعداد مفتاح الوصول (Access Key) ومفتاح السر (Secret Key) والمنطقة (region) الخاصة بنا بناءً على إعداداتنا. يمكن تخصيص منطقة AWS Region لتناسب المنطقة التي تستخدمها عادةً مع حساب AWS الخاص بك. أنا في شمال شرق الولايات المتحدة، لذلك سأبقيها us-east-1.
مفتاح الوصول (Access Key) ومفتاح السر (Secret Key) هما بيانات اعتماد ستحتاج إلى إنشائها باستخدام حساب AWS الخاص بك. طريقة إعداد الكود الخاص بنا هي أننا سنخزن هذه القيم داخل GitHub Secrets، مما سيمنع تسرب هذه المفاتيح. عند تشغيل الإجراء، يقوم GitHub بتغيير هذه القيم إلى نجوم (***) حتى لا يتمكن الأشخاص من الوصول إلى هذه المفاتيح.
لإعداد هذه الأسرار، نريد أولاً إنشاء مفاتيح الوصول في AWS. انتقل إلى وحدة تحكم AWS. ضمن قائمة المستخدم، حدد My Security Credentials، ثم حدد Create access key.

سيوفر لك هذا قيمتين: معرف مفتاح الوصول (Access key ID) ومفتاح الوصول السري (Secret access key). احفظ هذه القيم، حيث لن تتمكن من الوصول إلى مفتاح السر مرة أخرى.

ملاحظة هامة: تذكر ألا تقوم بتضمين مفتاح الوصول ومفتاح السر مباشرة داخل الكود الخاص بك. قد يؤدي ذلك إلى اختراق بيانات اعتماد AWS الخاصة بك.
بعد ذلك، داخل مستودع GitHub، انتقل إلى Settings، ثم Secrets، ثم حدد New secret. هنا سنقوم بإضافة مفاتيح AWS الخاصة بنا باستخدام الأسرار التالية:

• AWS_ACCESS_KEY_ID: معرف مفتاح الوصول الخاص بك في AWS.
• AWS_SECRET_ACCESS_KEY: مفتاح السر الخاص بك في AWS.

وبمجرد الحفظ، يجب أن يكون لديك سِران جديدان.

الآن بعد أن قمنا بتهيئة بيانات الاعتماد الخاصة بنا، يجب أن نكون جاهزين لتشغيل الأمر لمزامنة مشروعنا مع S3. داخل GitHub Action، أضف الخطوة التالية:

 - run: aws s3 sync ./out s3://[bucket-name]

ملاحظة: تأكد من استبدال [bucket-name] باسم حاوية S3 الخاصة بك. سيؤدي هذا الأمر إلى تشغيل مزامنة مع حاوية S3 المحددة لدينا، باستخدام محتويات المجلد out، وهو المكان الذي يتم فيه بناء مشروعنا.
والآن، إذا قمنا بالالتزام بتغييراتنا، يمكننا رؤية أن الإجراء الخاص بنا يتم تشغيله تلقائياً بمجرد الالتزام بفرع main، حيث نقوم ببناء مشروعنا ومزامنته مع S3!

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

ولكن إذا قمت بإجراء تغيير على الكود، مثل تغيير عنوان الصفحة الرئيسية داخل ملف pages/index.js وقمت بالالتزام بهذا التغيير:

<h1 className={styles.title}> Colby 's <a href="https://nextjs.org">Next.js!</a> Site </h1>

يمكننا رؤية أن تغييرنا يؤدي إلى بدء تشغيل سير العمل:

وبمجرد انتهاء سير العمل الخاص بنا، يمكننا رؤية أن محتوانا قد تم تحديثه تلقائياً على موقعنا:

يمكنك متابعة الالتزامات (commits) لهذه الخطوة:

• إضافة تهيئة AWS وأمر مزامنة S3
• تحديث العنوان لاختبار سير العمل

ماذا يمكننا أن نفعل أيضاً؟

إعداد CloudFront

لم يكن الهدف من هذا المقال هو استعراض العملية الكاملة لتهيئة موقع ويب لـ AWS، ولكن إذا كنت تستضيف موقعاً على S3، فقد ترغب أيضاً في تضمين CloudFront أمامه. يمكنك الاطلاع على دليلي الآخر الذي يشرح كيفية إعداد CloudFront بالإضافة إلى دليل خطوة بخطوة لإنشاء الموقع في S3.

إلغاء صلاحية ذاكرة التخزين المؤقت لـ CloudFront (Cache Invalidation)

إذا كان موقعك على S3 خلف CloudFront، فمن المحتمل أنك سترغب في التأكد من أن CloudFront لا يقوم بتخزين التغييرات الجديدة مؤقتاً. باستخدام AWS CLI، يمكننا أيضاً تشغيل عملية إلغاء صلاحية ذاكرة التخزين المؤقت (cache invalidation) مع CloudFront للتأكد من أنه يجلب أحدث التغييرات. تحقق من الوثائق هنا لمعرفة المزيد.

نشر طلبات السحب (Pull Request Deployments)

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

الخلاصة التقنية

يُظهر هذا الدليل بوضوح كيف يمكن لدمج GitHub Actions مع AWS S3 أن يُحدث ثورة في عملية نشر تطبيقات Next.js الساكنة. من خلال أتمتة كل خطوة، بدءاً من البناء وحتى المزامنة، نضمن نشر تحديثات سريعة وموثوقة، مما يقلل من الأخطاء البشرية ويوفر وقتاً ثميناً للمطورين. هذه الاستراتيجية لا تعزز كفاءة سير العمل فحسب، بل تمكّن الفرق أيضاً من التركيز على تطوير الميزات بدلاً من الانشغال بالعمليات اليدوية المتكررة. إن تبني النشر المستمر (CD) بهذه الطريقة هو خطوة أساسية نحو تحقيق دورة حياة تطوير برمجيات أكثر رشاقة وفعالية.