Git ব্রাঞ্চ মডেল
বৃহস্পতিবার, ২৫ অক্টোবর, ২০১৮
আমার ক্লাসে ছাত্রছাত্রীরা Python প্রোগ্রামিং ল্যাঙ্গুয়েজে প্রজেক্ট করছে। IDE হিসাবে PyCharm ব্যবহার করছে। প্রজেক্টের মার্কিং বা ইভালুয়েশন-এর একটা নির্ণায়ক হিসাবে (Criteria -র বাংলা ভেবে না পেয়ে Google ট্রান্সলেট -এ খুঁজে দেখি এই অনুবাদ দেখাচ্ছে, খারাপ না!) তাদেরকে বলেছিলাম যে তাদের কোড কোনো এক প্রকার ভার্সন কন্ট্রোল সিস্টেমে হোস্ট করতে হবে। উদাহরণ হিসাবে GitHub কিংবা Google Code ব্যবহার করতে বলেছিলাম। প্রজেক্টের প্রথম ইটারেশন প্রেসেন্টেশনের দিন দেখা গেলো ৬ টা টিমের মধ্যে শুধু একটা টীম তা করতে পেরেছে, বাকিরা নাকি অনেক চেষ্টা করেও GitHub -এ কোড হোস্ট করতে পারে নাই। একটা টীম তো বলেই বসলো যে খুব ভালো হয় তাদেরকে এই GitHub -এ কিভাবে কোড হোস্ট করতে হয় তার উপর যদি একটা টিউটোরিয়াল করাই!
GitHub (সাথে Git) কী সেটা নাহয় কম কথাতেই বুঝিয়ে বলা যায়, কিন্তু Git ব্রাঞ্চ -এর প্রয়োজনীয়তা আর ইন্ডাস্ট্রিতে কিভাবে সেটা ব্যবহার করা হয় (Git ব্রানচিং মডেল) সেটা ঠিক কিভাবে বুঝাবো সেটা ভেবে পাচ্ছিলাম না। আমার আগের কাজের, অর্থাৎ সফটওয়্যার ইঞ্জিনিয়ার হিসাবে গত ৪ বছরের অভিজ্ঞতা থেকে কিছু একটা বলবো ঠিক করেছিলাম, কিন্তু সুন্দর করে গুছিয়ে কিভাবে বলবো সেটা মাথায় আসছিলো না। বসে বসে তাই অনলাইনে ম্যাটেরিয়াল খুঁজছিলাম, আর খুঁজতে খুঁজতেই দুর্দান্ত একটা ব্লগ পোস্ট পেয়েছি। ২০১০ সালে লেখা এই ব্লগ পোস্টের মালিককে সাথে সাথেই ইমেইল দিয়ে তাঁর ব্লগের ছবি আর লেখার ভাবার্থ করতে পারবো কিনা না জিজ্ঞেস করলাম, আর ১০ মিনিটের মধ্যেই ভদ্রলোকের উত্তর পেয়ে গেলাম! বললেন সম্ভব হলে তাঁর ব্লগের একটা লিংক আর তাঁর নামটা উল্লেখ করলেই হবে, আমি সানন্দে রাজি!
ভিন্সেন্ট ড্রিসেন নামের এই লোক নেদারল্যান্ডের বাসিন্দা। আর তাঁর যেই ব্লগ পোস্টের উপর আজকের লেখা সেটার লিংক: https://nvie.com/posts/a-successful-git-branching-model/
যাক, এখন আসল কথায় আসি। আজকাল যেকোনো সফটওয়্যার কোম্পানিতেই কোড ডেভেলপমেন্টের জন্য ভার্সন কন্ট্রোল সিস্টেম ব্যবহার করা হয়। মূলতঃ অনেকগুলো টীম বা একই টিমের ভিন্ন ভিন্ন ডেভেলপাররা যেন একই সাথে কোডের উপর কাজ করতে পারে, সেটা করতে গিয়ে যেন কোডে কোনো কনফ্লিক্ট না হয়, কোনো বাগ (bug) ধরা পড়লে যেন সহজেই সেই কোড ফিক্স কিংবা কমিট করা কোড বের করে নিয়ে পুরোনো ভার্সনে ফিরিয়ে নিয়ে আসা যায় ইত্যাদি নিশ্চিত করতেই ভার্সন কন্ট্রোল সিস্টেম ব্যবহার করা হয়। আমার আগের একটা ব্লগ পোস্টে এই বিষয়টা নিয়ে কিছু লিখেছিলাম, দেখে নিতে পারেন।
কিন্তু ইন্ডাস্ট্রিতে সাধারণত একটা মডেল ব্যবহার করে এই ভার্সন কন্ট্রোল সিস্টেমটি ইমপ্লিমেন্ট করা হয়।এই মডেল বা Git ব্রাঞ্চ মডেল বুঝতে শুরুতেই নিচের ছবিটা ভালো করে দেখুন। তাড়াহুড়ো না করে সময় নিয়ে খুঁটিয়ে খুঁটিয়ে দেখুন, কাজে লাগবে:
এবার ব্যাখ্যা করার চেষ্টা করছি। প্রথমত, ছবিতে উপর থেকে নিচে সময় পার হওয়া বোঝাচ্ছে (বামের উপর থেকে নিচে যাওয়া কালো অ্যারো লাইন)। খুব সাধারণ ভাবে বললে, কোড হোস্টিং সার্ভারে (যেমন GitHub, BitBucket) একটা মূল ব্রাঞ্চ থাকে যেটা master বা প্রোডাকশন ব্রাঞ্চ (অনেকসময় প্রোডাকশন ব্রাঞ্চ আবার master ব্রাঞ্চ থেকে আলাদা হয়)। প্রোডাকশনে যাওয়া কোডের ভার্সন এই ব্রাঞ্চ-এ মেইনটেইন করা হয় (উপরের ছবিতে ডানের নীল ডটের লাইন)। তবে কোডে যেকোনো ডেভেলপমেন্ট বা পরিবর্তন করা হয় প্রোডাকশন ব্রাঞ্চ থেকে তৈরি করা আরেকটা ব্রাঞ্চে - এটাকে সাধারণত ডেভেলপমেন্ট (development) ব্রাঞ্চ বলা হয় (ছবিতে হলুদ ডটের লাইন) । ডেভেলপাররা এই ব্রাঞ্চ থেকেই আবার নতুন ব্রাঞ্চ তৈরী করে নিয়ে সাধারণত কোনো ইস্যু বা ফীচার -এর উপর নিজেদের কম্পিউটারে কাজ করেন (গোলাপী ডটের লাইন - feature branches)। কাজ শেষ হয়ে গেলে (অর্থাৎ কোড লেখা, বিভিন্ন রকম টেস্ট করা শেষ হলে - কেবল তারপরই) তারা তাদের কোড ডেভেলপমেন্ট ব্রাঞ্চে "পুশ" করেন। একটা পুশ করার আগে ডেভেলপাররা নিজেদের ব্রাঞ্চেই অনেকবার কোড কমিট (commit) করেন। ছবিতে একেকটা ডট সেই কমিট করাই বোঝাচ্ছে। যদিও ছবিতে ঠিক ঐরকম ভাবে দেখানো হয় নাই, ডেভেলপাররা নিজেদের ব্রাঞ্চ development ব্রাঞ্চে পুশ করার আগে কিন্তু development ব্রাঞ্চ থেকে কোড "আপডেট বা পুল" করে নেন। এটা করেন যাতে অন্যদের ইতিমধ্যে করা "পুশ" গুলোর পরিবর্তন নিজেদের ব্রাঞ্চে নিয়ে আসা যায়। এটা করা বাধ্যতামূলক নয় (সেজন্যই হয়তো ছবিতে দেখানো হয় নাই), কিন্তু কোডের মার্জ কনফ্লিক্ট দূর করার জন্য খুবই উপকারী একটা অভ্যাস।
কোনো একটা প্রোডাকশন রিলিজের আগে সাধারণত একটা "কাট-অফ" বা কোড ফ্রিজ ডেট থাকে। সব ডেভেলপারদের কাজ এর আগেই শেষ করতে হয়। যাদের কাজ শেষ হয়, অর্থাৎ যারা development ব্রাঞ্চে "পুশ" করে ফেলেন, ওই অবস্থার development ব্রাঞ্চ থেকে আরেকটা রিলিজ ব্রাঞ্চ তৈরী করা হয় (ছবিতে সবুজ ডটের লাইন)। রিলিজ ব্রাঞ্চ সাধারণত রিলিজ ক্যান্ডিডেট এনভায়রনমেন্ট (আমার আগের কাজের জায়গায় একে RC1 বলা হতো) বা টেস্টিং এনভিরনমেন্টে ডেপ্লয় করা হয়। QA, টেস্ট ইঞ্জিনিয়াররা এই এনভিরনমেন্টে যাবতীয় টেস্ট করেন। কোনো বাগ পাওয়া গেলে অনেক সময় এই ব্রাঞ্চেই কোড ফিক্স করা হয়, অথবা আবার ডেভেলপমেন্ট ব্রাঞ্চে কোড ফিক্স করে তারপর আবার রিলিজ ব্রাঞ্চে পুশ করা হয়। রিলিজ ব্রাঞ্চে করা যেকোনো পরিবর্তন অটোমেটিকালি development ব্রাঞ্চে মার্জ করা হয় যাতে করে বাকি ডেভেলপাররা সব সময় লেটেস্ট কোড পেতে পারেন।
যখন টেস্টিং শেষে QA টীম সাইন অফ করে অর্থাৎ গ্রিন সিগন্যাল দেয়, তখন রিলিজ ব্রাঞ্চের কোড master ব্রাঞ্চে পুশ করা হয়। খেয়াল করবেন, এই একই কোড কিন্তু development ব্রাঞ্চেও পুশ করা হয়। এই পুশকে সাধারণত একটা ট্যাগ দিয়ে চিহ্ন দিয়ে রাখা হয়। এই কোডই প্রোডাকশন এনভায়রনমেন্ট -এ ডেপ্লয় করা হয়। ইউসাররা এই কোড ব্যবহার করার সুযোগ পান।
সব শেষে বলি, অনেক সময় প্রোডাকশন কোডে ক্রিটিক্যাল বাগ পাওয়া যায়। স্বাভাবিক পদ্ধতির ডেভেলপমেন্ট অর্থাৎ, development ব্রাঞ্চ থেকে নতুন ফিচার বা বাগ ফিক্স ব্রাঞ্চ তৈরি করে কোড ফিক্স, তারপর রিলিজ ব্রাঞ্চে কোড পুশ, সেটা টেস্ট এনভিরনমেন্টে ডেপ্লয় করে টেস্ট করা - ইত্যাদি করার সময় থাকে না। সেইসব ক্ষেত্রে hotfix ব্রাঞ্চ তৈরি করে (ছবিতে লাল ডটের লাইন) তাতেই কোড ফিক্স করে আবার master ব্রাঞ্চে (একই সাথে development ব্রাঞ্চে) কোড পুশ করা হয়।
আর এভাবেই একটা কোডের সময়ের সাথে বেড়ে ওঠা চলতে থাকে। হাজার লাইনের ছোট একটা কোড একসময় মিলিয়ন বা লক্ষাধিক লাইনের বিশাল কোডে পরিণত হয়। এর মধ্যে কত ডেভেলপার/সফটওয়্যার ইঞ্জিনিয়ার আসে আর যায় - কোড থেমে থাকে না!
বলে রাখা ভালো, Git branching model শুধু এই একটাই না, আরো আছে। প্যাট্রিক পোর্তো -র লেখা এই ব্লগ পোস্টে কয়েকটার সম্পর্কে জানা যাবে। আর ভিন্সেন্টের লেখা মূল ব্লগটা পড়ার অনুরোধ থাকলো।
আর এই কোড ব্রানচিং, ডেপ্লয় ইত্যাদি সাধারণত DevOps - দের কাজ। খুব ছোট কোম্পানিতে হয়তো ডেভেলপাররা নিজেরাই এই কাজ গুলো করে থাকেন। কিন্তু দিন দিন এই কাজগুলো স্পেশালাইজড লোকজন (DevOps) রা করছেন। এই রোলে এখন অনেক লোককেই চাকরি হয়। লিনাক্স কম্যান্ড, স্ক্রিপ্টিং আর Git কমান্ডে আপনি ভালো হলে DevOps রোলে কাজ করার চেষ্টা করে দেখতে পারেন।
ধন্যবাদ।
--ইশতিয়াক
বৃহস্পতিবার, ২৫ অক্টোবর, ২০১৮
আমার ক্লাসে ছাত্রছাত্রীরা Python প্রোগ্রামিং ল্যাঙ্গুয়েজে প্রজেক্ট করছে। IDE হিসাবে PyCharm ব্যবহার করছে। প্রজেক্টের মার্কিং বা ইভালুয়েশন-এর একটা নির্ণায়ক হিসাবে (Criteria -র বাংলা ভেবে না পেয়ে Google ট্রান্সলেট -এ খুঁজে দেখি এই অনুবাদ দেখাচ্ছে, খারাপ না!) তাদেরকে বলেছিলাম যে তাদের কোড কোনো এক প্রকার ভার্সন কন্ট্রোল সিস্টেমে হোস্ট করতে হবে। উদাহরণ হিসাবে GitHub কিংবা Google Code ব্যবহার করতে বলেছিলাম। প্রজেক্টের প্রথম ইটারেশন প্রেসেন্টেশনের দিন দেখা গেলো ৬ টা টিমের মধ্যে শুধু একটা টীম তা করতে পেরেছে, বাকিরা নাকি অনেক চেষ্টা করেও GitHub -এ কোড হোস্ট করতে পারে নাই। একটা টীম তো বলেই বসলো যে খুব ভালো হয় তাদেরকে এই GitHub -এ কিভাবে কোড হোস্ট করতে হয় তার উপর যদি একটা টিউটোরিয়াল করাই!
GitHub (সাথে Git) কী সেটা নাহয় কম কথাতেই বুঝিয়ে বলা যায়, কিন্তু Git ব্রাঞ্চ -এর প্রয়োজনীয়তা আর ইন্ডাস্ট্রিতে কিভাবে সেটা ব্যবহার করা হয় (Git ব্রানচিং মডেল) সেটা ঠিক কিভাবে বুঝাবো সেটা ভেবে পাচ্ছিলাম না। আমার আগের কাজের, অর্থাৎ সফটওয়্যার ইঞ্জিনিয়ার হিসাবে গত ৪ বছরের অভিজ্ঞতা থেকে কিছু একটা বলবো ঠিক করেছিলাম, কিন্তু সুন্দর করে গুছিয়ে কিভাবে বলবো সেটা মাথায় আসছিলো না। বসে বসে তাই অনলাইনে ম্যাটেরিয়াল খুঁজছিলাম, আর খুঁজতে খুঁজতেই দুর্দান্ত একটা ব্লগ পোস্ট পেয়েছি। ২০১০ সালে লেখা এই ব্লগ পোস্টের মালিককে সাথে সাথেই ইমেইল দিয়ে তাঁর ব্লগের ছবি আর লেখার ভাবার্থ করতে পারবো কিনা না জিজ্ঞেস করলাম, আর ১০ মিনিটের মধ্যেই ভদ্রলোকের উত্তর পেয়ে গেলাম! বললেন সম্ভব হলে তাঁর ব্লগের একটা লিংক আর তাঁর নামটা উল্লেখ করলেই হবে, আমি সানন্দে রাজি!
 |
| ইমেইলে অনুমতি |
ভিন্সেন্ট ড্রিসেন নামের এই লোক নেদারল্যান্ডের বাসিন্দা। আর তাঁর যেই ব্লগ পোস্টের উপর আজকের লেখা সেটার লিংক: https://nvie.com/posts/a-successful-git-branching-model/
যাক, এখন আসল কথায় আসি। আজকাল যেকোনো সফটওয়্যার কোম্পানিতেই কোড ডেভেলপমেন্টের জন্য ভার্সন কন্ট্রোল সিস্টেম ব্যবহার করা হয়। মূলতঃ অনেকগুলো টীম বা একই টিমের ভিন্ন ভিন্ন ডেভেলপাররা যেন একই সাথে কোডের উপর কাজ করতে পারে, সেটা করতে গিয়ে যেন কোডে কোনো কনফ্লিক্ট না হয়, কোনো বাগ (bug) ধরা পড়লে যেন সহজেই সেই কোড ফিক্স কিংবা কমিট করা কোড বের করে নিয়ে পুরোনো ভার্সনে ফিরিয়ে নিয়ে আসা যায় ইত্যাদি নিশ্চিত করতেই ভার্সন কন্ট্রোল সিস্টেম ব্যবহার করা হয়। আমার আগের একটা ব্লগ পোস্টে এই বিষয়টা নিয়ে কিছু লিখেছিলাম, দেখে নিতে পারেন।
কিন্তু ইন্ডাস্ট্রিতে সাধারণত একটা মডেল ব্যবহার করে এই ভার্সন কন্ট্রোল সিস্টেমটি ইমপ্লিমেন্ট করা হয়।এই মডেল বা Git ব্রাঞ্চ মডেল বুঝতে শুরুতেই নিচের ছবিটা ভালো করে দেখুন। তাড়াহুড়ো না করে সময় নিয়ে খুঁটিয়ে খুঁটিয়ে দেখুন, কাজে লাগবে:
 |
| From Vincent Driessen's blog post: https://nvie.com/posts/a-successful-git-branching-model/ |
এবার ব্যাখ্যা করার চেষ্টা করছি। প্রথমত, ছবিতে উপর থেকে নিচে সময় পার হওয়া বোঝাচ্ছে (বামের উপর থেকে নিচে যাওয়া কালো অ্যারো লাইন)। খুব সাধারণ ভাবে বললে, কোড হোস্টিং সার্ভারে (যেমন GitHub, BitBucket) একটা মূল ব্রাঞ্চ থাকে যেটা master বা প্রোডাকশন ব্রাঞ্চ (অনেকসময় প্রোডাকশন ব্রাঞ্চ আবার master ব্রাঞ্চ থেকে আলাদা হয়)। প্রোডাকশনে যাওয়া কোডের ভার্সন এই ব্রাঞ্চ-এ মেইনটেইন করা হয় (উপরের ছবিতে ডানের নীল ডটের লাইন)। তবে কোডে যেকোনো ডেভেলপমেন্ট বা পরিবর্তন করা হয় প্রোডাকশন ব্রাঞ্চ থেকে তৈরি করা আরেকটা ব্রাঞ্চে - এটাকে সাধারণত ডেভেলপমেন্ট (development) ব্রাঞ্চ বলা হয় (ছবিতে হলুদ ডটের লাইন) । ডেভেলপাররা এই ব্রাঞ্চ থেকেই আবার নতুন ব্রাঞ্চ তৈরী করে নিয়ে সাধারণত কোনো ইস্যু বা ফীচার -এর উপর নিজেদের কম্পিউটারে কাজ করেন (গোলাপী ডটের লাইন - feature branches)। কাজ শেষ হয়ে গেলে (অর্থাৎ কোড লেখা, বিভিন্ন রকম টেস্ট করা শেষ হলে - কেবল তারপরই) তারা তাদের কোড ডেভেলপমেন্ট ব্রাঞ্চে "পুশ" করেন। একটা পুশ করার আগে ডেভেলপাররা নিজেদের ব্রাঞ্চেই অনেকবার কোড কমিট (commit) করেন। ছবিতে একেকটা ডট সেই কমিট করাই বোঝাচ্ছে। যদিও ছবিতে ঠিক ঐরকম ভাবে দেখানো হয় নাই, ডেভেলপাররা নিজেদের ব্রাঞ্চ development ব্রাঞ্চে পুশ করার আগে কিন্তু development ব্রাঞ্চ থেকে কোড "আপডেট বা পুল" করে নেন। এটা করেন যাতে অন্যদের ইতিমধ্যে করা "পুশ" গুলোর পরিবর্তন নিজেদের ব্রাঞ্চে নিয়ে আসা যায়। এটা করা বাধ্যতামূলক নয় (সেজন্যই হয়তো ছবিতে দেখানো হয় নাই), কিন্তু কোডের মার্জ কনফ্লিক্ট দূর করার জন্য খুবই উপকারী একটা অভ্যাস।
কোনো একটা প্রোডাকশন রিলিজের আগে সাধারণত একটা "কাট-অফ" বা কোড ফ্রিজ ডেট থাকে। সব ডেভেলপারদের কাজ এর আগেই শেষ করতে হয়। যাদের কাজ শেষ হয়, অর্থাৎ যারা development ব্রাঞ্চে "পুশ" করে ফেলেন, ওই অবস্থার development ব্রাঞ্চ থেকে আরেকটা রিলিজ ব্রাঞ্চ তৈরী করা হয় (ছবিতে সবুজ ডটের লাইন)। রিলিজ ব্রাঞ্চ সাধারণত রিলিজ ক্যান্ডিডেট এনভায়রনমেন্ট (আমার আগের কাজের জায়গায় একে RC1 বলা হতো) বা টেস্টিং এনভিরনমেন্টে ডেপ্লয় করা হয়। QA, টেস্ট ইঞ্জিনিয়াররা এই এনভিরনমেন্টে যাবতীয় টেস্ট করেন। কোনো বাগ পাওয়া গেলে অনেক সময় এই ব্রাঞ্চেই কোড ফিক্স করা হয়, অথবা আবার ডেভেলপমেন্ট ব্রাঞ্চে কোড ফিক্স করে তারপর আবার রিলিজ ব্রাঞ্চে পুশ করা হয়। রিলিজ ব্রাঞ্চে করা যেকোনো পরিবর্তন অটোমেটিকালি development ব্রাঞ্চে মার্জ করা হয় যাতে করে বাকি ডেভেলপাররা সব সময় লেটেস্ট কোড পেতে পারেন।
যখন টেস্টিং শেষে QA টীম সাইন অফ করে অর্থাৎ গ্রিন সিগন্যাল দেয়, তখন রিলিজ ব্রাঞ্চের কোড master ব্রাঞ্চে পুশ করা হয়। খেয়াল করবেন, এই একই কোড কিন্তু development ব্রাঞ্চেও পুশ করা হয়। এই পুশকে সাধারণত একটা ট্যাগ দিয়ে চিহ্ন দিয়ে রাখা হয়। এই কোডই প্রোডাকশন এনভায়রনমেন্ট -এ ডেপ্লয় করা হয়। ইউসাররা এই কোড ব্যবহার করার সুযোগ পান।
সব শেষে বলি, অনেক সময় প্রোডাকশন কোডে ক্রিটিক্যাল বাগ পাওয়া যায়। স্বাভাবিক পদ্ধতির ডেভেলপমেন্ট অর্থাৎ, development ব্রাঞ্চ থেকে নতুন ফিচার বা বাগ ফিক্স ব্রাঞ্চ তৈরি করে কোড ফিক্স, তারপর রিলিজ ব্রাঞ্চে কোড পুশ, সেটা টেস্ট এনভিরনমেন্টে ডেপ্লয় করে টেস্ট করা - ইত্যাদি করার সময় থাকে না। সেইসব ক্ষেত্রে hotfix ব্রাঞ্চ তৈরি করে (ছবিতে লাল ডটের লাইন) তাতেই কোড ফিক্স করে আবার master ব্রাঞ্চে (একই সাথে development ব্রাঞ্চে) কোড পুশ করা হয়।
আর এভাবেই একটা কোডের সময়ের সাথে বেড়ে ওঠা চলতে থাকে। হাজার লাইনের ছোট একটা কোড একসময় মিলিয়ন বা লক্ষাধিক লাইনের বিশাল কোডে পরিণত হয়। এর মধ্যে কত ডেভেলপার/সফটওয়্যার ইঞ্জিনিয়ার আসে আর যায় - কোড থেমে থাকে না!
বলে রাখা ভালো, Git branching model শুধু এই একটাই না, আরো আছে। প্যাট্রিক পোর্তো -র লেখা এই ব্লগ পোস্টে কয়েকটার সম্পর্কে জানা যাবে। আর ভিন্সেন্টের লেখা মূল ব্লগটা পড়ার অনুরোধ থাকলো।
আর এই কোড ব্রানচিং, ডেপ্লয় ইত্যাদি সাধারণত DevOps - দের কাজ। খুব ছোট কোম্পানিতে হয়তো ডেভেলপাররা নিজেরাই এই কাজ গুলো করে থাকেন। কিন্তু দিন দিন এই কাজগুলো স্পেশালাইজড লোকজন (DevOps) রা করছেন। এই রোলে এখন অনেক লোককেই চাকরি হয়। লিনাক্স কম্যান্ড, স্ক্রিপ্টিং আর Git কমান্ডে আপনি ভালো হলে DevOps রোলে কাজ করার চেষ্টা করে দেখতে পারেন।
ধন্যবাদ।
--ইশতিয়াক
No comments:
Post a Comment