সোর্স কোড নিয়ন্ত্রণে আপনার প্রকল্পের কোন অংশটি হওয়া উচিত?


54

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

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

এটি বলেছিল, আমি এ সম্পর্কে অন্যান্য মতামত পেতে পছন্দ করব। সবকিছু নিয়ন্ত্রণে না রাখার জন্য কি কোনও যুক্তি রয়েছে?


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

উত্তর:


71

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


1
@ এডউডকক: আপনি ঠিক বলেছেন, অর্ডার সঠিক হওয়া একটি সত্যিকারের ব্যথা হতে পারে তবে কখনও কখনও আপনি ডাটাবেসের একটি নির্দিষ্ট অবস্থা পুনরায় তৈরি করতে চান বা পুরো বিষয়টিকে ড্রপ / পুনরায় তৈরি করার পরিবর্তে পরীক্ষার সময় কিছু পরিবর্তন করতে পারেন। আমি এটি প্রকল্পের দ্বারা পরিবর্তিত দেখতে পাই।
হতাশিত

1
পয়েন্ট নেওয়া, এটির জন্য একটি স্তর বা বাস্তববাদ প্রয়োজন।
এড জেমস

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

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

1
@ মাইকে আমি এটা বোঝাতে চাইছি আমি মনে করি এটি এক্সপি সম্পর্কে একটি বইতে কেন্ট বেক ছিলেন যিনি আসলে এটি প্রস্তাব করেছিলেন। এমন খারাপ ধারণা নয়। আপনি সমস্ত বিল্ড ফ্যাক্টরগুলি পুনর্গঠন করতে সক্ষম হতে প্রায় 100% নিশ্চিত। এবং প্রকল্পের চলাকালীন পরিবেশগুলি সম্ভবত সম্ভবত পরিবর্তিত হবে তা ভুলে যাবেন না।
শিল্পীেক্স

29

সূর্যের নীচে প্রায় সবকিছুই উত্স নিয়ন্ত্রণে রাখা ভাল।

  • কোড

  • লাইব্রেরি

  • সম্পদ

  • স্ক্রিপ্টগুলি তৈরি / স্থাপন করুন

  • ডাটাবেস তৈরি এবং আপডেট স্ক্রিপ্ট

  • কিছু ডকুমেন্টেশন

  • পরিবেশ নির্দিষ্ট কনফিগারেশন ফাইল

উত্স নিয়ন্ত্রণে রাখা উচিত নয় যে একমাত্র জিনিস হ'ল আপনার প্রকল্পের জন্য নিদর্শনগুলি।


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

2
@ ব্রুসইডিগার সেক্ষেত্রে আমি ব্যক্তিগতভাবে আউটপুট এবং সরঞ্জাম দুটি নির্দিষ্ট তথ্য চাই। যদি সরঞ্জামটি অদৃশ্য হয়ে যায়, আপনার কমপক্ষে এখনও একটি স্ট্যাটিক বৈদ্যুতিন অনুলিপি রাখবেন :)
ম্যাপেল_শ্যাফ্ট

একটি বড় প্রক্রিয়া সংস্থার এখানে সুবিধাগুলির মধ্যে একটি, উত্সটি ভিসিএসে চলে যায়, উত্পন্ন জিনিসগুলি কনফিগারেশন ম্যানেজমেন্ট সিস্টেমে যেতে হয়, সুতরাং আপনার সরঞ্জামটি ক্ষুব্ধ হয়ে গেলেও আপনার ফলাফলগুলি নিয়ন্ত্রিত থাকে
জে.কে.

আপনি যে সংকলকটি ব্যবহার করছেন তার নির্দিষ্ট সংস্করণটি সম্পর্কে কীভাবে? মুরগি, কেন পুরো ওএস নয়?
23

18

আমি বলতে চাই যে;

  • বিল্ড সম্পাদন করার জন্য প্রয়োজনীয় যে কোনও ফাইল সংস্করণ নিয়ন্ত্রণে চলে
  • বিল্ড দ্বারা উত্পাদিত কোনও ফাইল (যা হতে পারে) তা করে না

আমি ট্রাঙ্কের বাইরে কোথাও সরঞ্জাম ইনস্টল প্যাকেজগুলির মতো বড় বাইনারি রাখার ঝোঁক রাখব তবে সেগুলি এখনও সংস্করণ নিয়ন্ত্রণে থাকা উচিত।


15

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


15

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

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

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

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

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

আপনার সমস্ত বিল্ড স্ক্রিপ্টগুলি সোর্স নিয়ন্ত্রণে অন্তর্ভুক্ত। সবকিছু! সমস্ত উপায় নীচে পরিবেশের ভেরিয়েবল। আপনার বিল্ড মেশিনটি প্রকল্পের মূলটিতে একটি স্ক্রিপ্ট সম্পাদন করে আপনার যে কোনও প্রকল্পের একটি বিল্ড চালাতে সক্ষম হওয়া উচিত। ( ./buildএকটি যুক্তিসঙ্গত মান; ./configure; makeপ্রায় তত ভাল)) স্ক্রিপ্টটির প্রয়োজনমতো পরিবেশ সেট আপ করা উচিত এবং তারপরে যেকোন সরঞ্জাম পণ্য তৈরি করে (মেক, পিঁপড়া ইত্যাদি) চালু করে।

আপনি যদি মনে করেন এটি খুব বেশি কাজ, তবে তা নয়। এটি আসলে এক টন কাজ বাঁচায়। সময়ের শুরুতে আপনি একবারে ফাইলগুলি প্রতিশ্রুতিবদ্ধ করেন এবং তারপরে আপনি যখনই আপগ্রেড করেন। কোনও একাকী নেকড়ে তার নিজস্ব মেশিন আপগ্রেড করতে পারে না এবং উত্স কোডের একগুচ্ছ প্রতিশ্রুতিবদ্ধ করতে পারে যা অন্য কারও জন্য বিল্ড ভেঙে কিছু সরঞ্জামের সর্বশেষতম সংস্করণে নির্ভর করে। আপনি যখন নতুন বিকাশকারী নিয়োগ করেন, আপনি তাদের প্রকল্পটি পরীক্ষা করে চালানোর জন্য বলতে পারেন ./build। সংস্করণ ১.৮-তে প্রচুর পারফরম্যান্স টিউনিং থাকে এবং আপনি কোড, সংকলক পতাকা এবং পরিবেশের ভেরিয়েবলগুলি টুইট করেন, আপনি নিশ্চিত করতে চান যে নতুন সংকলক পতাকাগুলি দুর্ঘটনাক্রমে সংস্করণ 1.7 প্যাচ বিল্ডগুলিতে প্রয়োগ না হয়, কারণ তাদের সত্যিকারের কোড দরকার পরিবর্তনগুলি যা তাদের সাথে যায় বা আপনি কিছু লোমশ বর্ণের পরিস্থিতি দেখতে পান।

সর্বোপরি , এটি আপনার পাছা কোনও দিন বাঁচাতে পারে: কল্পনা করুন যে আপনি সোমবারে আপনার পণ্যের 3.0.০.২ সংস্করণটি পাঠিয়েছেন। হুররে, উদযাপন করুন। মঙ্গলবার সকালে, একজন ভিআইপি গ্রাহক সমর্থন হটলাইনে কল করেন, আপনি 18 মাস আগে প্রেরণ করেছেন এমন সংস্করণ ২.২..6-তে এই সুপারক্রিটিক্যাল, জরুরি বাগ সম্পর্কে অভিযোগ করে ining এবং আপনাকে এখনও চুক্তিবদ্ধভাবে এটিকে সমর্থন করতে হবে এবং আপনি নতুন কোডে বাগটি স্থির করে দিয়েছেন তা নিশ্চিত না করা পর্যন্ত তারা আপগ্রেড করতে অস্বীকার করেছে এবং এগুলি আপনাকে নাচিয়ে তুলতে যথেষ্ট বড়। দুটি সমান্তরাল মহাবিশ্ব রয়েছে:

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

  • মহাবিশ্বে যেখানে সমস্ত কিছু সোর্স নিয়ন্ত্রণে থাকে, আপনি ২.২. check ট্যাগটি পরীক্ষা করে দেখুন, এক ঘন্টা বা তার মধ্যে একটি ডিবাগ বিল্ড প্রস্তুত রেখেছেন, "ভিআইপি বাগ" পুনরুদ্ধার করতে এক-দু'দিন ব্যয় করুন, কারণটি সন্ধান করুন, এটি ঠিক করুন বর্তমান প্রকাশ, এবং গ্রাহককে আপগ্রেড করতে রাজি করুন। স্ট্রেসফুল, তবে আপনার হেয়ারলাইন 3 সেন্টিমিটার বেশি যেখানে অন্য মহাবিশ্বের মতো ততটা খারাপ নয়।

যা বলেছিল, আপনি এটি খুব বেশি দূরে নিতে পারেন:

  • আপনার একটি স্ট্যান্ডার্ড ওএস ইনস্টল করা উচিত যা আপনার একটি "সোনার অনুলিপি" রয়েছে। এটা দস্তাবেজ, সম্ভবত একটি README যে হয় উৎস নিয়ন্ত্রণ, তাই ভবিষ্যত প্রজন্মের যে সংস্করণ 2.2.6 জানেন এবং তার আগে শুধুমাত্র RHEL 5.3 এবং 2.3.0 নির্মিত এবং পরে শুধুমাত্র উবুন্টু 11.04 নির্মিত হয়। যদি আপনার পক্ষে এইভাবে সরঞ্জামচেন পরিচালনা করা সহজ হয় তবে এটির জন্য যান, কেবল নিশ্চিত হন যে এটি একটি নির্ভরযোগ্য সিস্টেম।
  • উত্স নিয়ন্ত্রণ সিস্টেমে প্রকল্পের ডকুমেন্টেশনগুলি বজায় রাখা জটিল। প্রজেক্ট ডকস সর্বদা কোডের আগে থাকে এবং বর্তমান সংস্করণের কোডে কাজ করার সময় পরবর্তী সংস্করণে ডকুমেন্টেশনে কাজ করা অস্বাভাবিক কিছু নয়। বিশেষত যদি আপনার সমস্ত প্রকল্পের ডক্স বাইনারি ডক্স হয় যা আপনি পৃথক বা মার্জ করতে পারবেন না।
  • আপনার যদি এমন সিস্টেম থাকে যা বিল্ডে ব্যবহৃত সমস্ত কিছুর সংস্করণগুলি নিয়ন্ত্রণ করে, এটি ব্যবহার করুন ! কেবলমাত্র নিশ্চিত হয়ে নিন যে পুরো টিম জুড়ে সিঙ্ক করা সহজ, যাতে প্রত্যেকে (বিল্ড মেশিন সহ) একই সরঞ্জামের সেট থেকে টানছেন। (আমি ডেবিয়ানের পিউবিল্ডার এবং পাইথনের ভার্চুয়ালেনভের দায়িত্বশীল ব্যবহারের মতো সিস্টেমগুলির কথা ভাবছি))

কোনও হার্ড-টু-প্রতিস্থাপন হার্ডওয়্যার চেক করতে ভুলবেন না। একটি সংস্থা একটি বিল্ড হারিয়েছে কারণ তাদের আর কিছু সিপিইউ (এইচপিপিএ? 68040?) না থাকায় বিল্ড সরঞ্জামগুলি চলছে।
হটপাউ 2

1
"সিএম সিস্টেম" কী বোঝায়?
বোডো

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

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

13

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


7

উত্স নিয়ন্ত্রণের জন্য ব্যবহারের কেসটি হ'ল: যদি আমাদের সমস্ত বিকাশকারী মেশিন এবং আমাদের সমস্ত স্থাপনার মেশিন একটি উল্কাপ্রাপ্ত হয়ে পড়ে? আপনি পুনরুদ্ধারটি চেকআউট এবং যতটা সম্ভব বিল্ডিংয়ের নিকটবর্তী হতে চান। (যদি এটি খুব নির্বোধ হয় তবে আপনি "নতুন বিকাশকারীকে ভাড়া করুন" নিয়ে যেতে পারেন)

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

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


1
এর অর্থ হ'ল একাধিক মেশিন থেকে কাজ করা বেদাহীন। কেবল রেপো টানুন, এবং আপনি যেতে প্রস্তুত।
স্পেন্সার রথবুন

উল্কা রেফারেন্সের জন্য +1, যা জিনিসগুলি সুন্দরভাবে উপস্থাপন করে।
মফিনিস্তা

কেউ কি (উদাহরণস্বরূপ) রেভা নিয়ন্ত্রণের অধীনে পুরো টুলচেন সহ একটি জাভা প্রকল্পের উদাহরণের দিকে ইঙ্গিত করতে পারে যে এটি চেক আউট এবং সোজা উপায়ে ব্যবহার করা যেতে পারে?
andersoj

@andersoj পরীক্ষা করে দেখুন boxen.github.com
ল্যারি OBrien

6

প্রকল্পে অবদান রাখে এমন কিছু এবং যার জন্য আপনি পরিবর্তনগুলি ট্র্যাক করতে চান।

ব্যতিক্রমগুলিতে চিত্রগুলির মতো বৃহত বাইনারি ব্লব অন্তর্ভুক্ত থাকতে পারে, যদি আপনি কোনও স্ক্যাম ব্যবহার করেন যা বাইনারি ডেটা খুব ভালভাবে পরিচালনা করে না।


2

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


1

সবকিছু বাদ দিয়ে উত্স নিয়ন্ত্রণে থাকা উচিত:

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

এটির মতো চিন্তা করুন: দলে প্রতিটি নতুন সদস্যের প্রকল্পের একটি কার্যকরী অনুলিপি (মাইনাস কনফিগারেশন আইটেম) চেকআউট করতে সক্ষম হওয়া উচিত।

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


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

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


3
-1 উত্স নিয়ন্ত্রণে নয় এমন কনফিগারেশন ফাইলগুলি সম্পর্কে আপনার বক্তব্যটির সাথে অত্যন্ত অনাদৃত। সম্ভবত বিকাশকারী সুনির্দিষ্ট কনফিগারেশন ফাইলগুলি হ্যাঁ, তবে আপনি যদি পরিবেশের এক-পদক্ষেপের জন্য দক্ষতা চান এবং কোনও পরিবেশ স্থাপন করতে চান তবে পরিবেশ নির্দিষ্ট কনফিগারেশন ফাইলগুলি প্রয়োজনীয়।
ম্যাপেল_শ্যাফ্ট

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

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

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

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

1

আপনার অটোমেটেড বিল্ড যা কিছু উত্পন্ন করে তা উত্স নিয়ন্ত্রণে যায় না। কিছু যে প্রয়োজন কোন বিল্ড সময় পরিবর্তন করে উৎস নিয়ন্ত্রণ যান। এটা খুব সহজ।

উদাহরণস্বরূপ, নিম্নলিখিতগুলি উত্স নিয়ন্ত্রণে যায় না:

  • উত্পন্ন কোড
  • উত্পাদিত বাইনারি
  • আপনার বিল্ড দ্বারা তৈরি কিছু
  • আপনার সার্ভিস, প্রক্রিয়া, ওয়েব অ্যাপ্লিকেশন দ্বারা রানটাইম সময়ে তৈরি করা কিছু

উত্স নিয়ন্ত্রণে কি যায়:

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

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


1

আপনার যে কাজ করতে হবে এবং যে কোনও কিছু পরিবর্তন করতে পারে তার কোনও না কোনওভাবে সংস্করণ করা দরকার। তবে দু'টি স্বতন্ত্র সিস্টেম এটির খোঁজ রাখার প্রয়োজন খুব কমই আছে।

নির্ভরযোগ্য উপায়ে উত্পন্ন যে কোনও জিনিস সাধারণত উত্স সংস্করণে সংযুক্ত করা যায় - সুতরাং এটি স্বাধীনভাবে ট্র্যাক করার দরকার নেই: উত্পন্ন উত্স, বাইনারিগুলি যা কোনও সিস্টেম থেকে অন্যটিতে যায় না, ইত্যাদি etc.

লগ এবং অন্যান্য স্টাফ তৈরি করুন যা সম্ভবত কেউই পাত্তা দেয় না (তবে আপনি কখনই নিশ্চিত হয়ে জানেন না) সাধারণত যে কেউ এটি তৈরি করছে তার দ্বারা সবচেয়ে ভাল ট্র্যাক হয়: জেনকিনস ইত্যাদি etc.

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

যা কিছু অবশিষ্ট রয়েছে (এবং এই মুহুর্তে উত্স ফাইল এবং বিল্ড সার্ভার কনফিগারেশনের চেয়ে কিছু বেশি হওয়া উচিত) উত্স নিয়ন্ত্রণে চলে যায়।


0

আমার উত্তরটি বেশ সহজ: বাইনারি নয়। জড়িত দ্বারা, প্রায় সব কিছু।

(অবশ্যই ডেটাবেস ব্যাকআপ বা স্কিমা মাইগ্রেশন বা ব্যবহারকারী-ডেটা নয়))


স্কিমা স্থানান্তরগুলি একেবারে উত্স নিয়ন্ত্রণে চলে। এইভাবে আপনি জানেন ডিবি স্কিমা কোডটি কী প্রত্যাশা করে।
মার্নেন লাইবো-কোসার

0

উত্স নিয়ন্ত্রণ একটি পরিবর্তন ট্র্যাকিং প্রক্রিয়া is কখন এবং কখন কী পরিবর্তন হয়েছে তা জানতে চাইলে এটি ব্যবহার করুন।

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

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

উত্স নিয়ন্ত্রণ যাদু নয়। এটি চেষ্টা করে দেখুন, তবে যদি এটি ব্যয়টি অফসেট করার জন্য পর্যাপ্ত মান যোগ না করে তবে এটিকে ত্যাগ করুন।


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

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

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

0

স্টাফ আমি উত্স নিয়ন্ত্রণে রাখি না:

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

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


0

নীচের বইটি যা আপনার উদ্বেগের জন্য আমি আপনাকে উত্সাহিত করছি:

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

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

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


-1

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

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