it-swarm.asia

هل يمكنك أن توصي بطرق لإدارة نشر الشفرة على خادم ويب يعمل بنظام Linux؟

لقد كنت دائمًا تستخدم نصًا بسيطًا للباش لنشر الكود. أنا أبتعد عن استخدام Subversion to Mercurial ولكني لا أعتقد حقًا أن برنامج التحكم في المراجعة مهم للنشر.

ما هي بعض طرق betters للقيام بذلك؟

#!/bin/sh
date=`date +%Y%m%d_%H%M%S`
tar -zcvf app-dir-$date.tar.gz app/dir 
tar -zcvf app-templates-$date.tar.gz app/templates
tar -zcvf app-media-$date.tar.gz app/media
svn export http://example.com/somepath/trunk hh/ --force
7
citadelgrad

يمكنني استخدام Mercurial لإدارة كل شيء ، بما في ذلك صفحات HTML الثابتة الخاصة بي. يجعل الحياة حقا ، حقا سهلة بالنسبة لي.

تشمل الفوائد

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

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

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

برأيي أنه يجب ألا تضطر إلى "حل" أدواتك إلا إذا لم يكن لديك خيار آخر. القيام بهذا النوع من الهزائم بغرض الحصول عليها ، ولديك خيار :)

5
Tim Post

بالإضافة إلى الاقتراحات الممتازة الواردة في الإجابات الأخرى ، قد ترغب في التفكير فيما إذا كان من المهم لك القيام بتحديث ذري.

على خادم FreeBSD الخاص بي ، أنجز هذا من خلال آليتين:

  • إصدار جميع الموارد الثابتة الخاصة بي. (على سبيل المثال http://static.example.com/images/logo.1.png أو http://static.example.com/style/main.3.css). هذا يتيح لي svn update الموقع الثابت مباشرة قبل تحديث الموقع الديناميكي ، دون القلق بشأن رؤية المستخدمين لملفات جديدة في الصفحات القديمة.

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

    cp -Rp www.site1.com.1 www.site1.com.2 (أو svn checkout)

    svn update site1.com.2 (قد تحتاج svn switch أولاً)

    ln -sf site1.com.2 www.site1.com (نقل التغييرات ذريًا إلى الإنتاج)

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

تعمل هذه الاستراتيجية بشكل جيد فقط إذا كنت لا تخلط المحتوى الذي حمّله المستخدم مع موقعك الديناميكي.

1
JasonBirch

نستخدم النملة مهمة scp ، مع المحدد المعدل . هذا يعني أنك فقط قم بتحديث الملفات التي تغيرت منذ التحميل السابق. لسوء الحظ ، يبدو أن المحدد الذي تم تعديله مصمم للاستخدام الشخصي فقط ، وليس للمشاركة مع أعضاء الفريق. يحتوي الملف cache.properties على أسماء مسار إلى دليل العمل الخاص بالمستخدم. لقد كتبنا مجموعة من أهداف النمل لتدليك الملف cache.properties في تنسيق يمكن مشاركته بين المطورين ثم تدليكه مرة أخرى إلى التنسيق الذي يحتاجه النمل. يختلف التنسيق أيضًا بين بيئة Windows وبيئة GNU/Linux.

0
Don Kirkby

أليس الهدف الكامل لاستخدام التحكم في الإصدار هو أنك لست بحاجة إلى الاهتمام بنفسك في عمل نسخة احتياطية للموقع قبل دفع التحديث؟

إذا تم القيام به بشكل صحيح ، يجب أن يكون svn update (أو ما يعادله) كافيًا ، وإذا كان من الخطأ ، فقم بإعادته إلى التزام سابق؟ هذا ما نفعله على أي حال. قم بتنفيذ جميع التغييرات ، svn update خادم التدريج ، إذا كان كل شيء على ما يرام ، ثم svn update الخادم المباشر.

0
Mark Henderson