التحكم في الإصدار المستمر
https://stackoverflow.com/questions/688546
-
22-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لم أر نظام تحكم مستمر في الإصدار - نظام يحفظ التغييرات في الكود الخاص بك أثناء قيامك بتطويرها ، بدلاً من انتظار تسجيل رسمي. سيتم حفظ التغييرات على أنها "لم يتم التحقق منها" بالطبع ، لكنها ستعمل يتم حفظها بعيدًا للنسخ الاحتياطي ، وعرضها من قبل الآخرين قبل أن تقوم بالفعل بالتحقق الرسمي.
لم أر هذا ، وأتساءل عما إذا كان ذلك ، أو شيء من هذا القبيل ، موجود ، والأسباب التي قد تكون أو لا تكون فكرة جيدة.
في الوقت الحالي ، يفكر المبرمجون في التحكم في التعليمات البرمجية المصدر على أنه دمج حزم من التعليمات البرمجية ، ولكن لماذا لا تجعل هذه الحزم أصغر وتتكامل بشكل مستمر؟
-آدم
المحلول
في الوقت الحالي ، يفكر المبرمجون في التحكم في التعليمات البرمجية المصدر على أنه دمج حزم من التعليمات البرمجية ، ولكن لماذا لا تجعل هذه الحزم أصغر وتتكامل بشكل مستمر؟
أود أن أقول أن DVCs تقوم بالفعل بذلك بشكل أساسي الآن ، ليس لأنها لا مركزية ، ولكن لأن الالتزام أسرع بكثير .. مع git ارسل في كثير من الأحيان أكثر من SVN .. كما يجعل من السهل ارتكاب "قطع" أو محددة من الكود (باستخدام git add -i أو git gui) ، وهو أكثر تركيزًا بشكل عام على تتبع خطوط التعليمات البرمجية ، بدلاً من الملفات الكاملة (مثل VCs "التقليدية" مثل التخريب)
وأيضًا ، فإن الطريقة التي تعمل بها git بطبيعتها تعني ، كما قلت ، "سيتم حفظ التغييرات على أنها" لم يتم التحقق منها "بالطبع" .. عندما تلتزم ، تكون التغييرات محلية ، ثم تدفعها إلى الجهاز البعيد باستخدام منفصلة أمر .. يمكنك الالتزام في كل مرة تقوم فيها بحفظها ، ثم إعادة صيدهم في التزام واحد إذا كنت ترغب في ذلك.
أما بالنسبة للأداة التي تقوم "بالتحكم المستمر في الإصدار" ، فيمكنك القيام بذلك ببساطة مع برنامج نصي Shell ، شيء مثل ..
while [ 1 ]; do
git add -a && git commit -m "Autocommit at $(date)";
sleep 10;
done
هناك نص ، CACM (جيثب) ، الذي يفعل شيئًا مشابهًا
CACM] يشاهد دليلًا محددًا ، ويرتكب جميع التغييرات على مستودع GIT المستقل.
لاستخدام فقط افعل:
cacm --repo dir_of_git_repo --watch dir_to_watch
لست متأكدًا من سبب رغبتك في القيام بذلك .. أجد واحدة من أكثر الأشياء المفيدة حول استخدام VCS هي مختلفة لما قمت بتغييره (منذ الالتزام الأخير). يبدو أن وجود ارتباطات ثابتة/آلية سيكون مجرد ضوضاء ..
أيضا ، محرر النص "E" لديه ميزة مثيرة للاهتمام ، وتصور تاريخ التراجع ، مع المتفرعة. هناك المدونة على ذلك مع لقطات الشاشة.
نصائح أخرى
إن مهمة التنقيح التلقائي المستمر ليست مهمة لنظام الإصدار ، ولكن للمحرر. عندما ترى إصدارًا جديدًا في نظام الإصدار ، يجب أن يمثل تغييرًا ذا معنى من الإصدارات الأخرى ، وليس كل كلمة نصفها.
يحتوي Eclipse على ميزة تسمى "التاريخ المحلي" تفعل ذلك بالضبط. سوف يحتفظ بنسخة من ملفات المصدر الخاصة بك بين الحفظ. حتى أنه يتبع المجلدات المحذوفة لك. لقد حفظ مؤخرتي عدة مرات. يمكنك رؤية التاريخ المحلي كعنصر تحكم في الإصدار منخفض المستوى يحدث فقط على الجهاز المحلي الخاص بك. الجانب السلبي لهذا بالطبع عندما تعمل على جهاز مختلف ، سيكون لديك تاريخ محلي مختلف.
لقد رأيت بعض المكونات الإضافية القائمة على DVCs المختلفة ، ولكن لا يمكن أن تكون هذه سوى ذكية للغاية. في الحقيقة ، الشيء المثالي الذي يجب القيام به هو تخزين المستودع على نظام ملفات النسخ على المكاتب ، بحيث يتم الاحتفاظ بهذه الإصدارات الحبيبية المتكررة (وغير القابلة للتغيير) من ملفات DVC.
كما قال آخرون ، أفضل تقديم العديد من الالتزامات الصغيرة. مع DVCs ، لا داعي للقلق بشأن كسر الجذع أو الفرع الرئيسي ، وادفع فقط بعد الانتهاء .. لا تقلق بشأن المراجعات السامة أثناء تحرير الملفات.
على Linux ، أنا أستخدم Ext3cow لتخزين مستودعات HG/GIT الخاصة بي. هذا يعطيني نوع الوظيفة التي تصفها. من المحزن أن أقول ، لا أعرف أي شيء مثله محمول خارج لينكس. ربما سيأتي بعض فريق مجنون مع واحد في بيثون.
لقد ظهر هذا السؤال عدة مرات من قبل (على الرغم من كل منها في سياق مختلف) ، لذا فإن الحاجة إلى شيء مثل Ext3Cow (ولكن المحمول) واضح. ومع ذلك ، لا أريد ذلك الانتفاخ في DVCs نفسها ، وخاصة على الأشجار الضخمة.
أعتقد أنك بحاجة حقًا إلى طلب هذا من نظام الملفات ، وليس DVCs.
أنت لا تريد تسجيل الوصول كل يتغيرون. تريد التحقق من مجموعات من التغييرات الذرية التي يمكن أن تعمل معًا. لا ترغب في إضافة معلمة إلى طريقة ما وحفظها ، بعد ذلك ، يتم تسجيل الدخول (و CI Build Run) ، ثم يمكنك الحصول على استراحة بناء لأنك لم تقم بتحديث المكالمات بعد.
تقصد شيئا مثل تخريب التلقائي?
إخلاء المسئولية: أنا لا أقول إن التقييم الذاتي فكرة جيدة للتنمية ، أو أنني سأفعل ذلك شخصيًا ، لكن التكنولوجيا موجودة.
يمكنك ارتكاب كل سطر ، أو شخصية مع DVCs مثل git إذا أردت. بشكل عام ، أعتقد أنه من الجيد أن تلتزم قدر الإمكان ، عند استخدام DVCs ، لتسهيل البحث عن مشاكل في أدوات مثل Git Bisect. إذا كنت تريد التأثير الذي تصفه ، فيمكنك نص محررك المفضل للالتزام بكل حفظ ... في الممارسة العملية على الرغم من أنني أعتقد أنه سيكون كثيرًا.
يقوم بعض الأشخاص بإعداد فرع التنمية لهذا الغرض ويجعل المطورون تغييراتهم أثناء عملهم قبل دمجها في فرع مستوى ضمان الجودة. قد يكون لديك حتى مطور يقوم بتغييرات كبيرة في فرعه/فرعها قبل أن يلتزم بتلك التغييرات ودمجها في فرع التنمية الرئيسي. لذلك ، يمكن أن يعالج هذا التفرع.
أعتقد أن Eclipse لا ، أو اعتاد على فعل شيء مثل هذا في كل حفظ. لقد أنقذني عدة مرات عندما انتهى الأمر إلى اختراق الكود الخاص بي أثناء محاولة تحديد الخلل.
هنا نهج مختلف. كل يوم تقريبًا أركض إلى المواقف التي يتوقف فيها شيء عن العمل ولا أعرف السبب. أرجع بضع دقائق وتحقق من التغييرات التي تم إجراؤها وأي الملفات. لذلك أتفق على الحاجة إلى التحكم في إصدار Continouos.
في الوقت نفسه ، صحيح أنك لا ترغب في التحقق من الآلاف من التغييرات الصغيرة كل يوم في مستودعك.
حسنًا ، هذا ما تفعله. يمكنك استخدام كليهما ولكن لا تخلطهما. يجب استخدام التحكم في المصدر من قبل الفريق بأكمله وتسجيل الوصول إلى ذلك بين الحين والآخر. في الوقت نفسه ، تقوم بتشغيل برنامج إصدار ملف شخصي محلي يحفظ كل تغيير صغير ويسهل عليك استخدام المعلومات بالفعل.
هذا هو. أنا أستعمل مستكشف التاريخ منذ أن ساعدت في تطويره ، ولكن هناك آخرون أيضًا.
قد تكون مهتمًا بنظام التحكم المستمر في الإصدار الذي تم تطويره بواسطة JetBrains. إنه ليس عامًا بعد ، لكنني أعرض بعض الميزات في الكلمة الرئيسية في Jetbrainsday في Malmo: http://new.livestream.com/jetbrains/jetbrainsday1/videos/29348962
كما ذكر دان, ، حافظ IDE IDE IDE IDE IDE على كل إصدار قمت بحفظه من ملف رمز المصدر. هذا النهج لا يقتصر على IDES ، ومع ذلك ؛ ال Dec VMs اتخذ نظام التشغيل مقاربة مماثلة مع نظام الملفات المصنفة. في VMS ، يتضمن الاسم الكامل لكل ملف رقم إصدار ، وفي كل مرة تقوم فيها بحفظ ملف ، تم إنشاء نسخة جديدة مع إصدار رقم واحد أعلى من الرقم الأعلى سابقًا.
لا يتطابق أي منهما إلى التحكم في الإصدار كما نعرفه اليوم ، حيث يفتقر كلاهما إلى التفرع (أو ، في هذا الشأن ، أي ميزات مصممة بشكل خاص لتسهيل العديد من الأشخاص الذين يعملون على نفس الملف المصدر). لكن كلاهما يخدمون الغرض من النسخ الاحتياطي ضد الخطأ البشري ، وهو الجانب الأكثر فائدة في التحكم في الإصدار.
بعد أكثر من بضع سنوات من الخبرة في البرمجة في Java ، ما زلت أتذكر (مع الحنين إلى الماضي) نهج الرواية التي جلبها العصر البصري إلى عملية التطوير. كان للعصر البصري نهج غير ملفي لرمز المصدر. تم تخزين الكود في قاعدة البيانات العلائقية. كنت تعمل عمومًا على عرض يوضح طريقة واحدة. كان لديك أيضًا عرض ملف كامل ، لكنك لن تستخدمه كثيرًا.
فيما يتعلق بالتحكم في الإصدار ، فإنه سيولد إصدارًا مع كل حفظ. يمكنك بوضوح نقطة تفتيش طريقة أو فئة/واجهة أو حزمة أو مشروع كامل برقم/اسم إصدار. كما سمحت بتحكم أكثر غرابة في مصدرك على مستوى الطريقة. بمجرد أن بدأت العمل مع Eclipse ، بينما ورثت العديد من الميزات من العصر البصري ، واليوم لديها ميزة تاريخ تنقذ محليًا "يحفظ" رمزك محليًا ، إلا أنني لم أتمكن من الشعور بأنني قد اتخذت خطوة إلى الوراء.
معقول قضية واضحة لديه مفهوم أ عرض ديناميكي. على Windows ، تظهر عرض التطوير الخاص بك كمحرك محرك تم تعيينه ، ولكن يتم تخزين تغييرات الكود الخاصة بك جانب الخادم بمجرد أن تضغط على الحفظ. هل هذا ما كنت تبحث عنه؟
هناك ، كما تتوقع ، متداولة مع العمل بهذه الطريقة ، لذلك مثل سيإجابة في الاعلى, ، هذه ليست توصية ...
ماذا عن فيستا؟
