GIT لمواقع الويب / ما بعد الاستقبال / فصل مواقع الاختبار والإنتاج

Question

أنا أستخدم GIT لإدارة التعليمات البرمجية المصدر لموقع الويب الخاص بي ونشرها ، ولدي حاليًا اختبار المواقع المباشرة والمعيشة في نفس المربع. بعد هذا المورد http://toroid.org/ams/git-website-howto في الأصل ، توصلت إلى البرنامج النصي التالي لما بعد الاسترداد للتمييز بين الدفعات إلى موقعي المباشر ويدفع إلى موقع الاختبار الخاص بي:

while read ref
do
  #echo "Ref updated:"
  #echo $ref -- would print something like example at top of file
  result=`echo $ref | gawk -F' ' '{ print $3 }'`
  if [ $result != "" ]; then
    echo "Branch found: "
    echo $result
    case $result in
      refs/heads/master )
        git --work-tree=c:/temp/BLAH checkout -f master
        echo "Updated master"
        ;;
      refs/heads/testbranch )
        git --work-tree=c:/temp/BLAH2 checkout -f testbranch
        echo "Updated testbranch"
        ;;
      * )
        echo "No update known for $result"
        ;;
    esac
  fi
done
echo "Post-receive updates complete"

ومع ذلك ، لديّ شكوك في أن هذا أمر آمن بالفعل :) أنا لست خبيرًا في غيت حتى لا نهاية.

لذلك بعض الأسئلة:

1. هل هذا آمن؟

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

3. هل هناك شيء أفتقده؟ هل هناك طريقة مختلفة ونظيفة للتمييز بين عمليات النشر والاختبار عند استخدام GIT لإدارة المواقع الإلكترونية؟

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

شكرا لك -walt

ملاحظة - البرنامج النصي الذي توصلت إليه من أجل إعادة الشراء المتعددة (وأنا أستخدم ما لم أسمع أفضل) كما يلي:

sitename=`basename \`pwd\``

while read ref
do
  #echo "Ref updated:"
  #echo $ref -- would print something like example at top of file
  result=`echo $ref | gawk -F' ' '{ print $3 }'`
  if [ $result != "" ]; then
    echo "Branch found: "
    echo $result
    case $result in
      refs/heads/master )
        git checkout -q -f master
        if [ $? -eq 0 ]; then
            echo "Test Site checked out properly"
        else
            echo "Failed to checkout test site!"
        fi
        ;;
      refs/heads/live-site )
        git push -q ../Live/$sitename live-site:master
        if [ $? -eq 0 ]; then
            echo "Live Site received updates properly"
        else
            echo "Failed to push updates to Live Site"
        fi
        ;;
      * )
        echo "No update known for $result"
        ;;
    esac
  fi
done
echo "Post-receive updates complete"

ثم إعادة الريبو في ../live/rondsitename (هذه هي "عارية" مع أشجار العمل المضافة بعد init) لديها ما بعد الاستقبال الأساسي:

git checkout -f
if [ $? -eq 0 ]; then
    echo "Live site `basename \`pwd\`` checked out successfully"
else
    echo "Live site failed to checkout"
fi

Answer 1

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

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

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

يعد استخدام GIT لنشر موقع الويب الخاص بك فكرة جيدة جدًا ، فهناك الكثير من الأشخاص الآخرين الذين يقومون بذلك (مثل Rob Conery). إذا كان لديك موقع مباشر واختبار على أي حال ، فيجب أن يكون لديك فروع منفصلة لهم في مستودعك ، وتم إعداده كفروع تتبع عن بُعد على مستودعات الخادم المقابلة. يصبح سير العمل الخاص بك سهلاً مثل العمل في فرع الاختبار الخاص بك ، وادفعه لاختباره واختباره ودمجه للعيش ودفع مباشرة.

بصراحة ، لا تجعل الأمر صعبًا جدًا على نفسك.

Answer 2

أعتقد أن كلا الاتجاهين ستعمل.

يمكنك أيضًا استخدام "GIT Archive Master | Tar -C C:/Temp/blah -x" و "GIT Archive Live -Site | SSH Live -Site 'Tar -C/var/www -x'".

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

قد تكون تحديثات الموقع المباشر يجب تشغيلها يدويًا بعد اختبار إصدار "الاختبار"؟

Answer 3

لقد تابعت أيضًا نفس الدليل في Toroid.org ، لكنني أود أن أشير إلى أنه على الرغم من أنك بدأت بمستودع عاري ، عن طريق إضافة دليل عمل ، من المحتمل أن تكون هناك حاجة إلى معالجة إضافية. لقد وجدت أن الخطاف التالي مفيد إذا كان لديك محتوى قد يتغير ديناميكيًا أو غير ذلك ولا يريد أن يفقد البيانات عند استخدامه git checkout -f

ما قبل الاستقبال

#!/bin/sh
git add -A
git diff --quiet --cached
if [ $? -gt 0 ]; then
    git commit --quiet -m "autocommit"
    echo "Working Directory was out of sync. Pull to receive updated index."
    exit 1
fi

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

ما بعد الاستقبال

#!/bin/sh
git checkout -f
echo "Working directory synced."

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