ভিজ্যুয়াল স্টুডিওতে 1 বছরের বিকাশের কৌশলগুলি


32

আমার এক ক্লায়েন্ট আছেন যারা জোর দিয়েছিলেন যে আমরা আমাদের নতুন বিকাশকে পুরো ২০১ for সালের মূল শাখাগুলি থেকে আলাদা রাখব They তাদের মধ্যে আরও বিভিন্ন 3-4 টি টিম বিভিন্ন ক্ষমতায় অ্যাপ্লিকেশনটিতে কাজ করছে। অসংখ্য বড় বড় পরিবর্তন আনা হয়েছে (কীভাবে নির্ভরতা ইনজেকশন হয় তা স্যুইচ করা, রিশার্পার সহ কোড সাফ করা ইত্যাদি)। আমাদের পরিবর্তনগুলি শৃঙ্খলার উপর চাপ দেওয়ার জন্য প্রস্তুত করার জন্য এখন আমাদের নতুন দেব শাখায় মেইনকে একীভূত করার বিষয়টি আমার উপর পড়েছে।

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

আমি কি এমন কোন পদ্ধতির গ্রহণ করতে পারি যা এটি আমার পক্ষে সহজ করে দেবে?

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

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


63
নাঃ। আপনার দুটি পৃথক শাখা রয়েছে যা এক বছরের জন্য সক্রিয়ভাবে বিকশিত হয়েছিল। মার্জ চুষতে চলেছে।
26

2
আপনার দল যে পরিবর্তনগুলি করেছে তার পরিমাণ কত? এই পরিবর্তনগুলি সনাক্ত করতে এবং তারপরে ম্যানুয়ালি বর্তমান মাস্টার কোডবেসে এগুলি প্রয়োগ করতে আরও দক্ষ হতে পারে।
kdgregory

2
এটি কি 2015 বা 2016 এর সম্পূর্ণতা? যদি এটির 2015 এর 2 বছর হয়, যার অর্থ এটি দু'বার স্তন্যপান করবে।
ডেভিড মনিকা

1
আপনি যদি তাদের জন্য কাজ করছেন আপনার সংস্করণ নিয়ন্ত্রণ সিস্টেমের একটি পৃথক শাখায় ক্লায়েন্ট কেন যত্ন করে না?
Ixrec

17
আপনি যাই করুন না কেন, আপনি প্রতি ঘন্টা বিল দিচ্ছেন তা নিশ্চিত করুন।
শান ম্যাকসোমিংথ

উত্তর:


37

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

যাইহোক, আইএমএইচও প্রথম দিকে যা ঘটেছে তা পুনরায় করার চেষ্টা করছে সেরা পদ্ধতির:

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

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

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

এবং হ্যাঁ, আমি গুরুতর, সম্ভবত এটির কোনও শর্টকাট নেই। এটি পরিণত হতে পারে যে "দৈনিক অংশগুলি" কখনও কখনও খুব ছোট হতে পারে তবে আমি এটির প্রত্যাশা করতাম না, আমি অনুমান করি এটি সম্ভবত দৈনিক অংশগুলি খুব বড় মৌমাছির পরিণত হতে পারে more আমি আশা করি আপনার ক্লায়েন্ট এটির জন্য আপনাকে সত্যিই ভাল অর্থ প্রদান করবে এবং এটি তার জন্য এত ব্যয়বহুল যে তিনি তার ব্যর্থতা থেকে শিখবেন।

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


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

1
@ আদারবোব: আপনার পরামর্শ অনুসারে যদি ওপি দেব থেকে ট্রাঙ্কে সংহত হয় তবেই তা বোঝা যায়, তবে যখন তিনি ট্রাঙ্ক থেকে দেবের সাথে মিশে যাওয়ার সিদ্ধান্ত নেন না, যেমনটি আমি আগে বর্ণনা করেছি। যদি ওপি ট্রাঙ্ক থেকে তার দেব শাখায় দিনে দিনে পরিবর্তিত হয় (অতীতে ৩5৫ দিন পরিবর্তনের সাথে শুরু করে) তবে ট্রাঙ্কে উন্নয়ন চলছে কিনা তা বিবেচ্য নয়। উপস্থিত না পৌঁছানো পর্যন্ত তাকে কেবল এই কৌশল অব্যাহত রাখতে হবে (ধরে নেওয়া যায় যে তিনি একদিনেরও কম সময়ে একদিনে এই ৩-৪ টি দলের পরিবর্তন সংহত করতে ও পরীক্ষা করতে পারবেন)।
ডক ব্রাউন

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

এটি ভাল পরামর্শ। কয়েকটি জিনিস সম্বোধন করতে সম্পাদনা দেখুন।
ব্যবহারকারী 258451

1
@ ব্যবহারকারী 258451: সুতরাং ট্রাঙ্কের জন্য আপনার কিউএর বিভিন্ন টিম এবং নতুন দেব শাখার জায়গায় জায়গা ছিল যারা একে অপরের সাথে কথা বলতে চাননি? দুর্দান্ত স্কট: - ((
ডক ব্রাউন

14

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

  • আসল নিমজ্জিত অবস্থার অনুলিপি নিন
  • নিমজ্জিত এবং সর্বশেষের মধ্যে পার্থক্য
  • যে কোনও সাধারণ উপাদানকে ভেঙে ফেলুন
    • উদাহরণস্বরূপ, সমস্ত ফাংশনের নাম পরিবর্তন করুন, তারপরে প্যারামিটার পরিবর্তন করুন etc.
    • মানগুলি পরিবর্তিত হলে সাদা স্থানটিকে উপেক্ষা করুন, অন্যথায় আপনি স্পেস গণনা করতে অনেক সময় নষ্ট করবেন
  • প্রথমে মূল কার্যকারিতার উপর ফোকাস করুন

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

মূল কথা হচ্ছে চালিয়ে যাওয়া।

সম্পাদনা:

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

'জ্যাক এইডলি' এবং '17-এর 26 'এর মন্তব্যে ধন্যবাদ


1
এই পদ্ধতির সাথে বড় সমস্যাটি হ'ল এটি সংস্করণ নিয়ন্ত্রণ সিস্টেমে থাকা পরিবর্তনগুলির রেকর্ডটিকে ধ্বংস করবে।
জ্যাক এইডলি

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

আপনার কাছে পরিবর্তনগুলির একটি লগ রয়েছে, তবে পরিবর্তনগুলি একটি শাখা থেকে অন্য শাখায় একীভূত হওয়ার historicalতিহাসিক প্রমাণ আপনার কাছে নেই। এটি টিএফএসে একটি বিশাল চুক্তি হবে, যা আপনাকে শাখা থেকে শাখায় মার্জ করার সময় বেছে নেওয়ার জন্য কেবল নিমজ্জনিত চেঞ্জসেট সরবরাহ করে।
26

@ 17of26 আমি সম্মত হয়েছি যে আপনি কিছু পরিবর্তন রেকর্ড পুনরুদ্ধার করতে পারেন, 26 এর মধ্যে 17 টি সঠিক যে এই রেকর্ডটি সম্পূর্ণ বা নির্ভুল হবে না। এটি হতে পারে যে এই ক্ষয়ক্ষতি রেকর্ড হ্রাস হিসাবে তারা এখন যে খারাপ পরিস্থিতির মুখোমুখি হচ্ছে তা গ্রহণযোগ্য সমঝোতা হিসাবে তৈরি করা যথেষ্ট সহজ However তবে, আমি মনে করি তারা যে সিদ্ধান্ত নেয় তা বিবেচনা না করে চিনতে এটি একটি গুরুত্বপূর্ণ অসুবিধা draw
জ্যাক এইডলি

1
@ জ্যাক এইডলি আমি অবশ্যই নিশ্চিত হলাম এটি বেশ সমস্যা, তাই আমি আমার উত্তরটি প্রতিবিম্বিত করতে কিছুটা যুক্ত করেছি। আমি আশা করি ঠিক আছে?
এরদরিক আয়রনরোজ

8

কয়েক বছর আগে আমাদের একই শাখা পৃথক রাখার প্রয়োজনীয়তার সাথে একটি ক্লায়েন্ট ছিল। সুতরাং আমরা করেছি।

আমরা তাদের শাখাটি আর কখনও মার্জ করি নি। তাদের নিজস্ব অনন্য সংস্করণ ছিল। পরিবর্তনের জন্য আমরা তাদের অতিরিক্ত অতিরিক্ত চার্জ করেছি যেহেতু মূলত আমাদের কাছে 1 টি প্রধান ট্রাঙ্ক এবং শাখার পরিবর্তে দুটি বড় ট্রাঙ্ক ছিল।

আমরা ট্রাঙ্কে ফিরে একত্রীকরণের চেষ্টা করেছি কিন্তু 2 সপ্তাহ পরে আমরা সিদ্ধান্তটি ত্যাগ করার সিদ্ধান্ত নিয়েছিলাম কারণ এটি কোনও স্পষ্টত সুবিধা ছাড়াই কয়েক ঘন্টা জ্বলছিল।

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


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

1

এটি মজাদার হতে যাচ্ছে না, তবে এটি কতটা বেদনাদায়ক হবে তা নির্ভর করে পরিবর্তনের প্রকৃতি এবং সেগুলি কীভাবে বিচ্ছিন্ন on

আমি আপনাকে পরামর্শ দিচ্ছি যে আপনি প্রকৃত সংযুক্তির আগে যতটা সম্ভব রিফ্যাক্টরিংয়ের মাধ্যমে শাখাগুলি রূপান্তর করার চেষ্টা করবেন ।

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

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

কোডের ক্ষেত্রে যেখানে উভয় শাখায় অ-তুচ্ছ পরিবর্তন হয়েছে, আপনাকে কোডটি যত্ন সহকারে পরিদর্শন করতে হবে এবং পুনরায় লেখার পদ্ধতিটি আপনাকে সিদ্ধান্ত নিতে হবে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.