كيفية بناء خط أنابيب نشر أولي فعال

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

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

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

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

• GitLab لرمز المضيف.
  • السبب: يفضل زبائني أن تظل أكوادهم سرية ، كما أن فئة GitLab المجانية رائعة. أيضًا ، يعد CI المجاني المدمج رائعًا. شكرا GitLab!
  • البدائل: GitHub و BitBucket و AWS CodeCommit وغيرها الكثير.
• GitLab CI لبناء واختبار ونشر الكود الخاص بنا.
  • لماذا: يتكامل مع GitLab وهو مجاني!
  • البدائل: TravisCI و Codeship و CircleCI و DIY with Fabric8 وغيرها الكثير.
• Heroku لاستضافة تطبيقنا.
  • السبب: إنه يعمل خارج الصندوق وهو النظام الأساسي المثالي للبدء. يمكنك تغيير هذا في المستقبل ، ولكن لا يلزم تشغيل كل تطبيق جديد على مجموعة Kubernetes المصممة لهذا الغرض. حتى Coinbase بدأت في Heroku.
  • البدائل: AWS و DigitalOcean و Vultr و DIY مع Kubernetes وغيرها الكثير.

المدرسة القديمة: أنشئ تطبيقًا أساسيًا وانشره في Heroku

أولاً ، دعنا نعيد إنشاء تطبيق نموذجي لشخص لا يستخدم أي خطوط أنابيب CI / CD رائعة ويريد فقط نشر تطبيقاته.

لا يهم نوع التطبيق الذي تنشئه ، لكنك ستحتاج إلى Yarn أو npm. على سبيل المثال ، أقوم بإنشاء تطبيق Ruby on Rails لأنه يأتي مع عمليات الترحيل و CLI ، ولدي التكوين مكتوب بالفعل له. مرحبًا بك لاستخدام أي إطار عمل أو لغة تفضلها ، لكنك ستحتاج إلى Yarn للقيام بالإصدار الذي أقوم به لاحقًا. أقوم بإنشاء تطبيق CRUD بسيط باستخدام بضعة أوامر فقط وبدون مصادقة.

ودعنا نختبر ما إذا كان تطبيقنا يعمل بالشكل المتوقع. تقدمت وأنشأت بعض المنشورات ، فقط للتأكد.

ودعنا ننشره في Heroku عن طريق دفع الكود الخاص بنا وتشغيل عمليات الترحيل

 $ heroku create toptal-pipeline Creating ⬢ toptal-pipeline... done https://toptal-pipeline.herokuapp.com/ | https://git.heroku.com/toptal-pipeline.git $ git push heroku master Counting objects: 132, done. ... To https://git.heroku.com/toptal-pipeline.git * [new branch] master -> master $ heroku run rails db:migrate Running rails db:migrate on ⬢ toptal-pipeline... up, run.9653 (Free) ...

أخيرًا ، دعنا نختبرها في الإنتاج

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

الايجابيات

• سريع لاقامة.
• عمليات النشر سهلة.

سلبيات

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

خط أنابيب النشر الأولي المثالي

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

يقول ما؟ انتظر - يمكنني التحدث؟

نعم ، هذا ما قصدته بشأن منحك صوتًا. كيف حالك؟

أنا بخير. هذا شعور غريب

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

أوه ، هذا سهل. مقدار الوقت الذي أضيعه. هل سبق لك أن حاولت الدفع إلى Heroku؟

نعم ، مشاهدة تنزيل تبعياتك والتطبيق الذي يتم إنشاؤه كجزء من git push أمر مروع!

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

حسنًا ، يمكنك في الواقع حل هذه المشكلة الأخيرة عن طريق ربط الأمرين بـ && ، مثل git push heroku master && heroku run rails db:migrate ، أو مجرد إنشاء نص برمجي ووضعه في التعليمات البرمجية الخاصة بك ، ولكن لا يزال ، إجابة رائعة ، الوقت والتكرار هو ألم حقيقي.

نعم ، إنه حقًا مقرف

ماذا لو أخبرتك أنه يمكنك إصلاح هذا الجزء على الفور باستخدام خط أنابيب CI / CD؟

ماذا الآن؟ ما هذا؟

يشير CI / CD إلى التكامل المستمر (CI) والتسليم / النشر المستمر (CD). كان من الصعب جدًا بالنسبة لي أن أفهم بالضبط ما كان عليه عندما كنت أبدأ لأن الجميع استخدم مصطلحات غامضة مثل "دمج التطوير والعمليات" ، ولكن ببساطة:

• التكامل المستمر: التأكد من دمج جميع التعليمات البرمجية معًا في مكان واحد. اجعل فريقك يستخدم Git وستستخدم CI.
• التسليم المستمر: التأكد من أن الكود الخاص بك جاهز باستمرار للشحن. يعني إنتاج نسخة للقراءة للتوزيع من منتجك بسرعة.
• النشر المستمر: أخذ المنتج بسلاسة من التسليم المستمر ونشره على الخوادم الخاصة بك.

أوه ، فهمت الآن. يتعلق الأمر بجعل تطبيقي ينتشر بطريقة سحرية في العالم!

مقالتي المفضلة التي تشرح CI / CD هي بواسطة Atlassian هنا. هذا يجب أن يوضح أي أسئلة لديك. على أي حال ، نعود إلى المشكلة.

نعم ، نعود إلى ذلك. كيف أتجنب عمليات النشر اليدوية؟

إعداد خط أنابيب CI / CD للنشر على Push to master

ماذا لو أخبرتك أنه يمكنك إصلاح هذا الجزء على الفور باستخدام CI / CD؟ يمكنك الدفع إلى جهاز التحكم عن بُعد ( origin ) الخاص بـ GitLab وسيتم إنتاج جهاز كمبيوتر للقيام ببساطة بدفع هذا الرمز الخاص بك إلى Heroku.

مستحيل!

نعم الطريق! دعنا نعود إلى الكود مرة أخرى.

قم بإنشاء ملف .gitlab-ci.yml التالية ، مع تبديل toptal-pipeline toptal لاسم تطبيق Heroku الخاص بك:

 image: ruby:2.4 before_script: - > : "${HEROKU_EMAIL:?Please set HEROKU_EMAIL in your CI/CD config vars}" - > : "${HEROKU_AUTH_TOKEN:?Please set HEROKU_AUTH_TOKEN in your CI/CD config vars}" - curl https://cli-assets.heroku.com/install-standalone.sh | sh - | cat >~/.netrc <<EOF machine api.heroku.com login $HEROKU_EMAIL password $HEROKU_AUTH_TOKEN machine git.heroku.com login $HEROKU_EMAIL password $HEROKU_AUTH_TOKEN EOF - chmod 600 ~/.netrc - git config --global user.email "[email protected]" - git config --global user.name "CI/CD" variables: APPNAME_PRODUCTION: toptal-pipeline deploy_to_production: stage: deploy environment: name: production url: https://$APPNAME_PRODUCTION.herokuapp.com/ script: - git remote add heroku https://git.heroku.com/$APPNAME_PRODUCTION.git - git push heroku master - heroku pg:backups:capture --app $APPNAME_PRODUCTION - heroku run rails db:migrate --app $APPNAME_PRODUCTION only: - master

ادفع هذا الأمر ، وشاهده يفشل في صفحة خطوط الأنابيب الخاصة بمشروعك. هذا لأنه يفتقد مفاتيح المصادقة لحساب Heroku الخاص بك. ومع ذلك ، فإن إصلاح ذلك بسيط إلى حد ما. ستحتاج أولاً إلى مفتاح Heroku API . احصل عليه من صفحة إدارة الحساب ، ثم أضف المتغيرات السرية التالية في إعدادات CI / CD في GitLab repo:

• HEROKU_EMAIL : عنوان البريد الإلكتروني الذي تستخدمه لتسجيل الدخول إلى Heroku
• HEROKU_AUTH_KEY : المفتاح الذي حصلت عليه من Heroku

يجب أن يؤدي هذا إلى نشر GitLab إلى Heroku في كل دفعة. بالنسبة لما يحدث:

• عند الدفع لإتقان
  • يتم تثبيت Heroku CLI والمصادقة عليه في حاوية.
  • تم دفع التعليمات البرمجية الخاصة بك إلى Heroku.
  • تم التقاط نسخة احتياطية من قاعدة البيانات الخاصة بك في Heroku.
  • يتم تشغيل الهجرات.

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

خلق بيئة مرحلية

لكن انتظر ، سؤال سريع ، ماذا يحدث لمشاكلك الخاصة بالإنتاج؟ ماذا لو واجهت خطأ غريبًا لأن بيئة التطوير الخاصة بك مختلفة جدًا عن الإنتاج؟ واجهت ذات مرة بعض المشكلات الغريبة في SQLite 3 و PostgreSQL عندما أجريت عملية ترحيل. التفاصيل تراوغني ، لكن هذا ممكن تمامًا.

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

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

Errrr - نعم ، لا. لقد أوصلتني هناك. الناس الآخرون سوف يفسدونها. ما هي وجهة نظرك ، رغم ذلك؟

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

هذا يبدو منطقيا! إذن كيف أفعل هذا؟

هنا حيث تصبح مثيرة للاهتمام. أود نشر master مباشرة في التدريج.

انتظر ، أليس هذا هو المكان الذي ننشر فيه الإنتاج الآن؟

نعم إنه كذلك ، لكننا سننتشر الآن إلى مرحلة بدلاً من ذلك.

ولكن إذا تم نشر master في مرحلة التشغيل ، فكيف ننتشر في الإنتاج؟

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

علامات Git؟ من يستخدم علامات Git ؟! لقد بدأ هذا يبدو وكأنه الكثير من العمل.

كان الأمر مؤكدًا ، لكن لحسن الحظ ، لقد قمت بكل هذا العمل بالفعل ويمكنك فقط تفريغ الكود الخاص بي وسيعمل.

أولاً ، أضف كتلة حول النشر المرحلي إلى ملف .gitlab-ci.yml الخاص بك ، لقد قمت بإنشاء تطبيق Heroku جديد يسمى toptal-pipeline-staging :

 … variables: APPNAME_PRODUCTION: toptal-pipeline APPNAME_STAGING: toptal-pipeline-staging deploy_to_staging: stage: deploy environment: name: staging url: https://$APPNAME_STAGING.herokuapp.com/ script: - git remote add heroku https://git.heroku.com/$APPNAME_STAGING.git - git push heroku master - heroku pg:backups:capture --app $APPNAME_PRODUCTION - heroku pg:backups:restore `heroku pg:backups:url --app $APPNAME_PRODUCTION` --app $APPNAME_STAGING --confirm $APPNAME_STAGING - heroku run rails db:migrate --app $APPNAME_STAGING only: - master - tags ...

ثم قم بتغيير السطر الأخير من كتلة الإنتاج الخاصة بك للتشغيل على علامات Git ذات الإصدار المعنوي بدلاً من الفرع الرئيسي:

 deploy_to_production: ... only: - /^v(?'MAJOR'(?:0|(?:[1-9]\d*)))\.(?'MINOR'(?:0|(?:[1-9]\d*)))\.(?'PATCH'(?:0|(?:[1-9]\d*)))(?:-(?'prerelease'[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*))?(?:\+(?'build'[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*))?$/ # semver pattern above is adapted from https://github.com/semver/semver.org/issues/59#issuecomment-57884619

سيؤدي تشغيل هذا الآن إلى الفشل لأن GitLab ذكي بما يكفي للسماح فقط للفروع "المحمية" بالوصول إلى متغيراتنا السرية. لإضافة علامات الإصدار ، انتقل إلى صفحة إعدادات مستودع مشروع GitLab وأضف v* إلى العلامات المحمية.

دعنا نلخص ما يحدث الآن:

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

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

اختبار كل دفعة

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

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

أضف كتلة test :

 test: stage: test variables: POSTGRES_USER: test POSTGRES_PASSSWORD: test-password POSTGRES_DB: test DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSSWORD}@postgres/${POSTGRES_DB} RAILS_ENV: test services: - postgres:alpine before_script: - curl -sL https://deb.nodesource.com/setup_8.x | bash - apt-get update -qq && apt-get install -yqq nodejs libpq-dev - curl -o- -L https://yarnpkg.com/install.sh | bash - source ~/.bashrc - yarn - gem install bundler --no-ri --no-rdoc - bundle install -j $(nproc) --path vendor - bundle exec rake db:setup RAILS_ENV=test script: - bundle exec rake spec - bundle exec rubocop

دعنا نلخص ما يحدث الآن:

• عند كل دفعة أو طلب دمج
  • تم إعداد Ruby و Node في حاوية.
  • تم تثبيت التبعيات.
  • تم اختبار التطبيق.
• عند الضغط لإتقان ، أو دفع الالتزام الموسوم ، وفقط إذا نجحت جميع الاختبارات
  • يتم تثبيت Heroku CLI والمصادقة عليه في حاوية.
  • تم دفع التعليمات البرمجية الخاصة بك إلى Heroku.
  • يتم التقاط نسخة احتياطية من إنتاج قاعدة البيانات الخاصة بك في Heroku.
  • يتم التخلص من النسخة الاحتياطية في بيئة التدريج الخاصة بك.
  • يتم تشغيل عمليات الترحيل على قاعدة البيانات المرحلية.
• عند الضغط على إصدار ذي علامة دلالية ، الالتزام ، وفقط إذا نجحت جميع الاختبارات
  • يتم تثبيت Heroku CLI والمصادقة عليه في حاوية.
  • تم دفع التعليمات البرمجية الخاصة بك إلى Heroku.
  • يتم التقاط نسخة احتياطية من إنتاج قاعدة البيانات الخاصة بك في Heroku.
  • يتم تشغيل عمليات الترحيل في قاعدة بيانات الإنتاج.

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

الإصدار الدلالي التلقائي

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

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

حسنًا ، لدي سبب وجيه لفعل ما سأفعله.

صلوا ، أنوروني.

اعتدت أن أكون مثلك. كنت سعيدًا بهذا الإعداد ، ولكن بعد ذلك أخطأت. تسرد git tag العلامات بترتيب أبجدي ، v0.0.11 أعلى من v0.0.2 . ذات مرة قمت بوضع علامة عرضية على إصدار واستمرت في القيام بذلك لنحو ستة إصدارات حتى رأيت خطئي. وذلك عندما قررت أتمتة هذا أيضًا.

نحن نعيد الكرة مرة أخرى

حسنًا ، حسنًا ، لدينا قوة npm تحت تصرفنا ، لذلك وجدت حزمة مناسبة: Run yarn add --dev standard-version وأضف ما يلي إلى ملف package.json الخاص بك:

 "scripts": { "release": "standard-version", "major": "yarn release --release-as major", "minor": "yarn release --release-as minor", "patch": "yarn release --release-as patch" },

أنت الآن بحاجة إلى القيام بشيء أخير ، تكوين Git لدفع العلامات افتراضيًا. في الوقت الحالي ، تحتاج إلى تشغيل git push --tags لدفع العلامة لأعلى ، ولكن القيام بذلك تلقائيًا على git push العادي هو أمر بسيط مثل تشغيل git config --global push.followTags true .

لاستخدام خط الأنابيب الجديد ، متى أردت إنشاء إصدار تشغيل:

• yarn patch لإصدارات التصحيح
• yarn minor طفيف للإصدارات الطفيفة
• yarn major رئيسي للإصدارات الرئيسية

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

الآن بعد أن أكملت أخيرًا خط الأنابيب الخاص بك ، دعنا نلخص كيفية استخدامه!

• اكتب الكود.
• قم بإلزامها وادفعها للاختبار ونشرها على مراحل.
• استخدم yarn patch لوضع علامة على إصدار التصحيح.
• git push لدفعها إلى الإنتاج.

ملخص وخطوات أخرى

لقد خدشت للتو سطح ما هو ممكن مع خطوط أنابيب CI / CD. هذا مثال بسيط إلى حد ما. يمكنك فعل الكثير من خلال تبديل Heroku بـ Kubernetes. إذا قررت استخدام GitLab CI ، فاقرأ مستندات yaml لأن هناك الكثير الذي يمكنك القيام به عن طريق تخزين الملفات مؤقتًا بين عمليات النشر أو حفظ العناصر الأثرية!

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

في النهاية ، عندما يبدأ تطبيقك في التعقيد ويتطلب تبعيات على مستوى النظام ، قد تحتاج إلى استخدام حاوية. عندما يحدث ذلك ، راجع دليلنا: بدء استخدام Docker: Simplifying Devops.

هذا التطبيق النموذجي مباشر بالفعل ، ويمكنك العثور على الكود المصدري له هنا.