কোর্স ছাত্রদের জন্য প্রস্তুত নিবন্ধের অনুবাদ "DevOps অনুশীলন এবং সরঞ্জাম" OTUS শিক্ষামূলক প্রকল্পে।

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

কেন আমরা এই সম্পর্কে কথা বলছি?

ম্যাট ক্লেইন নিবন্ধটি লিখেছেন "মনোরেপোস: দয়া করে করবেন না!"  (অনুবাদকের দ্রষ্টব্য: Habré-এ অনুবাদ "মনোরপোজিটরি: দয়া করে করবেন না") আমি ম্যাটকে পছন্দ করি, আমি মনে করি সে খুব স্মার্ট এবং আপনার তার দৃষ্টিভঙ্গি পড়া উচিত। তিনি মূলত টুইটারে পোল পোস্ট করেছেন:

অনুবাদ:
এই নববর্ষের দিন, আমি কতটা হাস্যকর মনোরপোজিটরি নিয়ে তর্ক করতে যাচ্ছি। 2019 নিঃশব্দে শুরু হয়েছিল। এই চেতনায়, আমি আপনাকে একটি জরিপ প্রস্তাব. বড় ধর্মান্ধ কারা? সমর্থক:
- মনোরেপো
- জং
- ভুল পোল / উভয়

আমার প্রতিক্রিয়া ছিল, "আমি আক্ষরিক অর্থে সেই লোক উভয়ই।" কিভাবে মরিচা একটি ড্রাগ সম্পর্কে কথা বলার পরিবর্তে, কেন আমি মনে করি তিনি monorepositories সম্পর্কে ভুল তা দেখুন. নিজের সম্পর্কে একটু। আমি শেফ সফটওয়্যারের CTO। আমাদের প্রায় 100 জন প্রকৌশলী রয়েছে, একটি কোড বেস প্রায় 11-12 বছর আগের, এবং 4টি প্রধান পণ্য। এই কোডের কিছু একটি পলিরিপোজিটরিতে (আমার শুরুর অবস্থান), কিছু একটি মনোরপোজিটরিতে (আমার বর্তমান অবস্থান)।

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

আমি ম্যাটের পয়েন্টের প্রথম অংশের সাথে একমত:

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

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

আমি মনে করি ম্যাটের যুক্তিটি অনেক প্রকৌশলী (এবং পরিচালকদের) দ্বারা ভাগ করা মতামতের মতো যা আমি সম্মান করি। এটি কম্পোনেন্টে কাজ করা প্রকৌশলীর দৃষ্টিকোণ থেকে বা কম্পোনেন্টে কাজ করা দল থেকে ঘটে। আপনি এই ধরনের জিনিস শুনতে:

• কোডবেসটি ভারী - আমার এই সমস্ত আবর্জনার দরকার নেই।
• এটি পরীক্ষা করা কঠিন কারণ আমাকে এই সমস্ত আবর্জনা পরীক্ষা করতে হবে যা আমার প্রয়োজন নেই।
• বাহ্যিক নির্ভরতা নিয়ে কাজ করা আরও কঠিন।
• আমার নিজের ভার্চুয়াল সংস্করণ নিয়ন্ত্রণ সিস্টেম দরকার।

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

এটি যোগাযোগকে উস্কে দেয় এবং সমস্যা দেখায়

যখন আমরা সংগ্রহস্থলগুলি পৃথক করি, তখন আমরা সমন্বয় এবং স্বচ্ছতার একটি বাস্তব সমস্যা তৈরি করি। এটি আমরা যেভাবে টিম সম্পর্কে চিন্তা করি তার সাথে মিলে যায় (বিশেষ করে যেভাবে পৃথক সদস্যরা তাদের সম্পর্কে চিন্তা করে): আমরা একটি নির্দিষ্ট উপাদানের জন্য দায়ী। আমরা আপেক্ষিক বিচ্ছিন্নভাবে কাজ করি। সীমানা আমার দল এবং আমরা কাজ করছি উপাদান(গুলি) উপর স্থির করা হয়.

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

• পুরানো API ব্যবহার করা হয় যেখানে সব জায়গা খুঁজুন.
• এমন জায়গা আছে যেখানে নতুন API ব্যবহার করা যাবে না?
• আপনি কি ঠিক করতে পারেন এবং অন্যান্য উপাদানগুলি ভেঙে না তা নিশ্চিত করতে পরীক্ষা করতে পারেন?
• এই দলগুলি কি এখনই আপনার পরিবর্তনগুলি পরীক্ষা করতে পারে?

অনুগ্রহ করে মনে রাখবেন যে এই প্রশ্নগুলি সংগ্রহস্থলের প্রকারের থেকে স্বাধীন। আপনাকে B, C এবং D টিম খুঁজে বের করতে হবে। আপনাকে তাদের সাথে কথা বলতে হবে, সময় বের করতে হবে, তাদের অগ্রাধিকার বুঝতে হবে। অন্তত আমরা আশা করি আপনি করবেন।

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

একটি মনোরপোজিটরিতে, দায়িত্ব ডিফল্টরূপে স্থানান্তরিত হয়। টিম A তাদের উপাদান পরিবর্তন করে এবং সতর্ক না হলে অবিলম্বে B, C এবং D ভেঙ্গে ফেলে। এর ফলে B, C এবং D A এর দরজায় উপস্থিত হয়, আশ্চর্য হয়ে যায় যে টিম A কেন সমাবেশ ভেঙ্গেছে। এটি A কে শেখায় যে তারা উপরের আমার তালিকাটি এড়িয়ে যেতে পারে না। তারা কি করতে যাচ্ছেন তা নিয়ে কথা বলতে হবে। B, C এবং D কি নড়াচড়া করতে পারে? যদি B এবং C পারে তবে D পুরানো অ্যালগরিদমের আচরণের একটি পার্শ্ব প্রতিক্রিয়ার সাথে ঘনিষ্ঠভাবে সম্পর্কিত ছিল?

তারপরে আমরা কীভাবে এই পরিস্থিতি থেকে বেরিয়ে আসব সে সম্পর্কে আমাদের কথা বলতে হবে:

1. একাধিক অভ্যন্তরীণ API-এর জন্য সমর্থন, এবং D এর ব্যবহার বন্ধ না করা পর্যন্ত পুরানো অ্যালগরিদমকে অবমূল্যায়িত হিসাবে চিহ্নিত করবে।
2. একাধিক রিলিজ সংস্করণের জন্য সমর্থন, একটি পুরানো ইন্টারফেসের সাথে, একটি নতুনের সাথে।
3. A এর পরিবর্তনগুলি প্রকাশ করতে বিলম্ব করুন যতক্ষণ না B, C এবং D একই সাথে এটি গ্রহণ করতে পারে।

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

একাধিক সংস্করণ প্রকাশ করতে, আমাদের একটি শাখা প্রয়োজন। এখন আমাদের দুটি উপাদান রয়েছে - A1 এবং A2। দল B এবং C A2 ব্যবহার করে এবং D A1 ব্যবহার করে। আমাদের প্রতিটি উপাদানকে মুক্তির জন্য প্রস্তুত থাকতে হবে কারণ ডি এগিয়ে যাওয়ার আগে নিরাপত্তা আপডেট এবং অন্যান্য বাগ সংশোধনের প্রয়োজন হতে পারে। একটি পলিরিপোজিটরিতে, আমরা এটিকে একটি দীর্ঘজীবী শাখায় লুকিয়ে রাখতে পারি যা ভাল বোধ করে। একটি মনোরপোজিটরিতে, আমরা কোডটিকে একটি নতুন মডিউলে তৈরি করতে বাধ্য করি। টিম ডি এখনও "পুরানো" উপাদান পরিবর্তন করতে হবে. আমরা এখানে যে খরচ দিচ্ছি তা সবাই দেখতে পাবে - আমাদের কাছে এখন দ্বিগুণ কোড রয়েছে এবং A1 এবং A2 এ প্রযোজ্য যেকোন বাগ ফিক্স অবশ্যই তাদের উভয়ের জন্যই প্রযোজ্য হবে। একটি polyrepository মধ্যে শাখা পদ্ধতির সঙ্গে, এটি চেরি-পিক পিছনে লুকানো হয়. আমরা খরচ কম বলে মনে করি কারণ কোন সদৃশতা নেই। একটি ব্যবহারিক দৃষ্টিকোণ থেকে, খরচ একই: আপনি দুটি বহুলাংশে অভিন্ন কোডবেস তৈরি করবেন, প্রকাশ করবেন এবং বজায় রাখবেন যতক্ষণ না আপনি তাদের একটি মুছে ফেলতে পারেন। পার্থক্য হল যে একটি মনোরোপোজিটরির সাথে এই ব্যথা সরাসরি এবং দৃশ্যমান। এটি আরও খারাপ, এবং এটি ভাল।

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

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

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

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

শুধুমাত্র নিবন্ধিত ব্যবহারকারীরা জরিপে অংশগ্রহণ করতে পারবেন। সাইন ইন করুনকরুন।

সবচেয়ে বড় ধর্মান্ধ কারা? সমর্থক:

• মনোরেপো

• জং

• ভুল পোল / উভয়

33 জন ব্যবহারকারী ভোট দিয়েছেন। 13 জন ব্যবহারকারী বিরত ছিলেন।

উত্স: www.habr.com