আমি কি .gitignoreফাইলটিতে জ্যাঙ্গো মাইগ্রেশন ফাইল যুক্ত করব?
মাইগ্রেশন বিরোধের কারণে আমি সম্প্রতি প্রচুর গিট সমস্যা পেয়েছি এবং ভাবছিলাম যে আমার স্থানান্তর ফাইলগুলি উপেক্ষা করে চিহ্নিত করা উচিত কিনা।
যদি তা হয়, তবে আমি কীভাবে আমার অ্যাপ্লিকেশনগুলিতে থাকা সমস্ত মাইগ্রেশন যুক্ত করে .gitignoreফাইলগুলিতে যুক্ত করব ?
উত্তর:
জ্যাঙ্গো মাইগ্রেশন ডকুমেন্টেশন থেকে উদ্ধৃত :
প্রতিটি অ্যাপ্লিকেশনের জন্য স্থানান্তরকারী ফাইলগুলি সেই অ্যাপ্লিকেশনটির অভ্যন্তরে একটি "মাইগ্রেশন" ডিরেক্টরিতে থাকে এবং এর কোডবেজটির অংশ হিসাবে প্রতিশ্রুতিবদ্ধ এবং বিতরণ করার জন্য ডিজাইন করা হয়। আপনার একবার আপনার বিকাশ মেশিনে এগুলি তৈরি করা উচিত এবং তারপরে আপনার সহকর্মীদের মেশিনে, আপনার স্টেজিং মেশিনগুলিতে এবং শেষ পর্যন্ত আপনার উত্পাদন মেশিনে একই স্থানান্তর চালানো উচিত।
আপনি যদি এই প্রক্রিয়াটি অনুসরণ করেন তবে মাইগ্রেশন ফাইলগুলিতে আপনার কোনও মার্জ দ্বন্দ্ব হওয়া উচিত নয়।
সংস্করণ নিয়ন্ত্রণ শাখাগুলি মার্জ করার সময়, আপনি এখনও এমন পরিস্থিতির মুখোমুখি হতে পারেন যেখানে একই প্যারেন্ট মাইগ্রেশনের উপর ভিত্তি করে আপনার একাধিক মাইগ্রেশন রয়েছে, উদাহরণস্বরূপ যদি বিভিন্ন বিকাশকারী একসাথে একটি স্থানান্তর প্রবর্তন করেন। এই পরিস্থিতি সমাধানের একটি উপায় হ'ল _ নিমজ্জন_প্রবাস_কে পরিচয় করানো। কমান্ড দিয়ে প্রায়শই এটি স্বয়ংক্রিয়ভাবে করা যায়
./manage.py makemigrations --mergeযা একটি নতুন স্থানান্তর প্রবর্তন করবে যা বর্তমানের সমস্ত প্রধান স্থানান্তরের উপর নির্ভর করে। অবশ্যই এটি কেবল তখনই কাজ করে যখন প্রধান স্থানান্তরগুলির মধ্যে কোনও বিরোধ নেই, সেই ক্ষেত্রে আপনাকে ম্যানুয়ালি সমস্যার সমাধান করতে হবে।
এখানে কিছু জনকে সুপারিশ যে আপনি দেওয়া উচিত নয় সংস্করণ নিয়ন্ত্রণ আপনার মাইগ্রেশন কমিট, আমি কেন আপনি আসলে প্রসারিত করতে চাই উচিত , তাই না।
প্রথমত, আপনার উত্পাদন সিস্টেমগুলিতে প্রয়োগ করা মাইগ্রেশনগুলির একটি রেকর্ড আপনার প্রয়োজন। আপনি যদি উত্পাদনে পরিবর্তন স্থাপন করেন এবং ডাটাবেস স্থানান্তর করতে চান তবে আপনার বর্তমান অবস্থার বিবরণ প্রয়োজন। আপনি প্রতিটি প্রোডাকশন ডাটাবেসে মাইগ্রেশনগুলির পৃথক ব্যাকআপ তৈরি করতে পারেন তবে এটি অযথা জটিল মনে হয়।
দ্বিতীয়ত, মাইগ্রেশনগুলিতে প্রায়শই কাস্টম, হস্তাক্ষর কোড থাকে। এগুলি দিয়ে স্বয়ংক্রিয়ভাবে উত্পন্ন করা সর্বদা সম্ভব নয় ./manage.py makemigrations।
তৃতীয়ত, মাইগ্রেশনগুলি কোড পর্যালোচনাতে অন্তর্ভুক্ত করা উচিত। এগুলি আপনার উত্পাদন ব্যবস্থায় উল্লেখযোগ্য পরিবর্তন এবং এগুলির সাথে ভুল হতে পারে এমন অনেকগুলি জিনিস রয়েছে।
সংক্ষেপে, আপনি যদি নিজের উত্পাদন ডেটার বিষয়ে যত্নশীল হন তবে দয়া করে আপনার স্থানান্তরগুলি সংস্করণ নিয়ন্ত্রণে পরীক্ষা করুন।
আপনি নীচের প্রক্রিয়া অনুসরণ করতে পারেন।
আপনি makemigrationsস্থানীয়ভাবে চালাতে পারেন এবং এটি মাইগ্রেশন ফাইল তৈরি করে। রেপোতে এই নতুন মাইগ্রেশন ফাইলটি প্রতিশ্রুতিবদ্ধ করুন।
আমার মতে আপনার makemigrationsপ্রযোজনায় মোটেও চালানো উচিত নয় । আপনি migrateউত্পাদন চালাতে পারেন এবং আপনি স্থানীয় থেকে প্রতিশ্রুতিবদ্ধ মাইগ্রেশন ফাইল থেকে মাইগ্রেশন প্রয়োগ করা দেখতে পাবেন। এইভাবে আপনি সমস্ত দ্বন্দ্ব এড়াতে পারবেন।
স্থানান্তরের ফাইলগুলি তৈরি করতে স্থানীয় ENV এ ,
python manage.py makemigrations
python manage.py migrateএখন এই নতুন তৈরি ফাইলগুলি প্রতিশ্রুতিবদ্ধ করুন, নীচের মতো কিছু।
git add app/migrations/...
git commit -m 'add migration files' app/migrations/...উত্পাদন ENV এ , কেবল নীচের কমান্ডটি চালান।
python manage.py migratemigrateএবং makemigrationsপ্রতিশ্রুতিবদ্ধ মাইগ্রেশনগুলির জন্য কখনই নয় । কখনও ভেবে দেখিনি।
2018 ডক্স থেকে উদ্ধৃতি, জাজানো 2.0। (দুটি পৃথক কমান্ড = makemigrationsএবং migrate)
মাইগ্রেশনগুলি করার এবং প্রয়োগ করার জন্য পৃথক কমান্ডের কারণ হ'ল আপনি নিজের সংস্করণ নিয়ন্ত্রণ সিস্টেমে মাইগ্রেশন প্রতিশ্রুতিবদ্ধ করবেন এবং এটিকে আপনার অ্যাপ্লিকেশন দিয়ে পাঠিয়ে দেবেন; এগুলি কেবল আপনার বিকাশকে সহজ করে না, তারা অন্যান্য বিকাশকারী এবং উত্পাদনেও ব্যবহারযোগ্য।
টিএল; ডিআর: মাইগ্রেশন কমিট করুন, মাইগ্রেশন বিরোধগুলি সমাধান করুন, আপনার গিট ওয়ার্কফ্লো সামঞ্জস্য করুন।
মনে হচ্ছে আপনার দ্বন্দ্বগুলি উপেক্ষা করার পরিবর্তে আপনার গিট ওয়ার্কফ্লো সামঞ্জস্য করতে হবে ।
আদর্শভাবে, প্রতিটি নতুন বৈশিষ্ট্য একটি আলাদা শাখায় বিকাশিত হয় এবং একটি টান অনুরোধের সাথে ফিরে একত্রিত হয় ।
কোনও বিরোধ থাকলে পিআরগুলি একীভূত করা যায় না, সুতরাং যার দ্বন্দ্ব সমাধানের জন্য তার বৈশিষ্ট্যটি মার্জ করা দরকার, মাইগ্রেশন অন্তর্ভুক্ত রয়েছে। এর জন্য বিভিন্ন দলের মধ্যে সমন্বয় প্রয়োজন হতে পারে।
মাইগ্রেশন ফাইল কমিট করা যদিও এটি গুরুত্বপূর্ণ! যদি কোনও বিরোধ দেখা দেয়, জ্যাঙ্গো এমনকি আপনাকে এই দ্বন্দ্বগুলি সমাধান করতে সহায়তা করতে পারে ;)
আপনি কোনওভাবে মাইগ্রেশন সম্পাদনা না করে আপনি কেন বিবাদ পাচ্ছেন তা আমি ভাবতে পারি না ? এটি সাধারণত খারাপভাবে শেষ হয় - যদি কেউ কিছু মধ্যবর্তী কমিটগুলি মিস করে তবে তারা সঠিক সংস্করণ থেকে আপগ্রেড হবে না এবং তাদের ডাটাবেসের অনুলিপিটি নষ্ট হয়ে যাবে।
আমি যে প্রক্রিয়াটি অনুসরণ করি তা বেশ সহজ - আপনি যখনই কোনও অ্যাপ্লিকেশনটির জন্য মডেলগুলি পরিবর্তন করেন, আপনিও একটি স্থানান্তরিত প্রতিশ্রুতি দেন এবং তারপরে যে মাইগ্রেশন পরিবর্তন হয় না - যদি মডেলটিতে আপনার কিছু আলাদা প্রয়োজন হয়, তবে আপনি মডেলটি পরিবর্তন করেন এবং একটি প্রতিশ্রুতিবদ্ধ হন আপনার পরিবর্তনের পাশাপাশি নতুন মাইগ্রেশন।
গ্রিনফিল্ড প্রকল্পগুলিতে, আপনি প্রায়শই মাইগ্রেশন মুছতে পারেন এবং আপনি প্রকাশের সময় একটি 0001_ মাইগ্রেশন দিয়ে স্ক্র্যাচ থেকে শুরু করতে পারেন, তবে আপনার যদি প্রডাকশন কোড থাকে তবে আপনি পারবেন না (যদিও আপনি স্থানান্তরকে একের মধ্যে স্কোয়াশ করতে পারেন)।
সমাধানটি সাধারণত ব্যবহৃত হয়, এটি হ'ল যে কোনও কিছুকে মাস্টার হিসাবে মার্জ করার আগে, বিকাশকারীকে অবশ্যই কোনও দূরবর্তী পরিবর্তন আনতে হবে। মাইগ্রেশন সংস্করণগুলিতে যদি কোনও বিরোধ হয় তবে তার স্থানীয় নাম পরিবর্তন করা উচিত মাইগ্রেশনটির (দূরবর্তীটি অন্য দেবগণ দ্বারা পরিচালিত হয়েছে, এবং সম্ভবত সম্ভাব্যভাবে উত্পাদনে) এন + 1 করা হবে।
উন্নয়নের সময় কেবল মাইগ্রেশন না করানো ঠিক হবে (যদিও তা উপেক্ষা করবেন না, কেবল addতাদেরকে করবেন না )। তবে একবার আপনি প্রযোজনায় চলে গেলে, মডেল পরিবর্তনের সাথে স্কিমা সিঙ্ক করার জন্য আপনার সেগুলির প্রয়োজন।
তারপরে আপনাকে ফাইলটি সম্পাদনা করতে হবে এবং এটিকে পরিবর্তন করতে হবে dependencies সর্বশেষতম দূরবর্তী সংস্করণে হবে।
এটি জ্যাঙ্গো মাইগ্রেশনগুলির পাশাপাশি অন্যান্য অন্যান্য অনুরূপ অ্যাপ্লিকেশনের জন্য (স্ক্ল্যাচলেমি + আলেম্বিক, আরআর ইত্যাদি) কাজ করে।
গিটে একগুচ্ছ মাইগ্রেশন ফাইল থাকা অদৃশ্য। মাইগ্রেশন ফোল্ডারে কেবল একটি ফাইল রয়েছে যা আপনার উপেক্ষা করা উচিত নয়। এই ফাইলটি init .py ফাইল, আপনি যদি এটিকে উপেক্ষা করেন তবে অজগরটি আর ডিরেক্টরিটির অভ্যন্তরে সাবমডিউলগুলি সন্ধান করবে না, সুতরাং মডিউলগুলি আমদানির কোনও প্রচেষ্টা ব্যর্থ হবে। সুতরাং প্রশ্নটি হ'ল কীভাবে সমস্ত মাইগ্রেশন ফাইলগুলি উপেক্ষা করবেন তবে init .py? সমাধানটি হল: .gitignore ফাইলগুলিতে '0 * .py' যুক্ত করুন এবং এটি পুরোপুরিভাবে কাজটি করে।
আশা করি এটি কাউকে সাহায্য করবে।
গিটিংগোর মাইগ্রেশনগুলি, আপনার কাছে বিকাশ, মঞ্চায়ন ও উত্পাদন পরিবেশের জন্য পৃথক ডিবি থাকলে। দেবের জন্য উদ্দেশ্যে আপনি স্থানীয় স্ক্লাইট ডিবি ব্যবহার করতে পারেন এবং স্থানীয়ভাবে মাইগ্রেশনগুলির সাথে খেলতে পারেন। আমি আপনাকে চারটি অতিরিক্ত শাখা তৈরি করার পরামর্শ দিচ্ছি:
মাস্টার - মাইগ্রেশন ছাড়াই টাটকা কোডটি পরিষ্কার করুন। এই শাখার সাথে কেউ সংযুক্ত নেই। শুধুমাত্র কোড পর্যালোচনার জন্য ব্যবহৃত হয়
উন্নয়ন - প্রতিদিনের বিকাশ। ধাক্কা / টান গ্রহণ করা হয়েছে। প্রতিটি বিকাশকারী স্ক্লাইট ডিবিতে কাজ করছে
ক্লাউড_ডিএভি_এনভি - দূরবর্তী মেঘ / সার্ভার ডিএইভ পরিবেশ। কেবল টানুন। স্থানীয়ভাবে মেশিনে মাইগ্রেশন রাখুন, যা ডেড ডাটাবেসের কোড মোতায়েন এবং দূরবর্তী স্থানান্তরের জন্য ব্যবহৃত হয়
ক্লাউডপ্যাগ_এএনভি - দূরবর্তী মেঘ / সার্ভার স্ট্যাগ পরিবেশ AG কেবল টানুন। স্থানীয়ভাবে মেশিনে মাইগ্রেশন রাখুন যা স্ট্যাগ ডাটাবেসের কোড মোতায়েন এবং দূরবর্তী স্থানান্তরের জন্য ব্যবহৃত হয়
ক্লাউড_PROD_env - দূরবর্তী মেঘ / সার্ভার DEV পরিবেশ। কেবল টানুন। স্থানীয়ভাবে মেশিনে মাইগ্রেশন রাখুন, যা কোড স্থাপনা এবং প্রোড ডাটাবেসের দূরবর্তী মাইগ্রেশনের জন্য ব্যবহৃত হয়
দ্রষ্টব্য: 2, 3, 4 - স্থানান্তরগুলি রেপোগুলিতে রাখা যেতে পারে তবে পুল অনুরোধগুলি মার্জ করার কঠোর নিয়ম থাকা উচিত, তাই আমরা সিদ্ধান্ত নিয়েছিলাম এমন এক ব্যক্তিকে খুঁজে নেওয়ার সিদ্ধান্ত নিয়েছি, যে সমস্ত মাইগ্রেশন ফাইল রয়েছে এমন একমাত্র লোক - আমাদের মোতায়েন -er। প্রতিবার আমাদের মডেলগুলিতে কোনও পরিবর্তন হলে তিনি রিমোট ডিবি স্থানান্তরিত রাখেন।
সংক্ষিপ্ত উত্তর
আমি রেপোতে মাইগ্রেশন বাদ দিয়ে প্রস্তাব করছি। কোড মার্জ হওয়ার পরে, কেবল চালান ./manage.py makemigrationsএবং আপনি সম্পূর্ণ প্রস্তুত।
দীর্ঘ উত্তর আমার মনে হয় না যে আপনার স্থানান্তর ফাইলগুলি রেপোতে রাখা উচিত। এটি অন্য ব্যক্তির ডেভ পরিবেশ এবং অন্যান্য উত্সাহ এবং মঞ্চ পরিবেশে মাইগ্রেশন রাষ্ট্রগুলি লুণ্ঠন করবে। (উদাহরণস্বরূপ চিনির ট্যাংকের মন্তব্য দেখুন)।
আমার দৃষ্টিতে জাজানো স্থানান্তরের উদ্দেশ্য হ'ল পূর্ববর্তী মডেল রাজ্যগুলি এবং নতুন মডেল রাজ্যের মধ্যে ফাঁক খুঁজে বের করা এবং তারপরে এই ফাঁকটি সিরিয়াল করা। কোড একীকরণের পরে যদি আপনার মডেলটি পরিবর্তন makemigrationsহয় তবে ফাঁকটি খুঁজে বের করতে আপনি সহজ করতে পারেন । আপনি যখন স্বয়ংক্রিয়ভাবে এবং বাগ বিনামূল্যে অর্জন করতে পারেন তবে আপনি কেন ম্যানুয়ালি এবং সাবধানতার সাথে অন্যান্য স্থানান্তরকে মার্জ করতে চান? জাজানো ডকুমেন্টেশন বলছে,
তারা * (মাইগ্রেশন) * বেশিরভাগ স্বয়ংক্রিয়ভাবে নকশাকৃত
; দয়া করে এটি রাখুন মাইগ্রেশন ম্যানুয়ালি মার্জ করতে আপনাকে অন্যদের কী পরিবর্তন হয়েছে এবং পরিবর্তনের কোনও নির্ভরতা কী তা পুরোপুরি বুঝতে হবে। এটি প্রচুর ওভারহেড এবং ত্রুটির প্রবণ। সুতরাং মডেল ফাইল ট্র্যাকিং যথেষ্ট।
এটি ওয়ার্কফ্লোতে একটি ভাল বিষয়। আমি অন্যান্য বিকল্পের জন্য উন্মুক্ত।
manage.py makemigrations --mergeআমার জন্য সম্পূর্ণ স্বয়ংক্রিয়ভাবে কাজ করে।
makemigrations some_appকোনও সদস্য অভিনয় করেন তবে কেবলমাত্র সেই সদস্যের নিয়ন্ত্রণাধীন মডেলগুলিই ক্ষতিগ্রস্থ হবে না, তবে অন্যান্য সম্পর্কিত মডেলগুলিও প্রভাবিত হবে। এটি হ'ল, অন্যান্য অ্যাপ্লিকেশনে স্থানান্তর ফাইলগুলি (00 * _ *) পরিবর্তন করা হবে। এবং এটি গিটহাব থেকে চাপ দেওয়া বা টানার সময় অনেক বিবাদ সংক্রান্ত সমস্যার সৃষ্টি করে। যেহেতু বর্তমানে আমাদের সিস্টেম উত্পাদনের জন্য প্রস্তুত নয়, আমরা কেবল.gitignoreস্থানান্তর ফাইল। সিস্টেমটি উত্পাদন করতে গেলে কীভাবে সমাধান করা যায় তা আমরা এখনও জানি না। কারও কি কোন সমাধান আছে?