ডিভিসিএস-এ ভুল শাখায় প্রতিশ্রুতিবদ্ধ বিকাশকারীদের থামানো


12

সমস্যাটি

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

এর ফলে ফলাফলগুলি ভুল প্রতিশ্রুতি, বা ভুল (সম্ভবত অ-কিউএডি) কোডটি পৌঁছে দেওয়া এবং ভুল শাখায় মোতায়েন করা ব্যয় করতে ব্যয় করেছিল, যদি আমরা লক্ষ্য করি না যে কোডটি ভুল শাখায় চলে গেছে।

আমাদের শাখা এবং মার্জ ডিজাইন / পদ্ধতি

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

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

যেটি ঘটতে পারে তা হ'ল কোনও বিকাশকারী ভি 2-দেব শাখার জন্য ভি 1-ডেভ বা ভি 1-প্রোডে রূপান্তর করে বা আরও খারাপ, তারা ভি 2-দেবকে ভি 1-প্রোড (বা এই জাতীয় অনুরূপ ভুল) এ একীভূত করে।

আমরা বেশিরভাগ বিকাশকারীকে বলি- প্রড শাখাগুলি অ্যাক্সেস না করার জন্য , তবে কোডটি এখনও সাইন ইন করে more আরও প্রবীণ বিকাশকারীদের একটি দল 'প্রড শাখাটি দেখাশোনা করবে'।

এটি লক্ষ করা উচিত যে যখন ভি 2 সবেমাত্র বিকাশ শুরু করেছে, এখনও সমস্যাগুলি সমাধানের জন্য বেশ কয়েকটি শক্ত প্যাচগুলি ভি 1 এ চলে যেতে পারে। অর্থাত্ ভি 1 কেবলমাত্র বিজোড় ছোট প্যাচটি পাচ্ছে না।

আমরা এখন পর্যন্ত কি চেষ্টা করেছি

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

বিকাশকারীদের ভুল শাখায় প্রতিশ্রুতিবদ্ধ হওয়ার সম্ভাব্য কারণগুলি

  • খুব জটিল একটি শাখা নকশা
  • সমান্তরালে একাধিক শাখায় সক্রিয় বিকাশ। (প্রকল্পটি হিমসাগর-মডেল ব্যবহারের লক্ষণগুলি প্রদর্শন করে ))
  • বিকাশকারীরা ডিভিসিএসকে যথেষ্ট পরিমাণে বুঝতে পারেন না

আমি যে প্রশ্নগুলি পড়েছি তা কিছুটা প্রাসঙ্গিক ছিল

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

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

প্রশ্ন

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

আমার বিশ্বাস যে কারণে উপরে বর্ণিত হিসাবে অবদান রাখতে পারে সে সম্পর্কে নির্দিষ্ট মন্তব্য প্রশংসিত হবে, তবে এটি আপনার উত্তর সীমাবদ্ধ করা উচিত নয়।


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

এটি আংশিকভাবে পরিচালনা সংক্রান্ত সমস্যা, তবে এটি বিকাশকারীদের বুদ্ধিমান পছন্দ করতে দেয়ায় এটি একটি সরঞ্জামও।
মাইকেল শ '

উত্তর:


22

সমস্যাটি হচ্ছে আপনি প্রক্রিয়াটির মধ্য দিয়ে একটি শাখার অর্থ আংশিক উপায় পরিবর্তন করছেন ।

প্রাথমিকভাবে, v1 devশাখাটি উন্নয়নের জন্য। সমস্ত নতুন বৈশিষ্ট্য সেখানে। ভবিষ্যতের কোনও পর্যায়ে, এটি শাখার রক্ষণাবেক্ষণ শাখায় পরিণত হয় v1 release। এটিই সমস্যার ক্রুક્સ।

এটি এমন নয় যে বিকাশকারীগুলি opিপি হয় না, শাখার অনুমতি এবং ভূমিকা খালি এবং পরিবর্তনের সাপেক্ষে।

আপনার যা করা দরকার তা হ'ল প্রতিটি শাখার ভূমিকা কী তা প্রতিষ্ঠিত করা এবং সেই ভূমিকা বজায় রাখা। ভূমিকা পরিবর্তন হলে, শাখা।

উদাহরণ স্বরূপ:

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

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

একটি নিবন্ধ যা আপনার পড়া উচিত (এবং এটি সম্ভবত 'উচিত' এর জন্য একটি সংক্ষিপ্ত বিবরণ) হ'ল স্টিফেন ভ্যানসের অ্যাডভান্সড এসসিএম ব্রাঞ্চিং কৌশল

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

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

এই ভূমিকাগুলি হল:

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

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

ঠিক আছে, আপনি বলছেন, দুর্দান্ত, তবে এটি পারফরমেন্সের জন্য লেখা হয়েছিল যা একটি কেন্দ্রীয় ভিসিএস - আমি ডিভিসিএস ব্যবহার করছি।

পড়তে দেয় Git-প্রবাহ মডেল এবং দেখ কিভাবে এটা প্রযোজ্য।

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

ভূমিকা নীতিগুলি হুবহু মিলে না গেলেও (প্রতিটি পণ্যটির নিজস্ব কিছুটা পৃথক পৃথক পৃথক পৃথক পৃথক পৃথক পৃথক পৃথক পৃথক পৃথক পৃথক পৃথক পৃথক পৃথক লাইকসাইকেল থাকে), সেগুলি একটি মিল।

এটি করার ফলে আপনার শাখার নীতিটি সহজ করা উচিত এবং জড়িত প্রত্যেকের পক্ষে আরও সহজ করা উচিত।


+1 দুর্দান্ত প্রযুক্তিগত উত্তর, সে যদি এটি নথি না দেয় তবে সম্ভবত কাজ করবে work ব্রাঞ্চিং স্ট্র্যাটাজি সুস্পষ্ট পদ্ধতিগুলির সাথে নথিভুক্ত না করা হলে সমস্যা সম্পূর্ণরূপে সমাধানের সম্ভাবনা নেই।
mattnz

1
@ ম্যাটনজ আরও নিখুঁত শাখাগুলি রয়েছে (গাদ, আমি শব্দটি ব্যবহার করতে যাচ্ছি) নিদর্শনগুলি। যাইহোক, 'প্রত্যেকে প্রত্যেকে দেবকে প্রতিশ্রুতিবদ্ধ' এবং 'প্রস্তুত হয়ে গেলে, দেবের কাছ থেকে একটি রিলিজ করুন' আপনাকে সমাধানের 90% পথ পান should তারপরে কেবলমাত্র অডবোলের কেসগুলি হ'ল 'প্যাচ নিয়ে কাজ করা' এবং তারপরে এটি একটি "আমি জানি আমি এটি পুরানো মুক্তির জন্য করছি, সেই শাখায় স্যুইচ করুন"।

1
আমি এই উত্তরটি মেনে নিয়েছি কারণ এটি আমাদের এসসিএম-তে পরিবর্তন আনার ভিত্তি তৈরি করবে। অ্যাডভান্সড এসসিএম ব্রাঞ্চিং স্ট্র্যাটাজি এবং গিট-ফ্লো মডেলের লিঙ্কগুলি বিশেষভাবে প্রশংসা করা হয়েছে। আমরা আমাদের বিকাশকারীরা এইচিজির সাথে কী করবে তা বোঝার উন্নতি করতে প্রশিক্ষণে চেষ্টা করব এবং বিনিয়োগ করব।
imp25

@ ইম 25 আপনি এইচজি-প্রবাহকে গিটের পরিবর্তে এইচজি পাশের জন্য দরকারী বলে মনে করতে পারেন।

@ imp25 (এবং কিছু Stackoverflow প্রশ্ন ও hgflow সম্পর্কিত উত্তরগুলি - stackoverflow.com/questions/14011921/... stackoverflow.com/questions/13021807/... )

3

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

যেহেতু লোকেরা অভিজ্ঞতা অর্জন করে, ততই গভীর ধারণা বা যত্নের অভাব বোধ করার জন্য তাদেরকে দ্বাররক্ষকের ভূমিকায় ঘোরানো উচিত।

এবং একটি সাধারণ নিয়ম হিসাবে, ওকামের রেজার প্রয়োগ করুন: পুরো রেপো কাঠামোর কাজটি করা যতটা সম্ভব সহজ হওয়া উচিত।

শানের মন্তব্যও দেখুন।


2

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

আমি পরামর্শ দিয়েছি যে প্রত্যেকে নিয়মিতভাবে এই সমস্ত শাখায় কাজ করছে এই বিষয়টি নিয়ে আপনার সমস্যা হয়েছে got

@ অ্যান্ডি 256 এর প্রোডের জন্য পৃথক ভাণ্ডারের পরামর্শ অবশ্যই সহায়তা করবে তবে আপনাকে এই কাজটি অন্যভাবে পার্সেলিংয়ের বিষয়ে বিবেচনা করতে হবে, বা কোনও জিনিস নির্দিষ্টভাবে সাজানো উচিত যাতে কোনও দেব কোনও নির্দিষ্ট সপ্তাহে একাধিক শাখায় কাজ না করে।


1

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

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

অন্যান্য শাখাগুলিতে কোন পরিবর্তনগুলি অনুলিপি করা দরকার এবং কখন এটি হওয়ার দরকার হয় তা নির্বাচন করার জন্য সরঞ্জামগুলি সত্যই দুর্বল। গিট-ফ্লো একটি ব্রাঞ্চিং কৌশল তৈরি করে এটি সমাধান করার চেষ্টা করে যার অর্থ এই যে যখন শাখাগুলি মার্জ করা হয় তখন এর সমস্ত পরিবর্তনগুলি একত্রিত হয়ে যায় এবং তারপরে প্রোগ্রামারকে কখন এবং কোন শাখাগুলি একত্রিত করা হয় সে সম্পর্কে বুদ্ধিমান পছন্দ করার প্রয়োজন হয়।

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

জটিল পরিবেশটি এমন যেখানে আপনি অন্যান্য দলে অভ্যন্তরীণ রিলিজ করে মোট সমাধানের বিভিন্ন দিকের জন্য দায়ী একাধিক দল। গিট-ফ্লো কেবল এই ধরণের সমস্যা সমাধানে সক্ষম নয়।

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

কার্যকরভাবে বিকাশকারীদের একটি দল পরিবর্তনের গ্রুপগুলি সংশোধন করে যা সরানো দরকার এবং পরিবর্তনগুলি প্রাপ্ত বিকাশকারীরা পরিবর্তনের দলটি গ্রহণ করার পরে তাদের সংজ্ঞা দেয়।

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

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