আপনি কীভাবে বিকাশ কোড এবং উত্পাদন কোড বজায় রাখবেন? [বন্ধ]


136

কোড বজায় রাখার জন্য থাম্ব-অফ-থাম্বের সেরা অনুশীলন এবং নিয়মগুলি কী কী? উন্নয়ন শাখায় কেবলমাত্র প্রস্তুত রেডি কোড রাখা কি অনুশীলন, বা উন্নয়ন শাখায় অনির্ধারিত সর্বশেষ কোড পাওয়া উচিত?

আপনারা কীভাবে আপনার বিকাশ কোড এবং উত্পাদন কোড বজায় রাখবেন?

সম্পাদনা করুন - পরিপূরক প্রশ্ন - আপনার বিকাশকারী দলটি "কমিট-যত তাড়াতাড়ি সম্ভব-এবং-এমনকি-যদি-কোড-ধারণায়-মাইনর-বাগ-বা-অসম্পূর্ণ" প্রোটোকল বা "কমিট- কেবলমাত্র নিখুঁত-কোড "প্রোটোকল ডেভেলপমেন্ট শাখায় কোড করার সময়?


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

@ রেভো: অপেক্ষা করুন ... আমার ২০০৮ সালের উত্তর পুরানো? :) আমি মনে করি এটি সত্যিই আছে। এটি 10 ​​বছরেরও বেশি সময় হয়েছে: আমি আমার উত্তরটি সম্পাদনা করেছি।
ভনসি

উত্তর:


114

2019 আপডেট করুন:

আজকাল, প্রশ্নটি একটি প্রসঙ্গে গিট ব্যবহার করে দেখা যাবে এবং সেই বিতরণকৃত উন্নয়ন ব্যবহারের 10 বছর কার্যপ্রবাহের (মূলত গিটহাবের মাধ্যমে সহযোগিতা করা ) সাধারণ সেরা অনুশীলনগুলি দেখায়:

  • masterযে শাখাটি যে কোনও সময় উত্পাদনে মোতায়েনের জন্য প্রস্তুত: পরবর্তী প্রকাশ, বৈশিষ্ট্যযুক্ত শাখাগুলির একটি নির্বাচিত সেট মার্জ করে master
  • dev(বা ইন্টিগ্রেশন শাখা, বা ' next') হ'ল এটিই যেখানে পরবর্তী প্রকাশের জন্য নির্বাচিত বৈশিষ্ট্য শাখাটি একসাথে পরীক্ষা করা হয়
  • maintenance(বা hot-fix) শাখা হ'ল বর্তমান রিলিজ বিবর্তন / বাগ ফিক্সগুলির মধ্যে একটি, সম্ভাব্য সংযোজনগুলির সাথে ফিরে devএবং বা withmaster

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

https://github.com/rocketraman/gitworkflow/raw/master/docs/images/topicgraduation.png

(উৎস: গিট ওয়ার্কফ্লো: একটি কার্য-ওরিয়েন্টেড প্রাইমার )

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


আসল উত্তর (অক্টোবর ২০০৮, ১০+ বছর আগে)

এটি আপনার রিলিজ পরিচালনার ক্রম প্রকৃতির উপর নির্ভর করে

প্রথমত, আপনার ট্রাঙ্কের সমস্ত কি পরবর্তী প্রকাশের জন্য সত্যই ? আপনি সন্ধান করতে পারেন যে বর্তমানে বিকাশিত কিছু ফাংশনগুলি হ'ল:

  • খুব জটিল এবং এখনও পরিমার্জন করা প্রয়োজন
  • সময় মতো প্রস্তুত নয়
  • আকর্ষণীয় তবে এই পরবর্তী প্রকাশের জন্য নয়

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

প্রযোজনা কোডের কথা এলে, আপনার মনে রাখবেন যে আপনার প্যাচ শাখাগুলিও পরিচালনা করতে হবে:

  • প্রথম প্যাচগুলির প্রথম সেটটি প্রথম উত্পাদনে প্রকাশের আগেই শুরু হতে পারে (যার অর্থ আপনি জানেন যে আপনি কিছু বাগ সহ প্রযোজনায় যাবেন যা আপনি ঠিক করতে পারবেন না তবে আপনি সেই বাগগুলির জন্য আলাদা শাখায় কাজ শুরু করতে পারেন)
  • অন্যান্য প্যাচ শাখাগুলিতে একটি সু-সংজ্ঞায়িত উত্পাদন লেবেল থেকে শুরু করার জন্য বিলাসিতা থাকবে

যখন দেব শাখার কথা আসে, আপনার কাছে একটি ট্রাঙ্ক থাকতে পারে, যদি না আপনার সমান্তরালভাবে অন্যান্য উন্নয়ন প্রচেষ্টা করা দরকার তবে :

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

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


ভিলি এম এর মন্তব্যের জবাব দিতে:

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

1
@ অ্যাডাম সম্পাদনার জন্য আপনাকে ধন্যবাদ, এবং যথাযথ অ্যাট্রিবিউশনটি শীঘ্রই সেট না করার জন্য দুঃখিত।
ভনসি

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

43

আমরা ব্যাবহার করি:

  • একচেটিয়াভাবে উন্নয়ন শাখা

যতক্ষণ না প্রকল্পটি সমাপ্ত হয়, বা আমরা একটি মাইলফলক সংস্করণ তৈরি করছি (উদাঃ প্রোডাক্ট ডেমো, উপস্থাপনা সংস্করণ), তারপরে আমরা (নিয়মিত) আমাদের বর্তমান বিকাশ শাখাটি শাখায় বন্ধ করে দেব:

  • রিলিজ শাখা

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

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

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

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

চেক-ইন প্রারম্ভিক প্রশ্নে:

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

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

এখন থেকে এবং তখনই একটি অপ্রয়োজনীয় সংযুক্ত কোড এবং ডেটা চেকইন নতুন কোড তৈরি না হওয়া পর্যন্ত প্রোগ্রামটিকে অকেজো করে তুলবে। আমরা যা করি তা হ'ল চেক-ইন মন্তব্যে একটি "ওয়েট ফর বিল্ড" যুক্ত করা এবং / অথবা একটি ইমেল প্রেরণ করা।


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

2
আপনি বোঝাচ্ছেন যে কিউএ উন্নয়ন শাখার পরীক্ষা করে, তারা যদি মুক্তির শাখাটি পরীক্ষা করে তবে ভাল হয় না? এইভাবে আমি আমার নতুন উন্মাদ বৈশিষ্ট্যটিতে কাজ শুরু করতে পারি যা পরবর্তী প্রকাশে অন্তর্ভুক্ত করা হবে না (এবং কোনও কিছু ভেঙে দিতে পারে) তখন কিউএ আমার নতুন বৈশিষ্ট্যটি হস্তক্ষেপ না করে বিদ্যমান কোডটি পরীক্ষা করবে?
BornToCode

15

এটির জন্য মূল্য কী, আমরা এটি এটিই করি।

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

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

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

তারপরে রক্ষণাবেক্ষণটি প্রয়োজনীয় হিসাবে রিলিজ শাখায় করা যেতে পারে এবং এই ফিক্সগুলি সহজেই ট্রাঙ্কে আবার একত্রিত করা যায়।

আমি এটিকে একটি নিখুঁত সিস্টেম বলে দাবি করি না (এবং এটিতে এখনও কিছু গর্ত রয়েছে - আমি মনে করি না যে আমাদের রিলিজ ম্যানেজমেন্টটি এখনও যথেষ্ট শক্ত প্রক্রিয়া নয়) তবে এটি যথেষ্ট ভালভাবে কাজ করে।


যথেষ্ট ভাল কাজ করে এবং কেবল-কেবল-নন-ভিসিএস-ড্রুড বিকাশকারীদের পক্ষে যথেষ্ট সহজ।
ম্যাথিউউ

12

কেন এখনও কেউ এ বিষয়টি উল্লেখ করে না? একটি সফল গিট ব্রাঞ্চিং মডেল

এটা আমার জন্য চূড়ান্ত শাখা মডেল!

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

শাখা মডেল


4
হ্যাঁ, স্কটিচকন ডটকম / ২০১৮ / ২০১31 / 31 / গিথুব-ফ্লাওয়ার এইচটিএমএল চিত্রিত হিসাবে এটি প্রায়শই কিছুটা জটিল / সম্পূর্ণ না হলে ব্যতীত ।
ভনসি

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

1
আমি যেভাবে দেখছি, এটি মূলত ভনসি প্রায় 1 বছর পূর্বে (তার উত্তরে) যা বলেছিল সবগুলি অনুলিপি করে, তবে আরও বিশদভাবে এবং সুন্দর ছবি সহ!
ক্রেগোক্স

6

শাখায় বিকাশ কোড, ট্রাঙ্কে লাইভ কোড ট্যাগ।

"কেবলমাত্র নিখুঁত কোডের প্রতিশ্রুতিবদ্ধ" বিধি তৈরি করার দরকার নেই - যা বিকাশকারী চারটি স্থানে মিস করতে পারে সেটিকে: কোড পর্যালোচনা, শাখা পরীক্ষা, রিগ্রেশন টেস্টিং, চূড়ান্ত কিউএ টেস্টিং।

এখানে আরও বিস্তারিত ধাপে ধাপে ব্যাখ্যা:

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

4

দেব ট্রাঙ্কে চলে যায় (এসএনএন শৈলী) এবং প্রকাশগুলি (প্রোডাকশন কোড) তাদের নিজস্ব শাখা পায়

এটি "শাখা দ্বারা উদ্দেশ্য মডেল" (শাখা- প্রশাখা মডেলগুলির গুরুত্বের মধ্যে চিত্র 3 /! পিডিএফ)


3

আমরা প্রোডাকশন কোডটি (মূল ট্রাঙ্ক) সম্পূর্ণভাবে উন্নয়ন কোড (যেখানে প্রতিটি বিকাশকারীর নিজস্ব শাখা রয়েছে) থেকে আলাদা করে এই সমস্যার সমাধান করি।

কোনও কোডের পুঙ্খানুপুঙ্খভাবে চেক করার আগে প্রোডাক্ট কোডে প্রবেশের অনুমতি নেই (কিউএ এবং কোড পর্যালোচকরা)।

এই পদ্ধতিতে কোন কোডটি কাজ করে সে সম্পর্কে কোনও বিভ্রান্তি নেই, এটি সর্বদা প্রধান শাখা।


2

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


2
পূর্ববর্তী উত্তরের সম্পাদনা হিসাবে এটি আরও ভাল হতে পারে।
রিচার্ড হ্যারিসন

6
তিনি বলেন সিভিএস। :-)
পর্যন্ত

2

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

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

মূলত যে কোনও সময় ট্রাঙ্কের শাখা করা এবং এটি উত্পাদন করা সম্ভব possible


0

আমি গিট ব্যবহার করি এবং আমার 2 টি শাখা রয়েছে: মাস্টার এবং রক্ষণাবেক্ষণ

  • মাস্টার - উন্নয়ন কোড
  • রক্ষণাবেক্ষণ - উত্পাদন কোড

যখন আমি উৎপাদন কোড মুক্তি, আমি এটিকে ট্যাগ এবং আমি একত্রীকরণ মাস্টার থেকে maint শাখা। আমি সর্বদা রক্ষণাবেক্ষণ শাখা থেকে মোতায়েন করি । বিকাশ শাখা থেকে প্যাচগুলি আমি চেরি-পিকগুলি রক্ষণাবেক্ষণ শাখায় এবং প্যাচগুলি স্থাপন করি।


0

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

প্রতিটি প্রকল্প, বা কিছু ক্ষেত্রে অন্যান্য ইউনিটের নিজস্ব শাখা রয়েছে যা মুক্তি থেকে শাখা থাকে।

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

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

একত্রিত হয়ে যাওয়ার পরে কোনও সমস্যা আবিষ্কার না হওয়া অবধি প্রক্রিয়াটি মূলত ঠিক আছে। যদি কোনও ডাব্লুপি মিশ্রিত হওয়ার পরে "আটকে" যায়, এটি স্থির না হওয়া পর্যন্ত এটি সমস্ত কিছু ধরে রাখে (আটকে থাকাটিকে মুক্তি না দেওয়া পর্যন্ত আমরা আর কোনও প্রকাশ করতে পারি না)।


এটি কিছুটা নমনীয়ও হয় - খুব অল্প সময়ের মধ্যে খুব সহজেই প্রকাশ হতে পারে যদি এটি খুব অল্প সময়ের স্কেলে প্রকাশিত হয় (যেমন 1-2 দিনের মতো)।

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


0

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

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