আপনি প্রতিটি স্প্রিন্টে একাধিক শাখা / বিকাশকারীদের কাছ থেকে সংহতকরণ কোড কীভাবে পরিচালনা করবেন?

Question

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

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

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

Comments

আপনার কি এমন কোনও উন্নয়ন শাখা নেই যেখানে অবিচ্ছিন্ন ইন্টিগ্রেশন করা হয়?

— কায়মন

আমি এখানে কায়ামানের সাথে আছি, এর জন্য সর্বোত্তম অনুশীলন হ'ল ধারাবাহিক সংহতকরণ বাস্তবায়ন করা।

— র্যান্ডম ইউএস 1

শুভ মার্জ ডে! আপনার সমস্যাটি ডেইলি ডাব্লুটিএফ-এর কোনও কিছুর সাথে খুব সমান হয়, আপনি জানেন যে আপনি সমস্যায় পড়েছেন।

— ব্যবহারকারী 3067860

তাড়াতাড়ি মার্জ করুন, প্রায়শই মার্জ করুন: smal ক্ষুদ্রতম পরীক্ষার কোডটি লিখুন যা ব্যর্থ হবে (লাল), ক্ষুদ্রতম উত্পাদন কোডটি লিখুন যা পাস করবে (সবুজ), রিফ্যাক্টর, পুনরায় পরীক্ষা করবে, মার্জ হবে} শেষ না হয়ে।

— ctrl-alt-delor

প্রথম চেক ইন জয়! কখনও শেষ হবে না! :-)

— চককট্রিল

Answer 1

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

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

developশাখা সবসময় কোড কাজ আছে, এবং যে কোনো সময়ে মুক্তির জন্য প্রস্তুত হতে হবে। আপনি এমন একটি ঋণ ক্ষমা করেন, তখন আপনি একত্রীকরণ developমধ্যে masterএবং ট্যাগ করুন।

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

Comments

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

— আমন

@ আমন, একমত "বৈশিষ্ট্য শাখা" শব্দ যুক্ত হয়েছে, তবে এই উত্তরটি মোটামুটি ছোট রাখার চেষ্টা করছে। প্রচুর ভাল নিবন্ধ রয়েছে যা এই প্রক্রিয়াটির আরও গভীরতায় যায়।

— বেরিন লরিটস

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

— রব ক্রফোর্ড

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

— রেফু

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

— কিউবিক

Answer 2

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

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

Comments

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

— আমন

হ্যাঁ - এটি "ক্রমাগত সংহতকরণ" এর অর্থ কী! আপনি ক্রমাগত আপনার পরিবর্তনগুলি অন্য বিকাশকারীদের পরিবর্তনের সাথে সংহত করছেন!

— রব ক্রফোর্ড

@ রব, একমত আমার বক্তব্যটি বোঝাতে চাইছিল না যে ধারাবাহিক সংহতটি ভাল, ধারাবাহিক নয়। কেবলমাত্র আমরা আদর্শটিকে বেশ কার্যকরভাবে তৈরি করতে পারি নি এবং এখনও এটির কাছে গিয়ে অনেক উপকারিতা দেখেছি।

— ড্যানিয়েল

Answer 3

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

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

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

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

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

Answer 4

না

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

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

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

Comments

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

— বারিন লরিটস

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

— মমথিস

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

— ড্যান নীলি

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

— বেরিন লরিটস

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

— ড্যান নীলি

Answer 5

দেরী এবং বৃহত মার্জগুলি এড়ানোর জন্য আরেকটি সম্ভাব্য পন্থা হ'ল বৈশিষ্ট্যযুক্ত পতাকা : আপনি নিজের পরিবর্তনগুলি একটি (আদর্শভাবে গতিশীল) কনফিগারযোগ্য পতাকা দ্বারা সুরক্ষিত করেন যা তাদের উদ্দেশ্য পূর্বে সক্রিয় হতে বাধা দেয়।

এটি আপনাকে কিছু পরিবর্তন না করে আপনার পরিবর্তনগুলি প্রথম দিকে masterবা আপনার যৌথ বিকাশ শাখায় মার্জ করার অনুমতি দেয় । অন্যান্য বিকাশকারীরা তারপরে এই পরিবর্তনগুলি আবার তাদের বৈশিষ্ট্য শাখায় মার্জ করতে পারেন (বা সেইসাথে তাদের শাখাগুলি পুনরায়)।

অন্যান্য উত্তরগুলি ইতিমধ্যে নির্দেশ করেছে যে এটি একটি অবিচ্ছিন্ন ইন্টিগ্রেশন সমাধানের সাথে একত্রিত করা উচিত।

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

Answer 6

আমরা প্রতিটি বৈশিষ্ট্যের জন্য পৃথক উন্নয়ন শাখার একটি পদ্ধতির অনুসরণ করছি এবং তারপরে আমরা সংহতকরণ পরীক্ষার পরিবেশে পরীক্ষার জন্য শাখাগুলি একটি QA শাখায় মার্জ করছি।

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

যদি সবকিছু ঠিকঠাক হয় তবে আমরা রিলিজ শাখাটিকে মাস্টার শাখায় ফেরত দেব।

Answer 7

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

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

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