স্ক্র্যাম এবং একটি স্থিতিশীল উন্নয়ন কি দ্বন্দ্ব তৈরি করে?


11

আমি প্রায় ৪০ টি বিকাশকারী, ৫ টি দল নিয়ে একটি উন্নয়ন গোষ্ঠীর অংশ part আমরা 3 সপ্তাহের স্প্রিন্ট সহ স্ক্রম পদ্ধতি অনুসরণ করছি। আমাদের একটি ক্রমাগত ইন্টিগ্রেশন সেটআপ রয়েছে (জেনকিনস), একটি বিল্ড পাইপলাইন কয়েক ঘন্টা সময় নেয় (ব্যাপক স্বয়ংক্রিয় পরীক্ষার কারণে)। মূলত, উন্নয়ন প্রক্রিয়াটি ভালভাবে কাজ করে।

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

  • প্রতিটি কমিট পরীক্ষার একটি বেসিক সেট বিরুদ্ধে যাচাই করা হয়। একবার যাচাই হয়ে গেলে, কোডটি পর্যালোচনা (গেরিট) পরে পরিবর্তনটি মাস্টারকে ধাক্কা দেওয়া হয়
  • বেসিক ইউনিট পরীক্ষাগুলি প্রতি 30 মিনিটে সঞ্চালিত হয়, সময়কাল 10 মিনিটের চেয়ে কম হয়
  • একীকরণ পরীক্ষা প্রতি 2 ঘন্টা, সময়কাল 1 ঘন্টা চালানো হয়
  • UI- / ওয়েবসেটগুলি সফল ইন্টিগ্রেশন টেস্টে চালিত হয়, সময়কাল বেশ কয়েক ঘন্টা

স্প্রিন্ট চলাকালীন স্থিতিশীলতার জন্য কে দায়ী, তার উপর নির্ভর করে (সেই স্প্রিন্টের প্রতি দায়িত্বটি পাশ হয়ে গেছে), বিল্ডটি স্থিতিশীল করতে ফিরে পেতে মধ্যবর্তী, অ্যাড-হক "কমিট স্টপস" থাকতে পারে।

সুতরাং, আমরা চাই:

  1. আমাদের ডেভ টিমগুলি একটি স্প্রিন্টের বিহীন ওঠাকালীন সময়ে বিকাশ ও পরিবর্তন প্রতিশ্রুতিবদ্ধ
  2. আমাদের বিল্ড প্রক্রিয়াটি যদি কোনও বিল্ড স্টেপ ব্যর্থ হয় তবে তা ত্যাগ করতে হবে, কারণ পরবর্তী বিল্ড ফলাফলগুলির কোনও অর্থ নেই
  3. সময়োপযোগী বিকাশকারীদের গুণমানের প্রতিক্রিয়া জানাতে আমাদের বিল্ড প্রক্রিয়া

প্রদত্ত (2), পয়েন্ট (1) এবং (3) একে অপরের বিরোধিতা বলে মনে হচ্ছে। এটি মোকাবেলা করার জন্য কারও কি একটি ভাল অনুশীলন রয়েছে?

( আমরা বর্তমানে পয়েন্ট (2) শিথিল করছি, এমনকি ব্যর্থ বিল্ড স্টেপগুলিতেও ক্রমাগত বিল্ডিংকে অনুমতি দিচ্ছি that এটি কীভাবে আমাদের মানকে প্রভাবিত করে তা এখনও আমার কোনও প্রতিক্রিয়া নেই )

ধন্যবাদ, সাইমন


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

আপনার বিল্ড এনভায়রনমেন্ট অন-প্রিমিস বা মেঘ-ভিত্তিক?
লৌরি লয়ান্টি

@ লৌরিলান্টি, আমাদের বিল্ড এনভায়রনমেন্টটি প্রাক-ভিত্তিতে রয়েছে, 1 জেনকিন্স উদাহরণস্বরূপ 3 দাস।
সাইমন

উত্তর:


7

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

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

আপনি সর্বশেষে "সফল" বিল্ডের একটি স্বয়ংক্রিয় পরীক্ষা যোগ করতে পারেন (যেটি একীকরণ পরীক্ষায় উত্তীর্ণ হয় তা নয়), সারারাত চালিয়ে প্রথম জিনিসটির প্রতিবেদন হিসাবে সারারাত চালানোর জন্য tests


3
এখানে যুক্ত করার একটি ভাল অনুশীলন হ'ল বৈশিষ্ট্য শাখাগুলি মূল পরীক্ষায় মার্জ হওয়ার আগে সমস্ত পরীক্ষায় উত্তীর্ণ হওয়া উচিত
বার্ট ভ্যান ইনজেন শেহানাউ

@ বার্টওয়ানআইগেনসেনাউ - ভাল পয়েন্ট যুক্ত হয়েছে!
স্টিভ বার্নেস

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

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

8

স্ক্রামের সাথে কিছু করার নেই। আপনার বিল্ড নির্বিশেষে অবিচ্ছিন্ন স্থিতিশীল হওয়া উচিত।

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

যে কোনও ব্যক্তি বিল্ডটি ব্যর্থ হওয়ার কারণ বা ইউনিট পরীক্ষা ব্যর্থ হওয়ার কারণ হিসাবে পরিচয় করিয়ে দেয় তাকে প্রকাশ্যে লজ্জা দেওয়া উচিত । যদি বিল্ডটি ভেঙে যায় তবে তা অবিলম্বে ঠিক করতে হবে।


2
একদিকে, জোর দেওয়া উচিত যে স্থিতিশীলতা তৈরি করা সবার দায়িত্ব responsibility অন্যদিকে, আমি জনসাধারণের লজ্জার বিরুদ্ধে পরামর্শ দিচ্ছি, কারণ (১) আরও অভিজ্ঞ দলের সদস্যদের জুনিয়র সদস্যদের স্থায়িত্ব অর্জনে সহায়তা করার ক্ষেত্রে বড় দায়িত্ব রয়েছে (কোড পর্যালোচনা, জোড় প্রোগ্রামিং, বা কমিটমেন্টের আগে কেবল একত্রে কাজ করার মাধ্যমে, বা দ্বারা একসাথে একটি ভাঙ্গা বিল্ড ঠিক করা), (২) লজ্জা দলের টিমের মানসিক সুরক্ষা কেড়ে নেয় ।
রওয়ং

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

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

6

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

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

সুতরাং, বেশ কয়েক ঘন্টা 10-30 মিনিটে পরিণত হবে।

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

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

আমি স্ক্রাম এবং আপনার সমস্যার মধ্যে কোনও সংযোগ দেখতে পাচ্ছি না। সমস্যাগুলি যে কোনও উন্নয়ন প্রক্রিয়া নিয়েই ঘটতে পারে।


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

কিছু পরীক্ষা সমান্তরাল রানের সাথে দ্বন্দ্ব করতে পারে
ডিফ্রিটাস

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

2

আরও জেনকিনের ইনস্টলেশন এবং বিকাশকারীদের আলাদা জেনকিন্সের উদাহরণে পরীক্ষা করা কি সম্ভব নয়?

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

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


1

পয়েন্ট (2) সবচেয়ে বেদনাদায়ক বিন্দু বলে মনে হচ্ছে, তাই আমি এটিতে ফোকাস করব।

প্রকল্পটি একাধিক মডিউলে বিভক্ত করার সময় হতে পারে।

https://en.wikipedia.org/wiki/Dependency_inversion_principle

উ: উচ্চ-স্তরের মডিউলগুলি নিম্ন-স্তরের মডিউলগুলির উপর নির্ভর করবে না। উভয়ের বিমূর্ততা উপর নির্ভর করা উচিত।

খ। বিমূর্ততা বিশদ উপর নির্ভর করবে না। বিবরণ বিমূর্ততা উপর নির্ভর করা উচিত।

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

এটি আপনাকে অন্যান্য বিল্ড ব্যর্থতাগুলি কী হতে পারে সে সম্পর্কে প্রতিক্রিয়া জানাবে, যাতে আপনার পরবর্তী বিল্ডটি ঘটে যাওয়ার আগে একাধিক ভাঙ্গা মডিউল ঠিক করার সময় থাকে।

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


পার্শ্ব নোট হিসাবে (জুস্টের উত্তর দেখুন), আপনি যদি বিল্ডটিকে পৃথক মডিউলে বিভক্ত না করেন তবে আপনি বিল্ডটি দ্রুত রান করতে পারবেন না (সমান্তরালভাবে)।


0

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

  • কোড ইউনিট পরীক্ষা আছে
  • একটি স্বয়ংক্রিয় বিল্ডের অংশ হিসাবে ইউনিট পরীক্ষা পাস
  • কোডটি মূলতে একীভূত করা হয়েছে (এবং বিরোধগুলি সমাধান করা হয়েছে)
  • প্রভৃতি

সুতরাং, মূলত, কি ঘটছে আপনার দলের উপলক্ষে কাপড় সম্পন্ন করা হয় যে আসলে হয় না না সম্পন্ন। এটি নিজেই একটি সমস্যা।

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

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

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