বিকাশকারীদের জন্য সেরা DevOps অনুশীলন। অ্যান্টন বয়কো (2017)

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

আমাকে নিজের পরিচয় দিতে দিন, আমি পুরোপুরি স্বীকার করি যে রুমে এমন লোক রয়েছে যারা আমাকে চেনেন না। আমার নাম অ্যান্টন বয়কো, আমি একজন Microsoft Azure MVP। MVP কি? এটি মডেল-ভিউ-উপস্থাপক। মডেল-ভিউ-উপস্থাপক ঠিক আমি।

উপরন্তু, আমি বর্তমানে সিকলুমে সমাধান আর্কিটেক্টের পদে আছি। এবং সম্প্রতি আমি নিজেকে এমন একটি সুন্দর ডোমেন কিনেছি এবং আমি আমার ইমেল আপডেট করেছি, যা আমি সাধারণত উপস্থাপনায় দেখাই। আপনি আমাকে এখানে লিখতে পারেন: me [dog] byokoant.pro. আপনি প্রশ্ন সহ আমাকে ইমেল করতে পারেন. আমি সাধারণত তাদের উত্তর করি। একমাত্র জিনিস হল যে আমি ইমেলের মাধ্যমে প্রশ্নগুলি পেতে চাই না যা দুটি বিষয় সম্পর্কিত: রাজনীতি এবং ধর্ম। আপনি ইমেল দ্বারা অন্য সবকিছু সম্পর্কে আমাকে লিখতে পারেন. কিছু সময় কেটে যাবে, আমি উত্তর দেব।

আমার সম্পর্কে কয়েকটি শব্দ:

• আমি এখন 10 বছর ধরে এই ক্ষেত্রে আছি।
• আমি মাইক্রোসফটে কাজ করতাম।
• আমি ইউক্রেনীয় Azure সম্প্রদায়ের প্রতিষ্ঠাতা পিতা, যা আমরা কোথাও 2014 সালে প্রতিষ্ঠা করেছি। এবং আমরা এখনও এটি আছে এবং এটি উন্নয়নশীল.
• আমি আজুর সম্মেলনের প্রতিষ্ঠাতার পিতাও, যা আমরা ইউক্রেনে হোস্ট করছি।
• আমি কিয়েভে গ্লোবাল অ্যাজুর বুটক্যাম্প সংগঠিত করতেও সাহায্য করি।
• আমি যেমন বলেছি, আমি একজন Microsoft Azure MVP।
• আমি প্রায়ই সম্মেলনে কথা বলি। আমি সত্যিই সম্মেলনে কথা বলতে ভালোবাসি. গত এক বছরে আমি প্রায় 40 বার পারফর্ম করতে পেরেছি। আপনি যদি ইউক্রেন, বেলারুশ, পোল্যান্ড, বুলগেরিয়া, সুইডেন, ডেনমার্ক, নেদারল্যান্ডস, স্পেনের পাশ দিয়ে যান বা ইউরোপের অন্য কোন দেশ দেন বা নিয়ে যান, তাহলে এটা খুবই সম্ভব যে আপনি যখন একটি সম্মেলনে যান যার স্রোতে একটি মেঘের থিম আছে, আপনি স্পিকার তালিকায় আমাকে দেখতে পারেন.
• আমিও একজন স্টার ট্রেক ভক্ত।

আসুন এজেন্ডা সম্পর্কে একটু কথা বলি। আমাদের এজেন্ডা খুবই সহজ:

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

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

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

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

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

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

মূলত, এই সব তার নিজস্ব উপায়ে সত্য. কিন্তু এগুলিই আমাদের চূড়ান্ত অভ্যাস। এই অনুশীলনগুলিতে যাওয়ার আগে, আমি এই স্লাইডটি দেখার পরামর্শ দিই, যা আপনার কোম্পানিতে, আপনার প্রকল্পে Dev-Ops পদ্ধতি বাস্তবায়নের 3টি ধাপ দেখায়।

এই স্লাইডটির একটি দ্বিতীয় অনানুষ্ঠানিক নামও রয়েছে৷ DevOps-এর 3 Musketeers কী তা জানতে আপনি অনলাইনে অনুসন্ধান করতে পারেন। এটা সম্ভব যে আপনি এই নিবন্ধটি পাবেন. কেন 3 Musketeers? নীচে এটি বলে: মানুষ, প্রক্রিয়া এবং পণ্য, যেমন পিপিপি - পোর্টোস, পোর্টোস এবং পোর্টোস। এখানে DevOps-এর 3 জন মাস্কেটিয়ার রয়েছে৷ এই নিবন্ধটি আরও বিশদে বর্ণনা করে কেন এটি গুরুত্বপূর্ণ এবং এটি কী অন্তর্ভুক্ত করে।

আপনি যখন একটি DevOps সংস্কৃতি প্রয়োগ করা শুরু করেন, তখন এটি অত্যন্ত গুরুত্বপূর্ণ যে এটি নিম্নলিখিত ক্রমে প্রয়োগ করা হয়।

প্রাথমিকভাবে আপনাকে মানুষের সাথে কথা বলতে হবে। এবং আপনাকে লোকেদের বোঝাতে হবে এটি কী এবং কীভাবে তারা এটি থেকে কিছু সুবিধা পেতে পারে।

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

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

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

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

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

এবং যখন আপনি লোকেদের ব্যাখ্যা করেন যে তারা একই সমস্যাগুলি সমাধান করার লক্ষ্যে, আপনি প্রক্রিয়াগুলিকে আনুষ্ঠানিক করার দিকে এগিয়ে যেতে পারেন। এটা খুবই গুরুত্বপূর্ণ. কেন? কারণ যখন আমরা বলি “আনুষ্ঠানিকীকরণ”, তখন আপনার জন্য ন্যাপকিনের অন্তত কোথাও আপনার প্রক্রিয়াগুলি কীভাবে ঘটে তা বর্ণনা করা গুরুত্বপূর্ণ। আপনাকে বুঝতে হবে যে আপনি যদি, উদাহরণস্বরূপ, একটি QA পরিবেশ বা একটি উত্পাদন পরিবেশে স্থাপন করেন, তবে এটি সর্বদা এই ক্রমে ঘটে; এই পর্যায়ে আমরা চালাই, উদাহরণস্বরূপ, স্বয়ংক্রিয় ইউনিট পরীক্ষা এবং UI পরীক্ষা। স্থাপনার পরে, আমরা মোতায়েনটি ভাল বা খারাপভাবে হয়েছে কিনা তা পরীক্ষা করি। কিন্তু আপনার কাছে ইতিমধ্যেই ক্রিয়াগুলির একটি সুস্পষ্ট তালিকা রয়েছে যা আপনি উত্পাদনে স্থাপন করার সময় বারবার পুনরাবৃত্তি করতে হবে।

এবং শুধুমাত্র যখন আপনার প্রক্রিয়াগুলি আনুষ্ঠানিক হয়ে যায়, আপনি কি এমন পণ্য নির্বাচন করতে শুরু করেন যা আপনাকে এই প্রক্রিয়াগুলিকে স্বয়ংক্রিয় করতে সহায়তা করবে।

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

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

সাধারণভাবে DevOps অনুশীলন সম্পর্কে কথা বলা যাক। তারা কি? পার্থক্য কি? কিভাবে তাদের চেষ্টা করতে? কেন তারা গুরুত্বপূর্ণ?

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

সবচেয়ে বড় সমস্যা হল প্রায়ই যখন আমি একজন ব্যক্তিকে জিজ্ঞাসা করি: "আপনার কি প্রকল্পে CI আছে?" এবং তিনি বলেন: "হ্যাঁ," তারপর যখন আমি জিজ্ঞাসা করি তিনি কী করেন, তিনি আমাকে সম্পূর্ণ অটোমেশন প্রক্রিয়া বর্ণনা করেন। এই সম্পূর্ণ সত্য নয়।

প্রকৃতপক্ষে, সিআই-এর অনুশীলনটি কেবলমাত্র সেই কোডগুলিকে একীভূত করার লক্ষ্যে যা বিভিন্ন লোকেরা একক কোড বেসের মধ্যে লেখে। এখানেই শেষ.

CI এর সাথে সাথে, সাধারণত অন্যান্য অনুশীলন রয়েছে - যেমন ক্রমাগত স্থাপনা, রিলিজ ম্যানেজমেন্ট, তবে আমরা পরে সে সম্পর্কে কথা বলব।

সিআই নিজেই আমাদের বলে যে বিভিন্ন লোক কোড লেখে এবং এই কোডটি অবশ্যই একটি একক কোড বেসে একত্রিত হতে হবে।

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

তারপরে আমরা কিছু পরীক্ষা চালাতে পারি, যা একটি পৃথক অনুশীলনও। পরীক্ষা সব সবুজ - এটি দ্বিতীয় ভাল লক্ষণ. কিন্তু আবার, এই কিছুই মানে না.

কিন্তু আপনি কেন এটা করবেন? আজ আমি যে সমস্ত অনুশীলনের কথা বলব সেগুলি প্রায় একই মান বহন করে, অর্থাৎ প্রায় একই সুবিধা এবং প্রায় একই ভাবে পরিমাপ করা হয়।

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

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

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

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

যদি আমাদের একটি ক্রমাগত ইন্টিগ্রেশন অনুশীলন থাকে, তাহলে আমি আমার কোড লেখার সাথে সাথে এটি আমাদেরকে এখানে এবং এই মুহূর্তে বেশ কয়েকটি স্বয়ংক্রিয় সরঞ্জাম দিয়ে এটি পরীক্ষা করার অনুমতি দেয়। এটি আমাকে সম্পূর্ণ ছবি নাও দিতে পারে, কিন্তু তবুও, এটি অন্তত কিছু ঝুঁকি দূর করবে। এবং যদি কোন সম্ভাব্য বাগ থাকে, আমি এখনই এটি সম্পর্কে জানতে পারব, অর্থাৎ, আক্ষরিক অর্থে কয়েক মিনিটের মধ্যে। আমাকে ৩ মাস পিছিয়ে যেতে হবে না। আমি শুধুমাত্র 3 মিনিট রোল ব্যাক করতে হবে. একটি ভাল কফি মেশিন 2 মিনিটের মধ্যে কফি তৈরি করার সময়ও পাবে না, তাই এটি বেশ দুর্দান্ত।

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

কিভাবে আমরা এই অনুশীলনের সাফল্য বা ব্যর্থতা পরিমাপ করতে পারি? আমরা CI প্রকল্পে যা বাস্তবায়ন করেছি তা আপনি বিগ বসকে রিপোর্ট করলে, তিনি ব্লা ব্লা ব্লা শুনতে পাবেন। আমরা এটি বাস্তবায়ন করেছি, ঠিক আছে, কিন্তু কেন, এটি আমাদের কাছে কী নিয়ে এসেছে, আমরা কীভাবে এটি পরিমাপ করব, আমরা এটি কতটা সঠিক বা ভুলভাবে বাস্তবায়ন করছি?

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

আমাদের আরেকটি অনুশীলন হল অটোমেশন টেস্টিং অনুশীলন, যা প্রায়শই CI অনুশীলনের সাথে আসে। তারা হাতে হাতে চলে যায়।

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

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

আমাদের UI অটোমেশন পরীক্ষা থাকতে পারে যা আমাদের পরীক্ষা করতে দেয় যে UI এর সাথে কাজ কতটা ভালভাবে গ্রাহকের দ্বারা সেট করা নির্দিষ্ট প্রয়োজনীয়তা পূরণ করে, ইত্যাদি।

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

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

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

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

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

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

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

এছাড়াও, যখন আপনি একে অপরের মধ্যে কোড সংহত করেন, যেমন কমান্ডের মধ্যে, এটি আপনাকে এটি UI এ কেমন দেখায় তাও দেখতে দেয়।

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

আমাদের পরবর্তী অনুশীলনটি হল স্বয়ংক্রিয় পুনরুদ্ধারের অনুশীলন, যথা অ্যাপ্লিকেশনটির পূর্ববর্তী সংস্করণে ফিরে আসা।

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

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

কিন্তু, আপনি যদি ক্যালেন্ডারের দিকে না দেখে থাকেন, 90 এর দশক প্রায় 30 বছর আগের। এখন সবকিছু একটু ভিন্নভাবে ঘটছে। এবং ট্র্যাজেডির মাত্রা কল্পনা করার চেষ্টা করুন যখন তারা আপনাকে বলে: “আমরা উত্পাদনে নিযুক্ত করেছি, কিন্তু সেখানে কিছু ভুল হয়েছে। এখানে আপনার FTP লগইন এবং পাসওয়ার্ড, প্রোডাকশনের সাথে সংযোগ করুন এবং দ্রুত সেখানে এটি ঠিক করুন।" আপনি যদি চাক নরিস হন তবে এটি কাজ করবে। যদি তা না হয়, তাহলে আপনার ঝুঁকি রয়েছে যে আপনি যদি একটি বাগ ঠিক করেন তবে আপনি আরও 10টি করতে পারবেন। এই কারণেই আগের সংস্করণে ফিরে যাওয়ার এই অনুশীলনটি আপনাকে অনেক কিছু অর্জন করতে দেয়।

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

এখন এর আগের দুটি অনুশীলনকে একত্রিত করার চেষ্টা করা যাক। আমরা রিলিজ ম্যানেজমেন্ট নামে তৃতীয় একটি পাব।

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

এছাড়া আরো একটা দুঃখ আছে। আপনি যখন তৈরি করবেন, এমনকি একই মেশিনে, আপনি একই উত্সগুলি তৈরি করবেন, আপনার এখনও কোনও গ্যারান্টি নেই যে এই মেশিনটি শেষ বিল্ডের সময় যে অবস্থায় ছিল সেই অবস্থায় রয়েছে৷

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

অতএব, রিলিজ ম্যানেজমেন্ট অনুশীলন একটি আর্টিফ্যাক্ট রিপোজিটরি বা গ্যালারি বা লাইব্রেরি নামে একটি অতিরিক্ত বিমূর্ততা প্রবর্তনের পরামর্শ দেয়। আপনি যা খুশি কল করতে পারেন।

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

তারপর আমরা এটি গ্রহণ করি এবং স্বয়ংক্রিয়ভাবে এটিকে dev পরিবেশে স্থাপন করি। আমরা সেখানে দৌড়, এবং যদি সবকিছু ভাল হয়, তাহলে আমরা মঞ্চে স্থাপন করি। যদি সবকিছু ঠিকঠাক থাকে, তাহলে আমরা একই আর্কাইভ উৎপাদনে স্থাপন করি, একই বাইনারি, ঠিক একবার সংকলিত।

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

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

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

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

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

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

পরবর্তী অনুশীলন, যা বিদ্যমান এবং গুরুত্বপূর্ণ, কিন্তু যা খুব কম লোক ব্যবহার করে, তা হল অ্যাপ্লিকেশন পারফরম্যান্স মনিটরিং।

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

একটি ভাল উপায়ে, প্রায় প্রতিটি বিল্ডে অ্যাপ্লিকেশান পারফরম্যান্স মনিটরিং করা ভাল হবে, যদিও আপনি যেমন বোঝেন, এটি সবসময় সম্ভব নয়। তবে, সর্বনিম্নভাবে, প্রতিটি প্রকাশের জন্য এটি করা দরকার।

এটা কেন গুরুত্বপূর্ণ? কারণ আপনি যদি হঠাৎ কর্মক্ষমতা হ্রাস অনুভব করেন, তাহলে আপনাকে স্পষ্টভাবে বুঝতে হবে কেন। যদি আপনার দলে, বলুন, দুই সপ্তাহের স্প্রিন্ট থাকে, তাহলে অন্তত প্রতি দুই সপ্তাহে একবার আপনার আবেদনটি আলাদা আলাদা সার্ভারে স্থাপন করা উচিত, যেখানে আপনার কাছে একটি পরিষ্কারভাবে স্থির প্রসেসর, র‌্যাম, ডিস্ক ইত্যাদি রয়েছে এবং সেই একই পারফরম্যান্স পরীক্ষা চালান। . আপনি ফলাফল পাবেন. আগের স্প্রিন্ট থেকে এটি কীভাবে পরিবর্তিত হয়েছে তা দেখুন।

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

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

সম্প্রতি একটি মজার ঘটনা ঘটেছে। ছেলেরা আমার কাছে এসে বলল: "আমাদের আবেদনের নিরাপত্তা অডিট করতে সাহায্য করুন।" আমরা দীর্ঘদিন ধরে কোডটি একসাথে দেখেছিলাম, তারা আমাকে অ্যাপ্লিকেশন সম্পর্কে বলেছিল, ডায়াগ্রাম এঁকেছিল। এবং প্লাস বা বিয়োগ সবকিছুই ছিল যৌক্তিক, বোধগম্য, নিরাপদ, কিন্তু একটি কিন্তু ছিল! তাদের সোর্স কন্ট্রোলে কনফিগারেশন ফাইল ছিল, যার মধ্যে আইপি ডাটাবেসের সাথে প্রোডাকশনের ফাইল, এই ডাটাবেসের সাথে সংযোগ করার জন্য লগইন এবং পাসওয়ার্ড সহ।

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

কনফিগারেশন ব্যবস্থাপনা. আমাদের বিভিন্ন পরিবেশে বিভিন্ন কনফিগারেশন থাকতে পারে। উদাহরণস্বরূপ, QA, ডেমো, প্রোডাকশন এনভায়রনমেন্ট ইত্যাদির জন্য ডাটাবেসের জন্য আমাদের বিভিন্ন লগইন এবং পাসওয়ার্ড থাকতে পারে।

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

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

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

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

কেন? অবশ্যই, এটি দুর্দান্ত হবে যদি প্রতিটি বিকাশকারীর একটি ভার্চুয়াল মেশিন থাকে যা 24/7 কাজ করবে। তবে সম্ভবত এটি আপনার কাছে খবর, সম্ভবত আপনি মনোযোগ দেননি, তবে বিকাশকারী নিজেই 24/7 কাজ করেন না। একজন বিকাশকারী সাধারণত দিনে 8 ঘন্টা কাজ করে। এমনকি যদি তিনি তাড়াতাড়ি কাজ করতে আসেন, তবে তিনি একটি বড় লাঞ্চ করেন যার সময় তিনি জিমে যান। এটিকে দিনে 12 ঘন্টা হতে দিন যখন বিকাশকারী আসলে এই সংস্থানগুলি ব্যবহার করে৷ আমাদের আইন অনুসারে, আমাদের সপ্তাহে 5 দিনের মধ্যে 7টি কর্মদিবস হিসাবে বিবেচিত হয়।

তদনুসারে, সপ্তাহের দিনগুলিতে এই মেশিনটি 24 ঘন্টা কাজ করা উচিত নয়, তবে কেবল 12টি, এবং সপ্তাহান্তে এই মেশিনটি মোটেও কাজ করা উচিত নয়। দেখে মনে হবে সবকিছু খুব সহজ, কিন্তু এখানে কী বলা গুরুত্বপূর্ণ? এই মৌলিক সময়সূচীতে এই সাধারণ অনুশীলনটি বাস্তবায়ন করে, এটি আপনাকে এই পরিবেশগুলি বজায় রাখার খরচ 70% কমাতে দেয়, অর্থাৎ আপনি আপনার dev, QA, ডেমো, পরিবেশের মূল্য নিয়েছেন এবং এটিকে 3 দ্বারা ভাগ করেছেন।

প্রশ্ন হলো, বাকি টাকা দিয়ে কী করবেন? উদাহরণস্বরূপ, ডেভেলপারদের ReSharper কেনা উচিত যদি তারা ইতিমধ্যে না থাকে। অথবা একটি ককটেল পার্টি আছে. আপনার যদি পূর্বে এমন একটি পরিবেশ থাকে যেখানে dev এবং QA উভয়ই চরে থাকেন, এবং এটিই, এখন আপনি 3টি ভিন্ন পরিবেশ তৈরি করতে পারেন যা বিচ্ছিন্ন হবে এবং লোকেরা একে অপরের সাথে হস্তক্ষেপ করবে না।

ক্রমাগত কর্মক্ষমতা পরিমাপ সহ স্লাইড সম্পর্কে, আমরা কিভাবে কর্মক্ষমতা তুলনা করতে পারি যদি প্রকল্পের ডাটাবেসে 1 রেকর্ড থাকে, দুই মাস পরে এক মিলিয়ন থাকে? কিভাবে বুঝবেন কেন এবং কর্মক্ষমতা পরিমাপের বিন্দু কি?

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

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

আমরা কি একটি বিশেষ পরীক্ষার পরিবেশে কর্মক্ষমতা পরিমাপের বিষয়ে কথা বলছি? অর্থাৎ এটা কি উৎপাদন নয়?

হ্যাঁ, এটি উত্পাদন নয়, এটি একটি পরীক্ষার পরিবেশ, যা সর্বদা একই থাকে যাতে আপনি এটিকে পূর্ববর্তী পরিমাপের সাথে তুলনা করতে পারেন।

বুঝতে পেরেছি ধন্যবাদ!

যদি কোন প্রশ্ন না থাকে, আমি মনে করি আমরা শেষ করতে পারি। ধন্যবাদ!

উত্স: www.habr.com