GitHub, Confluence এবং Jira-তে AI প্রকাশনা কর্মপ্রবাহ

AI সহযোগিতা কোর্সে ফিরে যান

মালিকেরা অনুমোদনের আগে অবদানকারী PROP-042 স্থির করে। Confluence প্রকাশক প্রয়োজনীয়তা হালনাগাদ করেন, GitHub রক্ষণাবেক্ষক বাস্তবায়ন মার্জ করেন, আর অপারেশনস রানবুক প্রকাশ করে। Jira প্রতিটি ধাপ নথিভুক্ত করে। অনুমতি যাচাইয়ের পরে এটি করুন, কারণ তিনটি সিস্টেম মিলে একটি অ্যাটমিক লেনদেন গঠন করে না। আপনার প্রকাশনা লেজার অসম্পূর্ণ সরবরাহকে দৃশ্যমান করে।

মূল বিষয় #

• অনুমোদিত অভিপ্রায় সরবরাহ করা আচরণ থেকে আলাদা।
• স্থির প্রস্তাব-রিভিশন পর্যালোচনাকে নির্দিষ্ট সংস্করণের সঙ্গে যুক্ত করে।
• প্রকাশনা লেজার অসম্পূর্ণতা প্রকাশ করে।
• সাম্প্রতিক পাঠ পরিবর্তিত ভিত্তি থেকে সুরক্ষা দেয়।

শুরু করার আগে #

পূর্বশর্ত: কর্মক্ষেত্র সেটআপ , প্রকাশনার প্রবেশাধিকার, মালিকেরা এবং রিপোজিটরি রক্ষণাবেক্ষক। আনুমানিক সময়: দুই ঘণ্টা। কঠিনতা: উন্নত সমন্বয়।

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

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

বর্তমান উৎস নথিভুক্ত করুন #

1. MAP-01 পড়ুন, তারপর ম্যাপ করা পেজ ID দিয়ে REQ-17 এবং RUN-04 খুলুন।
2. পেজ মেনু ও Page History খুলুন, তারপর সংখ্যাসূচক সংস্করণ, অবস্থা, ভাষ্য, মালিক এবং ব্যতিক্রম নথিভুক্ত করুন।
3. Jira আইটেম পড়ুন এবং প্রস্তাবের স্থির এক্সপোর্ট বা GitHub commit সংযুক্ত করুন। শুধু কী review evidence স্থির করে না।
4. অনুমোদিত POL-01 এবং সুরক্ষিত কনফিগারেশন বেসলাইন পড়ুন।
5. চ্যাটে কেবল প্রয়োজনীয় কৃত্রিম অংশ দিন, সেগুলোকে স্ন্যাপশট হিসেবে চিহ্নিত করুন এবং লেখার ক্ষমতাসম্পন্ন কাজ বন্ধ রাখুন।

Task: PROP-042, propose only
Authority: Confluence REQ-17 for intent, GitHub for behavior
Read: mapped current pages, versions, scope, exceptions
Proposal: synthetic export retention from 7 to 30 days
Output: requirement wording, config diff, runbook, ledger
Evidence: source ID and captured revision for each factual claim
Unknowns: missing access and absent runtime observations
Stop: conflict, changed base, or denied access

অফলাইন প্যাকেট স্ন্যাপশট-ভিত্তিক থাকে। লেখার আগে প্রকাশক বর্তমান উৎস আবার পড়েন। প্রবেশাধিকার না পেলে প্রকাশনা বন্ধ থাকে। পুরোনো এক্সপোর্ট বর্তমান অনুমোদনের বিকল্প নয়।

প্রস্তাব স্থির করুন #

{
  "proposal_id": "PROP-042",
  "proposal_revision": 1,
  "requirement_base_version": 1,
  "runbook_base_version": 1,
  "policy_version": 1,
  "from_days": 7,
  "to_days": 30,
  "status": "awaiting-owner-review",
  "publication_order": ["requirement", "implementation", "runbook", "delivery"]
}

উদাহরণে দেওয়া পেজ সংস্করণের বদলে বাস্তবে ধারণ করা সংস্করণ বসান। স্থির JSON এবং প্রস্তাবিত ভাষ্য Jira-তে সংযুক্ত করুন। প্রতিটি মালিক ভূমিকা, সিদ্ধান্ত, প্রস্তাব-রিভিশন, উৎস সংস্করণ এবং পর্যালোচনার সময় নথিভুক্ত করেন। যেকোনো গুরুত্বপূর্ণ সম্পাদনা প্যাকেজকে Review-এ ফেরায়।

প্রোডাক্ট অভিপ্রায় ও পরিধি পর্যালোচনা করে। অপারেশনস পরিষ্কার এবং পুনরুদ্ধার পর্যালোচনা করে। রক্ষণাবেক্ষক diff পর্যালোচনা করেন। পরিবর্তনযোগ্য চ্যাট বার্তার প্রতিক্রিয়া কোনো রিভিশন-নির্দিষ্ট অনুমোদন নয়।

প্রকাশ করুন এবং আবার পড়ুন #

1. প্রকাশক দুই মালিকের পর্যালোচনা এবং অপরিবর্তিত উৎস-ভিত্তি যাচাই করার পর Jira-কে Publishing-এ নিন।
2. REQ-17 প্রকাশ করুন ত্রিশ দিনের মেয়াদ এবং সরবরাহ-মুলতুবি ক্ষেত্রসহ। তৈরি হওয়া সংস্করণ, পরিধি ও ব্যতিক্রম নথিভুক্ত করুন।
3. GitHub বাস্তবায়ন PR খুলুন, অনুমোদিত পেজ সংস্করণের উল্লেখসহ। কনফিগারেশন ত্রিশ দিনে বদলান এবং কর্তৃত্বহীন প্রয়োজনীয়তা-স্ন্যাপশট সংযুক্ত করুন।
4. রিপোজিটরি পর্যালোচনার পরে মার্জ করুন এবং main আবার পড়ুন। কমিটে থাকা আচরণ এবং রানটাইম আচরণ আলাদাভাবে নথিভুক্ত করুন।
5. RUN-04 প্রকাশ করুন, ID দিয়ে আবার পড়ুন এবং তৈরি হওয়া সংস্করণ নথিভুক্ত করুন। প্রকাশক প্রয়োজনীয়তার সরবরাহ-রেফারেন্স হালনাগাদ করেন।
6. Jira সম্পূর্ণ করুন শুধু তখনই, যখন সব রেকর্ড মেলে এবং চূড়ান্ত পুনঃপাঠের প্রমাণ সংযুক্ত থাকে।

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

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

আংশিক প্রকাশনা ট্র্যাক করুন #

পরের ধাপের আগে প্রতিটি ফল নথিভুক্ত করুন। PROP-042 পৃথক সিস্টেমের ঘটনাগুলোকে একসূত্রে যুক্ত করে। একটি সারি সম্পন্ন হলেই পুরো পরিবর্তন শেষ হয় না।

উদাহরণ ব্যর্থতা: Confluence ত্রিশ দিন প্রকাশ করে, কিন্তু GitHub মার্জ অনুমতি দেয় না। Jira-কে Blocked রাখুন এবং প্রয়োজনীয়তাকে সরবরাহ-মুলতুবি চিহ্নিত রাখুন। প্রোডাক্ট দল পরিবর্তন এগিয়ে নেওয়া বা পর্যালোচনার পরে সাত দিনে ফেরার সিদ্ধান্ত নেয়। জরুরি README কপিকে প্রয়োজনীয়তার কর্তৃত্বপূর্ণ উৎস করবেন না।

সমসাময়িক সম্পাদনা সামলান #

ব্রাউজার বেসলাইন: পাইলট সময়ে একজন প্রকাশক নির্ধারণ করুন। সম্পাদনার ঠিক আগে এবং প্রকাশনার পরপর Page History আবার খুলুন। অন্য কোনো লেখক উৎস বদলালে থামুন, তুলনা করুন, সমন্বয় করুন এবং অনুমোদন নবায়ন করুন। ক্রমানুসারে প্রকাশনা একটি পদ্ধতি, অ্যাটমিক লেনদেনের নিশ্চয়তা নয়।

API সম্প্রসারণ: Confluence v2 ডকুমেন্টেশনে GET /wiki/api/v2/pages/{id}?body-format=storage এবং ভার্সন অবজেক্টসহ PUT /wiki/api/v2/pages/{id} উল্লেখ আছে। পর্যালোচিত প্রকাশনা ইন্টিগ্রেশন বর্তমান সংস্করণের সঙ্গে অনুমোদিত ভিত্তি তুলনা করে, পরবর্তী সংস্করণ পাঠায় এবং পুনরায় পড়ে। ব্যর্থ সংস্করণ স্বয়ংক্রিয়ভাবে রিফ্রেশ করে পুরোনো বডি আবার পাঠাবেন না।

শুধু API সাফল্য যথেষ্ট নয়। ফলের বিষয়বস্তু, উৎস ID, পরিধি এবং সংস্করণ যাচাই করুন। এই কোর্সে লেখার ক্ষমতাসম্পন্ন API ক্লায়েন্ট নেই। নন-কোডারদের জন্য মানুষের ব্রাউজার-প্রকাশনাই কার্যকর বেসলাইন।

নেতিবাচক পরিস্থিতি যাচাই করুন #

বাস্তব sandbox ফলাফল নথিভুক্ত করুন actor-এর ভূমিকা এবং আগের ও পরের রিভিশনসহ। প্রবেশাধিকার-প্রত্যাখ্যাত ব্যবহারকারীর প্রমাণে সুরক্ষিত পেজের বডি রাখবেন না। প্রত্যাশিত ফল মাপা ফল নয়।

পর্যালোচনা প্যাকেজ তৈরি করুন #

শুধু প্রস্তাবের লেবেল নয়, কনটেন্ট স্থির করুন। PROP-042 প্রতিটি সিস্টেমে থাকে, কিন্তু লেবেল মালিক যে বডি পর্যালোচনা করেছেন তা শনাক্ত করে না। সঠিক প্রয়োজনীয়তার ভাষ্য, বাস্তবায়ন diff, রানবুকের ভাষ্য, উৎস সংস্করণ এবং প্রকাশনার ক্রম এক স্থির প্যাকেজে রাখুন।

Package: PROP-042 revision 1, illustrative
Intent: synthetic export retention changes from 7 to 30 days
Exclusions: production data, backups, legal holds
Requirement amendment: fixed proposed REQ-17 wording
Implementation: fixed candidate diff and protected base reference
Runbook amendment: fixed RUN-04 wording and recovery limits
Review: product and operations decisions for this package
Delivery: requirement -> implementation -> runbook -> closure
Stop: changed source, missing review, denied write, failed read-back

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

এই কৃত্রিম উদাহরণের পূরণ করা প্যাকেজ:

REQ-17 proposed v5: "Synthetic export files are retained for 30 days from creation. This pilot excludes production data, backups, and legal holds. Delivery remains pending until the GitHub configuration and RUN-04 read-backs match this approved wording."

GitHub config.json, proposed change against base-001:
-  "retention_days": 7
+  "retention_days": 30

RUN-04 proposed v3: "Retention days: 30. Synthetic exports only. No deletion job runs in this lab. If publication fails, keep delivery pending, read back each source, and obtain owner approval before restoring the seven-day configuration or completing the thirty-day publication."

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

অফলাইন স্ন্যাপশট এবং লাইভ প্রকাশনা আলাদা রাখুন। প্রথম লেখার ঠিক আগে প্রকাশক ম্যাপ করা পেজ আবার যাচাই করেন এবং রক্ষণাবেক্ষক সুরক্ষিত বেস আবার যাচাই করেন। কোনোটি বদলালে পুরোনো প্যাকেজ Review-এ থামে।

লেজার অনুসরণ করুন #

উদাহরণস্বরূপ অবস্থার অগ্রগতি: টেবিলটি শেখানোর জন্য রিভিশন দেখায়, পর্যবেক্ষণ নয়। প্রতিটি sandbox লেখার পরে প্রকৃত ফলের সংস্করণ ও commit পূরণ করুন।

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

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

পুরোনো সংস্করণ প্রত্যাখ্যানের উদাহরণ: প্রকাশক REQ-17 v4 পড়েন, অন্য অনুমোদিত সম্পাদক v5 প্রকাশ করেন, এরপর প্রকাশক v4-এর ওপর PROP-042 r1 প্রয়োগ করতে যান। প্ল্যাটফর্ম সংস্করণ-দ্বন্দ্ব জানায়, অথবা লেখার আগের পাঠে v5 ধরা পড়ে। actor publisher, প্রাথমিক v4, চেষ্টা করা PROP-042 r1, দেখা দ্বন্দ্ব বা বর্তমান সংস্করণের পরিবর্তন, এই চেষ্টায় অপরিবর্তিত চূড়ান্ত v5, এবং নির্ধারিত মালিক product owner নথিভুক্ত করুন। Jira Review-এ রাখুন। v5 আবার পড়ুন, ভাষ্য সমন্বয় করুন এবং পরের লেখার আগে নতুন স্থির প্যাকেজ পর্যালোচনার জন্য দিন। লাইভ পরীক্ষায় প্রকৃত প্ল্যাটফর্ম প্রতিক্রিয়া এবং Page History ব্যবহার করুন। এই সারি একটি শিক্ষামূলক উদাহরণ।

সম্পূর্ণ শিক্ষামূলক উদাহরণ, শুধু কৃত্রিম মান:

উপরের লেবেলগুলো উদাহরণ, টেন্যান্টের প্রমাণ নয়। আপনার লেজারে নেটিভ পেজ-ভার্সন লিংক এবং commit ID দরকার। Jira-কে Done করার আগে স্থির প্রস্তাব, দুই ভূমিকার পর্যালোচনা, উৎস-বেস রেকর্ড, প্রতিটি প্রকাশনার পুনঃপাঠ, নেতিবাচক পরীক্ষার ফল এবং অমীমাংসিত রানটাইম সীমা সংযুক্ত করুন। কোনো উপাদান অনুপস্থিত থাকলে সরবরাহ খোলা বা Blocked রাখুন।

প্যাকেজ গেট: পাঁচটি পরীক্ষার প্রতিটিকে Supported অথবা Blocked চিহ্নিত করুন: উৎস রিভিশন সাম্প্রতিক, উভয় মালিক একই স্থির রিভিশন অনুমোদন করেছেন, সব প্রয়োজনীয় প্রকাশনা পুনঃপাঠের সঙ্গে মেলে, রানটাইম সীমা স্পষ্ট এবং পুনরুদ্ধার অবস্থা সমন্বিত। Done-এর জন্য পাঁচটি Supported পরীক্ষা এবং কোনো অননুমোদিত লেখা না থাকা দরকার।

অনিশ্চিত লেখা সামলান #

টাইমআউটে ফলাফল অজানা থাকে। এটি সাফল্য বা ব্যর্থতা প্রমাণ করে না। ব্রাউজার বেসলাইনে পুনরায় চেষ্টা করার সিদ্ধান্তের আগে ম্যাপ করা উৎস খুলুন এবং বর্তমান বিষয়বস্তু ও ইতিহাস দেখুন।

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

পুরো ক্রম অন্ধভাবে আবার চালাবেন না। ইতিমধ্যে সম্পন্ন ধাপ পুনরাবৃত্তি করলে রিভিশন বাড়ে এবং অন্যের সম্পাদনা মুছে যাওয়ার ঝুঁকি তৈরি হয়। যাচাইকৃত অবস্থা থেকে শুরু করুন। উৎসে প্রবেশাধিকার না থাকলে পুরোনো লেজার দেখে অনুমান না করে Hold বেছে নিন।

পুনরুদ্ধার সিদ্ধান্ত তুলনা করুন #

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

প্রকাশনা সমাপ্তি যাচাই #

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

প্রত্যাশিত যুক্তি: পরের কাজ আসে সাম্প্রতিক উৎস এবং লেজার থেকে, আগের সহকারীর আত্মবিশ্বাস থেকে নয়। চূড়ান্ত ম্যাপ করা রেফারেন্স retrieval পরীক্ষায় নিন, যাতে আবিষ্কার একই কর্তৃত্ব-পার্থক্য বজায় রাখে।

সমস্যা সমাধান ও পুনরুদ্ধার #

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

পুনরুদ্ধার: Page History তুলনা এবং মালিক-পর্যালোচিত পুনরুদ্ধার বা ক্ষতিপূরণমূলক সম্পাদনা ব্যবহার করুন। পুনরুদ্ধারে নম্বরিং আগের অবস্থায় ফিরে যায় ধরে না নিয়ে ফলের সংস্করণ লিখুন। প্রোডাক্ট rollback বেছে নিলে সুরক্ষিত PR দিয়ে কনফিগারেশন ফিরিয়ে নিন। মুছে ফেলা ফাইল rollback প্রতিশ্রুতির বাইরে।

অনুশীলন ও স্ব-মূল্যায়ন #

REQ-17 প্রকাশের পরে কাজ থামান এবং অন্য প্রকাশককে শুধু ম্যাপ ও লেজার দিন।

প্রত্যাশিত যুক্তি: তারা বর্তমান উৎস আনবে, স্থির অনুমোদন নিশ্চিত করবে এবং শুধু অনুমোদিত Pending ধাপ চালাবে। প্রমাণ অনুপস্থিত থাকলে কাজ Review-এ ফিরে যায়।

প্রধান সূত্র #

• ইতিহাস ও পুনরুদ্ধার: Confluence প্রযুক্তিগত নথি .
• ভার্সনযুক্ত API কাজ: Confluence REST API v2 পেজসমূহ .
• কর্মপ্রবাহ নিয়ন্ত্রণ: Jira উন্নত কর্মপ্রবাহ .
• ইন্টিগ্রেশন নিরাপত্তা: MCP নিরাপত্তার সেরা অনুশীলন .

পরবর্তী পদক্ষেপ #

পর্যালোচিত প্রকাশনা চালানো শেষে ম্যাপ-প্রথম পুনরুদ্ধার চালিয়ে যান।