DevOps - VTB অভিজ্ঞতা ব্যবহার করে কীভাবে একটি পূর্ণাঙ্গ ইনহাউস ডেভেলপমেন্ট তৈরি করা যায়

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

 

প্রস্তাবনা: DevOps একটি দর্শন

গত এক বছরে, আমরা VTB-তে DevOps অনুশীলনের অভ্যন্তরীণ উন্নয়ন এবং বাস্তবায়ন সংগঠিত করার জন্য অনেক কাজ করেছি:

• আমরা 12টি সিস্টেমের জন্য অভ্যন্তরীণ উন্নয়ন প্রক্রিয়া তৈরি করেছি;
• আমরা 15টি পাইপলাইন চালু করেছি, যার মধ্যে চারটি উৎপাদনে আনা হয়েছে;
• স্বয়ংক্রিয় 1445 পরীক্ষার পরিস্থিতি;
• আমরা ইন-হাউস টিম দ্বারা প্রস্তুতকৃত বেশ কয়েকটি রিলিজ সফলভাবে বাস্তবায়ন করেছি।

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

প্রথমে, বাস্তবায়ন অ্যালগরিদম সহজ এবং পরিষ্কার বলে মনে হয়েছিল:

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

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

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

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

অভ্যন্তরীণ উন্নয়ন কোথায় শুরু হয়? 

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

• বহিরাগত ভাষা (MUMPS);
• কনসোল ইন্টারফেস;
• জনপ্রিয় অটোমেশন সরঞ্জাম এবং কাঠামোর সাথে একীকরণের অভাব;
• দশ টেরাবাইটে ডেটা ভলিউম;
• প্রতি ঘন্টায় 2 মিলিয়নেরও বেশি অপারেশনের লোড;
• তাৎপর্য - ব্যবসা-সমালোচনামূলক।

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

• কোড তৈরির ডকুমেন্টেশন এবং মৌলিক বিষয়গুলি অধ্যয়ন করেছেন;
• আমরা বিক্রেতার কাছ থেকে প্রাপ্ত উন্নয়নের সংক্ষিপ্ত কোর্সটি অধ্যয়ন করেছি;
• প্রাথমিক উন্নয়ন দক্ষতা আয়ত্ত করা;
• আমরা নতুন দলের সদস্যদের জন্য একটি প্রশিক্ষণ ম্যানুয়াল সংকলন করেছি;
• আমরা দলটিকে "যুদ্ধ" মোডে অন্তর্ভুক্ত করতে রাজি হয়েছি;
• কোড মান নিয়ন্ত্রণের সাথে সমস্যাটি সমাধান করেছে;
• আমরা উন্নয়নের জন্য একটি অবস্থান সংগঠিত করেছি।

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

সংগ্রহস্থল স্থানান্তর এবং অটোটেস্ট

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

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

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

এটি কেমন ছিল: অটোমেশনের আগে মডেল

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

সমাবেশ স্বতন্ত্র প্রসবের পর্যায়ে বাহিত হয়েছিল, যা ছিল স্বাধীন বস্তু। কোন পরিবর্তন একটি নতুন বিতরণ. অন্যান্য জিনিসের মধ্যে, 60-70টি প্রযুক্তিগত সংস্করণ 10-15 টি প্যাকেজে যুক্ত করা হয়েছে মূল রিলিজ কম্পোজিশন - রিলিজ থেকে কিছু যোগ বা বাদ দেওয়ার সময় প্রাপ্ত সংস্করণ এবং রিলিজের বাইরে বিক্রির পরিবর্তনগুলি প্রতিফলিত করে।

ডেলিভারির মধ্যে থাকা বস্তুগুলি একে অপরের সাথে ওভারল্যাপ করে, বিশেষ করে এক্সিকিউটেবল কোডে, যা অর্ধেকেরও কম অনন্য ছিল। ইতিমধ্যে ইন্সটল করা কোড এবং যার ইন্সটলেশন সবেমাত্র পরিকল্পিত ছিল তার উপর অনেক নির্ভরতা ছিল। 

কোডের প্রয়োজনীয় সংস্করণটি পেতে, ইনস্টলেশনের আদেশটি কঠোরভাবে অনুসরণ করা প্রয়োজন ছিল, এই সময় বস্তুগুলিকে শারীরিকভাবে অনেকবার, প্রায় 10-12 বার পুনঃলিখন করা হয়েছিল।

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

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

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

প্রথম আপডেট: সমাবেশ এবং বিতরণ কমিট

এই রুট বরাবর একটি পাইপের মাধ্যমে কোড প্রেরণের মাধ্যমে অটোমেশন শুরু হয়েছে:

• স্টোরেজ থেকে সমাপ্ত ডেলিভারি পিক আপ;
• এটি একটি উত্সর্গীকৃত পরিবেশে ইনস্টল করুন;
• অটোটেস্ট চালান;
• ইনস্টলেশন ফলাফল মূল্যায়ন;
• টেস্টিং কমান্ডের পাশে নিম্নলিখিত পাইপলাইনটি কল করুন।

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

• প্রতিটি পরিবর্তন একটি পৃথক শাখায় সঞ্চালিত হয়, যা ইনস্টলেশন প্যাকেজের সাথে মিলে যায় এবং লক্ষ্য মাস্টার শাখায় একত্রিত হয়;
• পাইপলাইন লঞ্চ ট্রিগার হল একটি মার্জ রিকোয়েস্টের মাধ্যমে মাস্টার ব্রাঞ্চে একটি নতুন কমিটের উপস্থিতি, যা ইনহাউস টিমের রক্ষণাবেক্ষণকারীরা বন্ধ করে দেয়;
• সংগ্রহস্থলগুলি প্রতি পাঁচ মিনিটে একবার সিঙ্ক্রোনাইজ করা হয়;
• ইনস্টলেশন প্যাকেজের সমাবেশ শুরু হয় - বিক্রেতার কাছ থেকে প্রাপ্ত অ্যাসেম্বলার ব্যবহার করে।

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

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

চূড়ান্ত সমাধান: ক্রমবর্ধমান ইনস্টলেশন প্যাকেজ 

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

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

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

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

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

একটি অতিরিক্ত চ্যালেঞ্জ ছিল বিপুল সংখ্যক নন-রিলিজ যা বিবেচনায় নিতে হয়েছিল। কিন্তু প্রোড-এর মতো শাখা এবং রিবেসের সাথে, কাজটি স্বচ্ছ হয়ে ওঠে।

প্রথমবার, দ্রুত এবং ত্রুটি ছাড়াই

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

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

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

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

ফলাফল এবং সিদ্ধান্তে

এক বছরেরও কম সময়ে আমরা পরিচালনা করেছি:

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

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

উত্স: www.habr.com