সংস্করণ নিয়ন্ত্রণ হুকগুলিতে ইউনিট পরীক্ষা চালানো কি ভাল অনুশীলন?


43

প্রযুক্তিগত দিক থেকে কিছু প্রাক / পোস্ট পুশ হুক যুক্ত করা সম্ভব যা কিছু নির্দিষ্ট প্রতিশ্রুতি দূরবর্তী ডিফল্ট শাখায় মার্জ করার অনুমতি দেওয়ার আগে ইউনিট পরীক্ষা চালাবে।

আমার প্রশ্ন হ'ল - বিল্ড পাইপলাইনে ইউনিট পরীক্ষা রাখা ভাল (এভাবে ভাঙ্গা প্রতিশ্রুতি রেপোতে প্রবর্তন করা) বা "খারাপ" কমিটিকে না ঘটানোই ভাল।

আমি বুঝতে পারি যে আমি এই দুটি বিকল্পের সাথে সীমাবদ্ধ নই। উদাহরণস্বরূপ, আমি রেপোতে মার্জ কমিটিকে ধাক্কা দেওয়ার আগে সমস্ত কমিটকে শাখাগুলি এবং পরীক্ষার অনুমতি দিতে পারি। তবে আপনি যদি ঠিক এই দুটি সমাধানের মধ্যে বেছে নিতে চান তবে কোনটি আপনি বেছে নেবেন এবং ঠিক কোন কারণে?


1
সম্পর্কিত: stackoverflow.com/questions/31681746
tkruse

উত্তর:


35

না, এটি দুটি কারণে নয়:

দ্রুততা

কমিটগুলি দ্রুত হওয়া উচিত। একটি প্রতিশ্রুতি যা 500 এমএস লাগে, উদাহরণস্বরূপ, খুব ধীর এবং এটি বিকাশকারীদের আরও অল্প পরিমাণে প্রতিশ্রুতিবদ্ধ করতে উত্সাহিত করবে। হ্যালো ওয়ার্ল্ডের চেয়ে বড় যে কোনও প্রকল্পের জন্য, আপনার কয়েক ডজন বা শত শত পরীক্ষা হবে, প্রাক-প্রতিশ্রুতি দেওয়ার সময় সেগুলি চালাতে খুব বেশি সময় লাগবে।

অবশ্যই, হাজার হাজার পরীক্ষাগুলি সহ বৃহত্তর প্রকল্পগুলির জন্য পরিস্থিতি আরও খারাপ হয়ে যায় যা কোনও বিতরণকৃত আর্কিটেকারে কয়েক মিনিট বা একক মেশিনে কয়েক সপ্তাহ বা কয়েক মাস ধরে চলে।

সবচেয়ে খারাপ দিকটি এটি হ'ল এটি দ্রুত করার জন্য আপনার করার মতো খুব বেশি কিছু নেই। ছোট পাইথন প্রকল্পগুলিতে, যা বলে, শত ইউনিট পরীক্ষা রয়েছে, গড় সার্ভারে চালাতে কমপক্ষে এক সেকেন্ড সময় লাগে, তবে প্রায়শই অনেক বেশি সময় লাগে। একটি সি # অ্যাপ্লিকেশনের জন্য, সংকলনের সময়টির কারণে এটি গড়ে চার-পাঁচ সেকেন্ডের হবে।

সেদিক থেকে, আপনি আরও ভাল সার্ভারের জন্য অতিরিক্ত 10,000 ডলার দিতে পারেন যা সময় কমিয়ে দেবে, তবে খুব বেশি নয়, বা একাধিক সার্ভারগুলিতে পরীক্ষা চালাবে, যা কেবল জিনিসগুলি ধীর করে দেবে।

আপনার যখন কয়েক হাজার পরীক্ষা (পাশাপাশি কার্যকরী, সিস্টেম এবং ইন্টিগ্রেশন টেস্টস) থাকে তখন উভয়ই ভাল অর্থ প্রদান করে, যা তাদের কয়েক সপ্তাহের পরিবর্তে কয়েক মিনিটের মধ্যে চালানোর অনুমতি দেয়, তবে এটি আপনাকে ছোট স্কেল প্রকল্পে সহায়তা করবে না।

পরিবর্তে, আপনি যা করতে পারেন তা হ'ল:

  • বিকাশকারীদের প্রতিশ্রুতি দেওয়ার আগে স্থানীয়ভাবে সংশোধিত কোডের সাথে দৃ strongly়তার সাথে সম্পর্কিত পরীক্ষা চালানোর জন্য উত্সাহিত করুন। তারা সম্ভবত কয়েক হাজার ইউনিট পরীক্ষা চালাতে পারে না, তবে তারা তাদের মধ্যে পাঁচ-দশটি চালাতে পারে।

    নিশ্চিত হয়ে নিন যে প্রাসঙ্গিক পরীক্ষাগুলি সন্ধান করা এবং সেগুলি চালানো আসলে সহজ (এবং দ্রুত)। উদাহরণস্বরূপ, ভিজ্যুয়াল স্টুডিওগুলি সনাক্ত করতে সক্ষম হয়েছে যা শেষ রানের পরে পরিবর্তিত পরিবর্তনগুলি দ্বারা কোন পরীক্ষাগুলি প্রভাবিত হতে পারে। অন্যান্য আইডিই / প্ল্যাটফর্ম / ভাষা / ফ্রেমওয়ার্কগুলির একই কার্যকারিতা থাকতে পারে।

  • কমিটিকে যত তাড়াতাড়ি সম্ভব রাখুন। স্টাইলের নিয়ম প্রয়োগ করা ঠিক আছে, কারণ প্রায়শই এটি করা একমাত্র জায়গা এবং এই জাতীয় চেকগুলি প্রায়শই আশ্চর্যরকম দ্রুত হয়। স্থির বিশ্লেষণ দ্রুত করা ঠিক আছে, যা খুব কমই ঘটে। ইউনিট পরীক্ষা চালানো ঠিক নয়।

  • আপনার অবিচ্ছিন্ন ইন্টিগ্রেশন সার্ভারে ইউনিট পরীক্ষা চালান।

  • নিশ্চিত করুন যে বিকাশকারীরা বিল্ডটি ভেঙে দেওয়ার পরে স্বয়ংক্রিয়ভাবে অবহিত হয়ে গেছে (বা ইউনিট পরীক্ষাগুলি ব্যর্থ হওয়ার পরে, আপনি যদি নিজের কোডের সাথে পরিচয় করিয়ে দিতে পারেন এমন কিছু সম্ভাব্য ভুল পরীক্ষা করে এমন একটি সরঞ্জাম হিসাবে একটি সংকলককে বিবেচনা করেন যা কার্যত একই জিনিস)।

    উদাহরণস্বরূপ, শেষের বিল্ডগুলি চেক করতে কোনও ওয়েব পৃষ্ঠায় যাওয়া কোনও সমাধান নয়। তাদের স্বয়ংক্রিয়ভাবে জানানো উচিত । একটি পপআপ দেখানো বা একটি এসএমএস পাঠানো কীভাবে তাদের জানানো হতে পারে তার দুটি উদাহরণ।

  • নিশ্চিত করুন যে বিকাশকারীরা বুঝতে পারেন যে বিল্ডটি ভাঙ্গা (বা ব্যর্থ হওয়া রিগ্রেশন পরীক্ষাগুলি) ঠিক নয় এবং এটি হওয়ার সাথে সাথেই তাদের শীর্ষস্থানীয় অগ্রাধিকারটি এটি ঠিক করা। তারা কোনও উচ্চ-অগ্রাধিকার বৈশিষ্ট্যটিতে কাজ করছে কিনা তা বিবেচ্য নয় যে তাদের বস আগামীকালের জন্য জাহাজে পাঠাতে বলেছিল: তারা বিল্ডটি ব্যর্থ হয়েছে, তাদের এটি ঠিক করা উচিত।

নিরাপত্তা

সুরক্ষা হোস্ট করা সার্ভারটি কাস্টম কোড যেমন চলমান ইউনিট পরীক্ষাগুলি বিশেষত সুরক্ষার কারণে চালানো উচিত নয়। গিটল্যাবের একই সার্ভারে সিআই রানারটিতে এই কারণগুলি ইতিমধ্যে ব্যাখ্যা করা হয়েছে ?

অন্যদিকে, আপনার ধারণাটি প্রাক-প্রতিশ্রুতি হুক থেকে বিল্ড সার্ভারে কোনও প্রক্রিয়া চালু করা হয়, তবে এটি আরও কমিটগুলি কমিয়ে দেবে।


4
আমি সম্মত, এটিই একটি বিল্ড সার্ভারের জন্য। আপনার উত্স নিয়ন্ত্রণ আপনার অ্যাপ্লিকেশন কাজ করে না তা নিশ্চিত করে সোর্স কোড পরিচালনা করার জন্য।
ম্যাথু

4
চরম ক্ষেত্রে, প্রতিস্থাপনটি বিল্ডটি ভাঙ্গার সময় একটি প্রয়োজনীয় বিজ্ঞপ্তির সরঞ্জাম হতে পারে।

37
আধ সেকেন্ড খুব ধীর? কী চলা হচ্ছে তার একটি চূড়ান্ত চেহারা দেওয়ার এবং তারপরে একটি উপযুক্ত কমিট মন্তব্য মন্তব্য করা এবং টাইপ করার সাথে তুলনায় বালতিতে এটি একটি ড্রপ।
ডোভাল

5
@ ডোভাল: পার্থক্যটি হ'ল আপনি যখন একটি চূড়ান্ত চেহারা দেন বা মন্তব্যটি সম্পর্কে ভাবেন, আপনি প্র্যাকটিভ হন এবং তাই, আপনি অপেক্ষা করেন না। আপনার আইডিইতে সর্বশেষ চরিত্রটি টাইপ করার আগে আপনি যে সময় ব্যয় করেছেন তা নয় এবং প্রতিশ্রুতি সম্পন্ন হওয়ার পরে আপনি যখন আবার টাইপ করা শুরু করতে পারেন তবে আপনি কতটা অপেক্ষা করেন। এজন্য সংকলকগুলি দ্রুত হওয়া উচিত; আপনি কোড পড়তে এবং লেখার জন্য বেশি বেশি সময় ব্যয় করেন তা বিবেচ্য নয়, কারণ আপনি যখন এটি করেন, আপনি অপেক্ষা করেন না, যখন কোডটি সংকলন করা হয়, তখন আপনি কোনও ভিন্ন ক্রিয়ায় স্যুইচ করার প্রলুব্ধ হন।
আর্সেনী মরজেনকো

10
@ থমাস: এটি বিভ্রান্তির বিষয়ে নয়, বিরক্তির বিষয়ে। একইভাবে, 100 এমএস। ব্যক্তিরা কীভাবে কোনও ওয়েবসাইট ব্যবহার করছেন তার উপর "একটি পরিমাপযোগ্য প্রভাব রয়েছে" । একই প্যাটার্ন এখানে: 100 এমএস। আপনি কোনও ইউটিউব ভিডিও দেখার সময় বা আপনার পিসি শুরু করার সাথে তুলনামূলক কিছুই নয়: সচেতনভাবে , আপনি 600 এমএসের মধ্যে পার্থক্যটি লক্ষ্য করবেন না। এবং 700 এমএস। বিলম্ব। তবে অচেতনভাবে, এটি আপনার আচরণের উপর প্রভাব ফেলে। একইভাবে, সামান্য ধীর প্রতিশ্রুতি আপনাকে প্রথম এবং ঘন ঘন প্রতিশ্রুতিবদ্ধ হতে নিরুৎসাহিত করে।
আর্সেনী মরজেনকো

41

আমার সহকর্মী উত্তরদাতাদের সাথে একমত হওয়ার জন্য আমাকে একজন হতে দিন।

এটি টিএফএস বিশ্বে গেটেড চেক-ইনস হিসাবে পরিচিত এবং আমি অন্য কোথাও আশা করি। আপনি যখন গেটেড চেক-ইন সহ একটি শাখায় চেক-ইন করার চেষ্টা করছেন, তখন তাকটি সার্ভারে প্রেরণ করা হবে, এটি নিশ্চিত করে যে আপনার পরিবর্তনগুলি তৈরি হয়েছে এবং নির্দিষ্ট (পড়ুন: সমস্ত) ইউনিট পরীক্ষা পাস করেছে। যদি তারা তা না করে তবে এটি আপনাকে জানিয়ে দেয় যে আপনি একজন খারাপ বানর যিনি এই বিল্ডটি ভেঙেছেন। যদি তারা তা করে, পরিবর্তনগুলি উত্স নিয়ন্ত্রণে চলে যায় (হ্যাঁ!)।

আমার অভিজ্ঞতায়, গেটেড চেক-ইনগুলি সফল ইউনিট পরীক্ষার জন্য অন্যতম গুরুত্বপূর্ণ প্রক্রিয়া - এবং এক্সটেনশান, সফ্টওয়্যার মানের দ্বারা।

কেন?

  • কারণ গেটেড চেক ইনগুলি লোকদের ভাঙ্গা পরীক্ষাগুলি ঠিক করতে বাধ্য করে। যত তাড়াতাড়ি ভাঙা পরীক্ষা হয়ে কিছু মানুষ করতে বদলে কি উচিত নয় , তারা ডি অগ্রাধিকারের হয়ে অলস ইঞ্জিনিয়ার এবং / অথবা বিরক্তিকর ভাবে আত্মসাম্মুখ্যপূর্ণ ব্যবসায়ী দ্বারা।
    • পরীক্ষার যতক্ষণ ভাঙা যায় তত কঠিন (এবং ব্যয়বহুল) এটি ঠিক করা।
  • কারণ যত তাড়াতাড়ি লোকেদের পরীক্ষা চালানো উচিত তার চেয়ে দ্রুত পরীক্ষা চালানো উচিত , পরীক্ষা চালানো অলস / ভুলে যাওয়া প্রকৌশলী এবং / অথবা পুশ ব্যবসায়ীদের দ্বারা পরিলক্ষিত হয়।
  • কারণ যত তাড়াতাড়ি ইউনিট পরীক্ষা প্রভাব যেমন আপনার সময় কমিট, মানুষ সত্যিই তাদের পরীক্ষার তৈরীর সম্পর্কে যত্নশীল শুরু ইউনিট পরীক্ষা। গতি বিষয়। প্রজননযোগ্যতা বিষয়। নির্ভরযোগ্যতা বিষয়। বিচ্ছিন্নতা বিষয়।

এবং অবশ্যই, আপনি যে সুবিধাটি মূলত উত্থাপিত করেছেন সেগুলি রয়েছে - যখন আপনি চেক-ইন পরীক্ষা করেছেন এবং পরীক্ষার একটি শক্ত স্যুট করেন, তখন প্রতিটি একক পরিবর্তন "স্থিতিশীল" থাকে। আপনি "সর্বশেষ ভাল বিল্ডটি কখন ছিল?" এর সমস্ত ওভারহেড (এবং ত্রুটির সম্ভাবনা) সংরক্ষণ করুন? - সমস্ত বিল্ডগুলি এর বিরুদ্ধে বিকাশ করার পক্ষে যথেষ্ট ভাল।

হ্যাঁ, পরীক্ষাগুলি তৈরি এবং পরিচালনা করতে এটি সময় নেয়। আমার অভিজ্ঞতায় একটি ভাল আকারের সি # অ্যাপ্লিকেশন এবং ~ 5k ইউনিট পরীক্ষার জন্য 5-10 মিনিট। এবং আমি এটি সম্পর্কে চিন্তা করি না। হ্যাঁ, লোকেরা ঘন ঘন চেক ইন করা উচিত। তবে তাদেরও তাদের কাজগুলি ঘন ঘন আপডেট করা উচিত, বা তাদের ইমেল পরীক্ষা করা উচিত, বা কিছু কফি বা কয়েক ডজন অন্যান্য "কোডে কাজ না করা" জিনিসগুলি পাওয়া উচিত যা সফটওয়্যার ইঞ্জিনিয়ারের সেই সময়টি দখল করার কাজ করে job খারাপ কোডটি পরীক্ষা করা 5-10 মিনিটের চেয়ে অনেক বেশি ব্যয়বহুল।


3
+1 আমি যোগ করতে চাই, অনেকগুলি ওপেন সোর্স প্রকল্পের অবদান এবং প্রতিশ্রুতিবদ্ধতার মধ্যে স্পষ্ট পার্থক্য রয়েছে। এর কারণগুলি গেটেড চেক-ইনগুলি কেন বিদ্যমান তার সাথে খুব মিল।
জেনসজি

গেটেড চেক-ইন নিয়ে একটি উল্লেখযোগ্য সমস্যা হ'ল এটি জটিল কোডের সহযোগী সমস্যা সমাধানে বাধা দেয়। বিতরণ দলগুলির সাথে এটি আরও বেশি তাৎপর্যপূর্ণ।
কৌতূহল রাব্বিট

2
@ কারকিরিস র‌্যাবিট - আপনি কীভাবে চিত্রিত করবেন? মানুষ খুব কমই কমিট সমন্বিত সহযোগিতায় এমনকি যদি তারা কাজ সমন্বিত সহযোগিতায়। অন্যথায় শেলফসেটস বা অ্যানডেটেড টাস্ক শাখাগুলি দলের পক্ষে বাধা না দেওয়ার জন্য সে জন্য ভাল কাজ করে।
টেলাস্টিন

@ টেলাস্টিনি শেলভিসেটস আমার জন্য একটি নতুন শব্দ। আমি সংগ্রহ করেছি যে এটি একটি এমএস ভিএস বিকল্প, যা বিপুল সংখ্যক প্রকল্পের বিকল্প নয়। মোবাইল অ্যাপ্লিকেশন বিকাশের ক্ষেত্রে, ভিএস হ'ল একটি খেলোয়াড়।
কৌতূহল রাব্বিট

3
@ কারকিরিস র‌্যাবিট - সত্যি? 17 টিরও বেশি সময় বিতরণ করা একটি দল যখন আপত্তিজনক দলটি ঘুমিয়ে আছে তখন ভাঙা বিল্ড হওয়ার সম্ভাবনার চেয়ে কমিটের জন্য 10 মিনিট অপেক্ষা করা বেশি যত্নশীল? মনে হচ্ছে ... অনুকূল থেকে কম।
টেলাস্টিন

40

কমিটগুলি দ্রুত চালানো উচিত। আমি যখন কিছু কোড করি তখন আমি এটি সার্ভারে ঠেলে দিতে চাই। এটি পরীক্ষার ব্যাটারি চালানোর সময় আমি কয়েক মিনিট অপেক্ষা করতে চাই না। আমি সার্ভারে যা চাপছি তার জন্য আমি দায়বদ্ধ এবং কমিট হুকের সাহায্যে কেউ আমাকে বয়সিট করার দরকার নেই।

এটি বলেছিল, একবার এটি সার্ভারে পৌঁছে গেলে, এটি বিশ্লেষণ করা উচিত, ইউনিট পরীক্ষা করা উচিত এবং অবিলম্বে তৈরি করা উচিত (বা স্বল্প সময়ের মধ্যে)। এটি আমাকে ইউনিট পরীক্ষাগুলি ভাঙ্গা হয়েছে বা এটি সংকলন করে না, বা স্থিতিশীল বিশ্লেষণ সরঞ্জামগুলি উপলভ্য একটি জগাখিচুড়ি করেছি তা সম্পর্কে আমাকে সতর্ক করবে। এটি যত দ্রুত সম্পন্ন হয় (বিল্ড এবং বিশ্লেষণ), আমার প্রতিক্রিয়া তত দ্রুত এবং আমি দ্রুত এটি সংশোধন করতে সক্ষম হয়েছি (চিন্তাগুলি আমার মস্তিষ্ক থেকে পুরোপুরি সরে যায়নি)।

সুতরাং না, ক্লায়েন্টের উপর টেস্ট এবং এই জাতীয় প্রতিশ্রুতি হুক রাখবেন না। যদি আপনার অবশ্যই হয় তবে সেগুলি একটি পোস্ট কমিটে সার্ভারে রেখে দিন (কারণ আপনার কাছে সিআই সার্ভার নেই) বা সিআই বিল্ড সার্ভারে এবং কোড সহ সমস্যাগুলি সম্পর্কে আমাকে যথাযথভাবে সতর্ক করুন। তবে প্রতিশ্রুতিটি প্রথম স্থানে আটকাবেন না।

আমার এটিও উল্লেখ করা উচিত যে টেস্ট চালিত বিকাশের কিছু ব্যাখ্যার সাথে প্রথমে ব্রেক ইউনিট পরীক্ষা করা উচিত । এটি বাগ উপস্থিত রয়েছে এবং এটি ডকুমেন্টগুলি প্রদর্শন করে। তারপরে একটি চেক ইন হবে এমন একক কোড যা ইউনিট পরীক্ষার সমাধান করে। ইউনিট পরীক্ষাগুলি পাস না হওয়া পর্যন্ত কোনও চেকিন প্রতিরোধ করা ইউনিট পরীক্ষায় পরীক্ষার কার্যকর মান হ্রাস করবে যা ইস্যুটি দলিল করতে ব্যর্থ হয়েছে।

সম্পর্কিত: জ্ঞাত ত্রুটিগুলির জন্য আমার ইউনিট পরীক্ষা করা উচিত? এবং ইউনিট পরীক্ষায় ব্যর্থতা যাচাইয়ের মূল্য কী?


2
Commits should run fast.এর সুবিধা কী? আমি কৌতূহলী কারণ আমরা বর্তমানে গেটেড চেকিন ব্যবহার করি। সাধারণত আমার চেকিনগুলি এক ঘন্টা বা তার বেশি কাজ করে, তাই 5 মিনিটের অপেক্ষা খুব বড় ব্যাপার নয়। প্রকৃতপক্ষে আমি খুঁজে পেয়েছি যে এটির সাধারণত যখন আমি কোনও ভিড়ের মধ্যে থাকি তখন বৈধতা নির্মূ mistakes় ভুলগুলি ধরার জন্য সবচেয়ে বেশি কার্যকর (তাড়াহুড়ো করার ফলে)
জাস্টিন

1
@ জাস্টিন পাঁচ মিনিটের অপেক্ষা পাঁচ মিনিট অপেক্ষা যেখানেই হোক না কেন। এক করা উচিত নয় প্রত্যেক সময় আপনি একটি কমিট না nerf তলোয়ার আউট বিরতি প্রয়োজন। এবং একে অপরের প্রতিটি ধারণামূলক ইউনিট যে একাধিক কমিটের জন্য এক ঘন্টা বা তার বেশি কাজ করা আমার পক্ষে অস্বাভাবিক কিছু নয় - "বাকী পরিষেবা কোডটি কমিট করুন" এর পরে "পরিবেশনিত ক্লায়েন্ট পৃষ্ঠার জন্য কোড কমিট করুন" দুটি পৃথক কমিট হিসাবে (সিএসএস টুইটকে অন্য অঙ্গীকার হিসাবে উল্লেখ না করা) mention এইগুলির প্রতিটি চালাতে যদি 5 মিনিট সময় নেয় তবে আমার 1/6 র্থ সময় পরীক্ষার জন্য অপেক্ষা করতে ব্যয় হয়। এটি বৃহত্তর রোলআপ

ইউনিট পরীক্ষা চালাতে 5 মিনিট অপেক্ষা? আমার মনে হচ্ছে আপনি যে প্রকল্পগুলিতে কাজ করছেন তাদের ছোট ছোট ভাগে ভাগ করা উচিত।
ব্যবহারকারী 441521

@ জাস্টিন catching silly mistakes (as a result of rushing)ঠিক সফটওয়্যার ইঞ্জিনিয়ারিংয়ের সাধারণভাবে ছুটে যাওয়া একটি খারাপ অভ্যাস। রবার্ট সি মার্টিন একটি শল্য চিকিত্সা করার মত কোড লিখতে পরামর্শ দিয়েছেন youtube.com/watch?v=p0O1VVqRSK0
জেরি জোসেফ

10

নীতিগতভাবে, আমি মনে করি যে বিল্ডটি ভেঙে দেয় এমন মূলধারায় মানুষকে পরিবর্তন করতে বাধা দেওয়া অর্থবোধ করে। এটি হ'ল, আপনার সংগ্রহস্থলের মূল শাখায় পরিবর্তন আনার প্রক্রিয়াটি নিশ্চিত হওয়া উচিত যে সমস্ত পরীক্ষা এখনও পাস করেছে। প্রকল্পের সমস্ত ইঞ্জিনিয়ারদের অন্য কোনও কিছু করার জন্য হারিয়ে যাওয়া সময়ের ক্ষেত্রে বিল্ডটি ভঙ্গ করা খুব ব্যয়বহুল।

তবে কমিট হুকের নির্দিষ্ট সমাধানটি কোনও ভাল পরিকল্পনা নয়।

  1. প্রতিশ্রুতি দেওয়ার সময় বিকাশকারীদের পরীক্ষা চালানোর জন্য অপেক্ষা করতে হবে। সমস্ত পরীক্ষাগুলি পাস করার জন্য যদি বিকাশকারীকে তার ওয়ার্কস্টেশনটির জন্য অপেক্ষা করতে হয় তবে আপনি মূল্যবান ইঞ্জিনিয়ার সময় নষ্ট করেছেন। ইঞ্জিনিয়ারকে পরবর্তী কাজটি সরিয়ে নিতে সক্ষম হওয়া দরকার, এমনকি যদি পরীক্ষাগুলি ব্যর্থ হয় বলে তাকে ফিরে যেতে হবে।
  2. বিকাশকারীরা একটি শাখায় ভাঙা কোড করতে পারে। বৃহত্তর কার্যক্রমে, কোডটির বিকাশকারীদের সংস্করণটি পাসিং অবস্থায় না কাটতে অনেক সময় ব্যয় করতে পারে। স্পষ্টতই, কোডটি মূল লাইনে মার্জ করা খুব খারাপ হবে। তবে এটি বরং গুরুত্বপূর্ণ যে বিকাশকারী এখনও তার অগ্রগতি ট্র্যাক করতে সংস্করণ নিয়ন্ত্রণ ব্যবহার করতে পারেন।
  3. প্রক্রিয়াটি এড়িয়ে যাওয়ার এবং পরীক্ষাগুলি বাইপাস করার জন্য মাঝে মাঝে ভাল কারণ রয়েছে।

2
# 1 বিকাশকারীদের ব্যক্তিগত শাখা বা স্থানীয় সংগ্রহস্থলে চেক-ইন করার অনুমতি দিয়ে বাধা দেওয়া হয়। এটি তখনই হয় যখন কোনও বিকাশকারী তাদের কোড কোথাও চায় যখন অন্যান্য বিকাশকারীরা দেখতে পান যে ইউনিট পরীক্ষা চালানো দরকার। # 1 হিসাবে, # 2 কেবলমাত্র হুক দ্বারা মেইনলাইন শাখায় বিভক্ত হয়। # 3 এই সত্যটি দ্বারা বিভ্রান্ত হয় যে ক) এ জাতীয় কোনও বৈশিষ্ট্য অক্ষম করা যেতে পারে, যদিও এটি কোনও ঝামেলা (এবং একটি ঝামেলা হওয়া উচিত ) এবং খ) স্বতন্ত্র ব্যর্থ ইউনিট পরীক্ষাগুলি অক্ষম করা যেতে পারে।
ব্রায়ান

@ ব্রায়ান, আমি সম্পূর্ণ চুক্তিতে আছি, আপনি এই কাজটি করতে পারেন। কিন্তু, কমিট হুক সার্ভার-সাইডটি ব্লক করে করার চেষ্টা করা কার্যকর হচ্ছে না।
উইনস্টন ইওয়ার্ট

ভাল দিক. Breaking the build is simply too costly in terms of lost time for all engineers on the projectআমি প্রতিটি ইঞ্জিনিয়ারদের প্রতিটি ভাঙা বিল্ডের হারিয়ে যাওয়ার সময় শেষ না করার জন্য কোনও ধরণের বিল্ড নোটিফিকেশন সরঞ্জামটি ব্যবহার করার পরামর্শ দেব
জেরি জোসেফ

3

না, অন্যান্য উত্তরগুলি যেমন নির্দেশ করেছে তেমন আপনাকে করা উচিত নয়।

যদি আপনি কোনও কোড বেস থাকতে চান যা কোনও ব্যর্থ পরীক্ষা না দেওয়ার নিশ্চয়তাযুক্ত, আপনি তার পরিবর্তে বৈশিষ্ট্য শাখায় বিকাশ করতে পারেন এবং অনুরোধগুলি মাস্টার হিসাবে টানতে পারেন। তারপরে আপনি এই টানার অনুরোধগুলি গ্রহণের জন্য পূর্ব শর্তগুলি সংজ্ঞায়িত করতে পারেন। সুবিধাটি হ'ল আপনি সত্যিই দ্রুত এগিয়ে যেতে পারেন এবং পরীক্ষাগুলি পটভূমিতে চালিত হয়।


2

মূল শাখায় প্রতিটি প্রতিশ্রুতিবদ্ধতার উপর সাফল্যপূর্ণ বিল্ড এবং পরীক্ষাগুলির জন্য অপেক্ষা করা সত্যই ভয়াবহ, আমি মনে করি সকলেই এতে একমত হয়।

একটি সামঞ্জস্যপূর্ণ প্রধান শাখা অর্জনের অন্যান্য উপায়ও রয়েছে। এখানে একটি পরামর্শ, টিএফএসে গেটেড চেক-ইনগুলির শিরাতে কিছুটা অনুরূপ, তবে যা শাখাগুলি সহ কোনও সংস্করণ নিয়ন্ত্রণ ব্যবস্থায় সাধারণীকরণযোগ্য, যদিও আমি বেশিরভাগ ক্ষেত্রে গিট শর্তাদি ব্যবহার করব:

  • একটি স্টেজিং শাখা রয়েছে যেখানে আপনি কেবল আপনার দেব শাখা এবং প্রধান শাখার মধ্যে মার্জ করতে পারবেন can

  • একটি হুক সেটআপ করুন যা একটি বিল্ড শুরু করে বা সারি তৈরি করে এবং স্টেজিং শাখায় করা কমিটগুলির পরীক্ষা করে, তবে এটি কমিটিকে অপেক্ষা করে না

  • সফল বিল্ড এবং পরীক্ষায়, প্রধান শাখাটি আপ টু ডেট থাকলে স্বয়ংক্রিয়ভাবে এগিয়ে যান make

    দ্রষ্টব্য: স্বয়ংক্রিয়ভাবে প্রধান শাখায় একত্রীকরণ করবেন না , কারণ পরীক্ষিত মার্জটি যদি প্রধান শাখার দৃষ্টিকোণ থেকে একটি ফরোয়ার্ড মার্জ না হয় তবে এর মধ্যে কমিটের সাথে মূল শাখায় মার্জ হওয়ার পরে ব্যর্থ হতে পারে

এর ফলে:

  • নিষিদ্ধ মানব প্রধান শাখায় প্রতিশ্রুতিবদ্ধ, যদি আপনি পারেন তবে স্বয়ংক্রিয়ভাবে, তবে সরকারী প্রক্রিয়ার অংশ হিসাবে যদি কোনও ফাঁক আছে বা এটি কার্যকর করার জন্য প্রযুক্তিগতভাবে সম্ভব না হয়

    কমপক্ষে, আপনি নিশ্চিত করতে পারেন যে এটি একবার স্থল নিয়ম করে কেউ অনিচ্ছাকৃতভাবে বা কুৎসা ছাড়াই এটি করবে না। কখনও এটি করার চেষ্টা করা উচিত নয়।

  • আপনি এর মধ্যে চয়ন করতে হবে:

    • একটি একক মঞ্চ শাখা, যা অন্যথায় সফল সংহতগুলি বাস্তবে ব্যর্থ করে দেয় যদি পূর্ববর্তীটি এখনও নির্মাণ না করে এবং পরীক্ষিত মার্জ ব্যর্থ হয় না

      কমপক্ষে, আপনি জানেন যে কোন সংশ্লেষ ব্যর্থ হয়েছে এবং কেউ এটি সংশোধন করেছেন, তবে এর মধ্যে সংযুক্তিগুলি আরও বিল্ডিং এবং পরীক্ষার ফলাফলগুলির জন্য তুচ্ছভাবে সনাক্ত করা যায় না (সংস্করণ নিয়ন্ত্রণ ব্যবস্থা দ্বারা)।

      আপনি ফাইল টীকা (বা দোষারোপ) দেখুন, কিন্তু কখনও কখনও একটি ফাইলের পরিবর্তন (যেমন কনফিগারেশন) অপ্রত্যাশিত জায়গায় ত্রুটি তৈরি করে। তবে এটি একটি বিরল ঘটনা।

    • একাধিক মঞ্চায়ন শাখা, যা বিরোধবিরোধী সফল একত্রীকরণগুলিকে মূল শাখায় যেতে দেয়

      এমনকি অন্য কোনও মঞ্চ শাখার দ্বন্দ্বহীন ব্যর্থ মার্জ রয়েছে এমন ইভেন্টেও। ট্রেসেবিলিটিটি কিছুটা ভাল, অন্তত এমন ক্ষেত্রে যে কোনও একীকরণ অন্য সংযোজন থেকে কোনও প্রভাবিত পরিবর্তনের আশা করেনি। তবে আবার, প্রতিদিন বা প্রতি সপ্তাহে চিন্তা না করার পক্ষে এটি যথেষ্ট বিরল।

      বেশিরভাগ সময় অবিসংবাদিত সংশ্লেষের জন্য, মঞ্চায়ন শাখাগুলি সংবেদনশীলভাবে বিভক্ত করা গুরুত্বপূর্ণ, যেমন প্রতি দল প্রতি, প্রতি স্তর হিসাবে, বা প্রতি উপাদান / প্রকল্প / সিস্টেম / সমাধান (আপনি তার নাম রাখবেন)।

      যদি প্রধান শাখাটি ইতিমধ্যে অন্য সংশ্লেষে ফরোয়ার্ড করা হয় তবে আপনাকে আবার মার্জ করতে হবে। আশা করা যায়, এটি বিরোধবিরোধী মার্জ বা খুব কম সংঘাতের সাথে সমস্যা নয়।

গেটেড চেক-ইনগুলির সাথে তুলনা করে, এখানে সুবিধাটি হ'ল আপনার কাছে একটি কার্যকারী প্রধান শাখার গ্যারান্টি রয়েছে কারণ মূল শাখাটি কেবলমাত্র এগিয়ে যাওয়ার অনুমতি দেওয়া হয়, এর মধ্যে যা কিছু করা হয়েছিল তার সাথে স্বয়ংক্রিয়ভাবে আপনার পরিবর্তনগুলি মার্জ করে না। সুতরাং তৃতীয় বিষয়টি প্রয়োজনীয় পার্থক্য।


তবে একটি কার্যকারী শাখা থাকার বিষয়টি (সাধারণত) আপনার স্থিতিশীল প্রকাশের বিষয়টি নিশ্চিত করার জন্য নয়, তবে একই কোডে একসাথে কাজ করে বিকাশকারীদের দ্বারা আঘাত হ্রাস করা উচিত।
টেলাস্টিন

আপনার যদি বিশাল, বিশ্বব্যাপী বিতরণ করা দলগুলির সাথে একটি বিশাল রেপো থাকে না। উদাহরণস্বরূপ মাইক্রোসফ্ট উইন্ডোজের সাথে অনুরূপ, আরও স্তরযুক্ত পদ্ধতির ব্যবহার করে।
acelent

2

আমি কোড জমা দেওয়ার গেট হতে "পাস ইউনিট পরীক্ষা" পছন্দ করি। তবে, সেই কাজটি করতে আপনার কয়েকটি জিনিস প্রয়োজন।

আপনার একটি বিল্ড ফ্রেমওয়ার্ক দরকার যা প্রত্নতত্ত্বগুলিকে ক্যাশে করে।

আপনার একটি পরীক্ষার কাঠামো দরকার যা পরীক্ষার স্ট্যাটাসকে (সফল) পরীক্ষার রান থেকে কোনও প্রদত্ত আর্টফ্যাক্ট (গুলি) দিয়ে দেয় aches

এইভাবে, পাসিং ইউনিট পরীক্ষাগুলি সহ চেক-ইনগুলি দ্রুত হবে (বিকাশকারীরা চেক-ইন করার আগে পরীক্ষাগুলি পরীক্ষা করার সময় উত্স থেকে শুরু করা প্রত্নতত্ত্বের ক্রস-চেক), ইউনিট পরীক্ষায় ব্যর্থ হওয়া ব্যক্তিরা অবরুদ্ধ থাকবে এবং বিকাশকারীরা যারা কমিটমেন্টের পূর্বে বিল্ডগুলি চেক করতে সুবিধামত ভুলে যাওয়া পরের বারের মতো মনে রাখার জন্য উত্সাহিত করা হবে কারণ সংকলন এবং পরীক্ষার চক্রটি দীর্ঘ।


1

আমি বলব এটি প্রকল্প এবং "কমিট" এর উপর পরিচালিত স্বয়ংক্রিয় পরীক্ষার সুযোগগুলির উপর নির্ভর করে।

আপনি চেক-ইন ট্রিগারটিতে চালনা করতে চান এমন পরীক্ষাগুলি যদি সত্যিই দ্রুত হয়, বা যদি বিকাশকারী ওয়ার্কফ্লো এইভাবে একটি চেক-ইন করার পরে কিছু প্রশাসনিক কাজকে বাধ্য করে, তবে আমি মনে করি এটি খুব বেশি গুরুত্ব পাবে না এবং কেবলমাত্র ডিভগুলিকে কেবল চেক করতে বাধ্য করবে স্টাফগুলিতে যা একেবারে সর্বাধিক প্রাথমিক পরীক্ষা চালায়। (আমি ধরে নিচ্ছি আপনি কেবল এই জাতীয় ট্রিগারটিতে সর্বাধিক প্রাথমিক পরীক্ষা চালাবেন))

এবং আমি মনে করি, গতি / কর্মপ্রবাহের অনুমতি দেওয়া, অন্য বিকাশকারীদের যে পরীক্ষাগুলিতে ব্যর্থ হয় তাদের পরিবর্তনের দিকে ধাক্কা না দেওয়া ভাল - এবং আপনি যদি চালনা করেন তবে সেগুলি ব্যর্থ হয়েছে কিনা তা আপনি কেবল জানেন।

আপনি প্রশ্নে "কমিট ... রিমোট শাখায়" লিখুন, যা আমার কাছে বোঝায় যে এটি (ক) প্রতি কয়েক মিনিটের মধ্যে কোনও দেব কিছু করেন না, তাই একটি ছোট অপেক্ষা খুব ভাল গ্রহণযোগ্য হতে পারে, এবং (খ) তার পরে এই ধরনের কমিট কোডের পরিবর্তনগুলি অন্যান্য ডিভগুলিকে প্রভাবিত করতে পারে, তাই অতিরিক্ত চেকগুলি ক্রমযুক্ত হতে পারে।

আমি এই জাতীয় অপারেশনের জন্য "অপেক্ষা করার সময় আপনার ডেভসকে ট্যুইডল থাম্বস তৈরি করবেন না" এ অন্যান্য জবাবগুলির সাথে একমত হতে পারি।


1

ভাঙ্গা কমিটগুলি ট্রাঙ্কে ছাড়ার অনুমতি দেওয়া উচিত নয় , কারণ ট্রাঙ্ক হ'ল উত্পাদনে যেতে পারে। সুতরাং আপনাকে ট্রাঙ্কে যাওয়ার আগে একটি গেটওয়ে যেতে হবে তা নিশ্চিত করতে হবে । যাইহোক, ভাঙ্গা কমিটগুলি যতক্ষণ না ট্রাঙ্কে না থাকে কোনও রেপোতে সম্পূর্ণ সূক্ষ্ম হতে পারে।

অন্যদিকে, সংগ্রহশালায় পরিবর্তন আনার আগে বিকাশকারীদের সমস্যার অপেক্ষা করতে / ঠিক করতে অনেকগুলি ত্রুটি থাকে draw

কিছু উদাহরণ:

  • টিডিডিতে, বৈশিষ্ট্যটি কার্যকর করা শুরু করার আগে নতুন বৈশিষ্ট্যগুলির জন্য ব্যর্থ পরীক্ষাগুলি প্রতিশ্রুতিবদ্ধ করা এবং ধাক্কা দেওয়া সাধারণ
  • ব্যর্থ পরীক্ষার প্রতিশ্রুতিবদ্ধ ও চাপ প্রয়োগ করে বাগগুলি প্রতিবেদন করার ক্ষেত্রে এটি একই রকম হয়
  • অসম্পূর্ণ কোড পুশ করা 2 বা ততোধিক লোককে সহজেই সমান্তরালে কোনও বৈশিষ্ট্যে কাজ করতে দেয়
  • আপনার সিআই অবকাঠামো এটি যাচাই করতে সময় নিতে পারে তবে বিকাশকারীকে অপেক্ষা করতে হবে না
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.