দীর্ঘকাল ধরে চলমান অপ্রকাশিত কোডের জন্য গিট শাখার কৌশল


15

আমাদের দলে, কাজের পৃথক ইউনিট (গল্পগুলি) ছাড়াও, আমাদের দীর্ঘকালীন কাজের থিম রয়েছে (এপিক্স)। একাধিক গল্প একটি মহাকাব্য তৈরি করে।

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

এটি অর্জনের জন্য কীভাবে আমাদের রেপো পরিচালনা করবেন সে সম্পর্কে কোনও পরামর্শ আছে? আমি "মহাকাব্য শাখা" প্রবর্তন বিবেচনা করেছি, যেখানে আমরা বন্ধের গল্পগুলি সরাসরি মাস্টারের পরিবর্তে সম্পর্কিত মহাকাব্য শাখায় মার্জ করতাম, তবে আমার উদ্বেগগুলি হ'ল:

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

উত্তর:


23

সাধারণ পরামর্শ: এটি করবেন না।

গিট শাখাগুলি কোডটির দীর্ঘকাল ধরে চলমান কাঁটাচামচগুলির জন্য নয়, যেমনটি এখানে আলোচনা করা হয়েছে এবং https://blog.newrelic.com/2012/11/14/long-running-branches-considered-harmful/ । শাখাগুলি প্রতিদিনের স্তরে পৃথক বিকাশকারী দ্বারা কমিটগুলি সংগঠিত করতে ব্যবহৃত ক্ষণস্থায়ী জিনিস হিসাবে সেরা হিসাবে বিবেচিত হয়। সুতরাং যদি তাদের কোনও নাম থাকে যা কোনও প্রকল্প পরিচালক (কিছুতেই শেষ ব্যবহারকারীকে ছেড়ে দেয়) এমন কিছু যা আপনার কোনও ভুল করছেন সে সম্পর্কে যত্নশীল হতে পারে।

প্রস্তাবিত অনুশীলনটি বৈশিষ্ট্য টগলস বা শাখা-বাই-অ্যাবস্ট্রাকশন সহ এটি নিশ্চিত করার জন্য অবিচ্ছিন্ন সংহতকরণ ব্যবহার করা হয় :

  • সমস্ত কোড সর্বদা সংহত করা হয় (কমপক্ষে প্রতিদিন, প্রায়শই আরও প্রায়শই)
  • যা মোতায়েন করা হয় তা সুস্পষ্ট নিয়ন্ত্রণাধীন।

1
আমি সন্দেহ করি এটি একটি জনপ্রিয় উত্তর হতে পারে! এর সাথে আমার প্রধান উদ্বেগগুলি হ'ল 'লাইভ' এবং 'পরবর্তী' বাস্তবায়ন উভয়ই বজায় রাখার ওভারহেড এবং এটিরও প্রয়োজন যে কোনও বৈশিষ্ট্যে কাজ করা দেব আপগ্রেড (/ প্রতিস্থাপন) পরিবর্তে নতুন সমান্তরাল বৈশিষ্ট্য হিসাবে পরিবর্তনগুলি গড়ে তুলতে অগ্রগামী জানেন বিদ্যমান কার্যকারিতা। অনুমান করুন এটি দলে বৃহত্তর মানসিকতার পরিবর্তনের জন্য প্রয়োজন।
সীতাতি

এটা তোলে শাখা ব্যবহার করার জন্য ঠিক আছে বিকাশ , কোড শুধু ওদের ব্যবহার দোকান কোড। সুতরাং যদি আপনি নিশ্চিত না হন যে কোনও কাজটি 30 মিনিটের স্থির বা 2 সপ্তাহের পুনরায় কাজ করা হয় তবে একটি শাখায় শুরু করুন। যত তাড়াতাড়ি আপনি জানেন, একটি বিমূর্তকরণ / টগলে মার্জ করুন বা রিফ্যাক্টর তারপর মার্জ করুন।
soru

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

2
লিঙ্কযুক্ত ব্লগ পোস্টটি এখন 5 বছরের পুরানো। আমি বৈশিষ্ট্য টগলগুলি ঘৃণা করি। দীর্ঘমেয়াদী শাখা করা, প্রধান থেকে ফিচার শাখায় নিয়মিত ফিরিয়ে দেওয়া এবং দীর্ঘমেয়াদী বৈশিষ্ট্য শাখায় অবিচ্ছিন্ন সংহতকরণে কী সমস্যা?
জেসন কেলি

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

1

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

যেমন।

আমার পণ্যের ভি 2 এর জন্য আমার কাছে এ, বি এবং সি বৈশিষ্ট্য রয়েছে। বি এবং সি সম্পর্কিত, আমি সি ছাড়াই চাই না যদি সিও শেষ না হয়।

আমার তিনটি দেব একই সাথে ফিচারগুলিতে কাজ করছে।

আমার পাথর মুক্তির তারিখ রয়েছে D

বি শেষ হয়ে যায় এবং একত্রী হয়, এ শেষ হয় এবং একত্রী হয়ে যায়। সি বিলম্বিত হয় ... আমি কী করব ?!

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

সমাধান আরও একটি মানুষের। আপনি আপনার মুক্তির তারিখটি মিস করেছেন এবং অবশ্যই এটি পিছনে যেতে হবে।


1

এটি একটি জটিল সমস্যা তবে অনেকের মুখোমুখি। আমি গিটফ্লো সেটআপটিকে একটি প্রাথমিক পয়েন্ট হিসাবে ব্যবহার করতে পছন্দ করি।

বিকাশ ->
মাস্টারে নতুন স্টাফ কাজ করা হচ্ছে -> উত্পাদনের পরীক্ষার প্রয়োজন সমাপ্ত জিনিস -> স্টাফ যা উত্পাদনে প্রকাশিত হয়েছে।

গৌণ (সংক্ষিপ্ত) বৈশিষ্ট্যগুলিতে আমি উন্নয়ন থেকে একটি শাখা তৈরি করি সেখানে কাজ করুন তারপর শাখাটি উন্নয়নে ফিরিয়ে দিন।

প্রধান (দীর্ঘমেয়াদী) বৈশিষ্ট্যগুলিতে আমি বিকাশ থেকে একটি শাখা তৈরি করি, branch শাখা থেকে ছোট শাখা তৈরি করি, তারপরে আবার প্রথম শাখায় মার্জ করি। একবার প্রধান বৈশিষ্ট্যটি সম্পূর্ণ হয়ে গেলে আবার উন্নয়ন শাখায় ফিরে যায়।

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

যে কোনও সময় মাস্টারকে বিকাশের সাথে একত্রীকরণ করা উচিত এবং এর যে কোনও দীর্ঘমেয়াদী শাখায় বিকাশ করা উচিত।

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

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

আমার সাধারন গাছ দেখতে ভাল লাগে

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production  

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

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


"প্রধান (দীর্ঘমেয়াদী) বৈশিষ্ট্যগুলিতে আমি উন্নয়ন থেকে একটি শাখা তৈরি করি" - আপনি কি উত্পাদন শাখা থেকে নতুন বৈশিষ্ট্য (উন্নয়ন) শাখা তৈরি করবেন না? প্রোডাকশন শাখা হিসাবে দেখা হচ্ছে রিলিজ-রেডি কোড।
রোবোট্রন

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

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

হ্যাঁ, এটি হবে। মাস্টারটিতে একটি নির্দিষ্ট এসএএ-এর কিউএ পরীক্ষাগুলি, তবে আপনি এটির জন্য ডিপ আপ করতে পারবেন না।
কোটায়ার

"মাস্টারে একটি নির্দিষ্ট এসএএএর কিউএ টেস্টগুলি" -> কিউএ প্রতিটি নতুন বৈশিষ্ট্যকে স্ট্যান্ডেলোন হিসাবে পরীক্ষা করে? আমার দলটি আপনার মুখোমুখি একটি সাধারণ দৃশ্যের মুখোমুখি হয়ে উঠুন: বলুন যে একই কোডবেজে আপনার দীর্ঘ দুটি প্রকল্প রয়েছে: প্রকল্প এ গত এক মাসের জন্য কিউএতে রয়েছে এবং অন্য এক মাসের জন্য কিউএড হবে। প্রকল্প বি গত 6 মাস ধরে বিকাশে ছিল এবং এখন QA এর জন্য প্রস্তুত। প্রকল্প এ মাস্টারের সাথে একীভূত হয়ে গেছে এবং অসংখ্য সূক্ষ্ম ব্যবসায়িক বিধি ত্রুটির কারণে অবশ্যই উত্পাদন প্রস্তুত নয়। আমরা কীভাবে প্রকল্প বি পরিচালনা করব? কথোপকথনগুলি পরীক্ষা করার জন্য A এবং B কে একসাথে পরীক্ষা করতে হবে (বি সংযুক্তির সময় বিবাদ সৃষ্টি করবে না)।
রোবোট্রন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.