https://virgool.ir/feed/@mohammadmahyar1512fa2026-11-10 19:47:11https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@mohammadmahyar1512https://virgool.ir/@mohammadmahyar1512/چرا-هر-ادمین-جیرا-به-یک-محیط-تست-نیاز-دارد-و-چرا-داکر-ساده-ترین-راهش-است-dqj3aw7gzzprاگر جیرا (Jira) را در یک شرکت واقعی نگه می‌دارید، احتمالاً این جمله را شنیده‌اید یا خودتان گفته‌اید:«یه تغییر کوچیکه، مستقیم روی Production می‌زنم.»و احتمالاً حداقل یک بار هم از گفتن همین جمله پشیمان شده‌اید.من ادمین جیرا هستم و بخش زیادی از تجربه‌ام روی نسخه Data Center بوده. چیزی که در این چند سال یاد گرفته‌ام ساده است:بیشتر خرابی‌های جیرا از باگ نرم‌افزار نمی‌آید؛ از تغییری می‌آید که بدون تست روی محیط اصلی اعمال شده است.و تقریباً همیشه ریشه ماجرا این است که محیط تستی وجود نداشته؛ یا اگر وجود داشته، شبیه Production نبوده.این نوشته درباره همین موضوع است؛ نه درباره اینکه Docker چیست.تغییر کوچکی که واقعاً کوچک نیستسه مورد از رایج‌ترین «تغییر کوچک»هایی که می‌توانند روی محیط زنده دردسر بسازند:۱. اضافه کردن Custom Fieldاضافه کردن یک فیلد سفارشی در جیرا شاید ساده به نظر برسد، اما هر فیلد جدید می‌تواند روی جست‌وجو، ایندکس، فرم‌ها و تجربه کاربر اثر بگذارد.روی نمونه‌ای با چند صد هزار Issue، این اثر کم‌کم خودش را نشان می‌دهد. یکی‌دو فیلد مشکلی ایجاد نمی‌کند، اما وقتی تعدادشان زیاد می‌شود — و معمولاً زیاد می‌شود چون هر تیم فیلد خودش را می‌خواهد — تازه متوجه هزینه واقعی آن می‌شوید.۲. دست زدن به Workflow فعالاگر یک وضعیت را از Workflowی حذف کنید که Issue فعال دارد، ممکن است Issueها در وضعیتی گیر کنند که دیگر مسیر خروجی مشخصی ندارد.کاربر می‌گوید:«دکمه نیست.»شما می‌پرسید:«کدوم دکمه؟»و تازه متوجه می‌شوید تغییر کوچکی که روی Workflow انجام شده، مسیر کار چند تیم را بسته است.۳. ادغام یا تغییر Permission Schemeاین یکی معمولاً بی‌سروصداتر از بقیه است.نه خطایی می‌بینید، نه کسی همان لحظه متوجه می‌شود. فقط یک تیم، یک روز بعد می‌فهمد که دیگر پروژه‌اش را نمی‌بیند، یا دسترسی‌هایی که قبلاً داشته از بین رفته است.هیچ‌کدام از این‌ها الزاماً باگ نیستند. در خیلی از موارد جیرا دقیقاً همان کاری را انجام می‌دهد که به آن گفته‌اید. مشکل این است که اثر تغییر را قبل از اعمال روی محیط اصلی ندیده‌اید.چرا معمولاً محیط تست وجود ندارد؟جواب صادقانه این است: گرفتن سرور دوم از مدیر سخت است.معمولاً بحث این‌طور شروع می‌شود:«یعنی می‌خوای برای تست هم یه سرور جدا بگیریم؟»و همین‌جا مکالمه تمام می‌شود.اینجاست که داکر (Docker) می‌تواند کمک کند. نه چون جادو می‌کند، بلکه چون هزینه شروع را پایین می‌آورد.به‌جای اینکه از همان ابتدا درباره خرید یا آماده‌سازی یک سرور کامل صحبت کنید، می‌توانید از یک محیط ایزوله و سبک‌تر شروع کنید؛ محیطی که برای تست تغییرات، تمرین ارتقا، بررسی افزونه‌ها و شبیه‌سازی خطاها کافی است.این فقط یک بحث فنی نیست؛ یک بحث مذاکره است.محیط تست واقعی یعنی چه؟محیط تست واقعی فقط این نیست که جیرا بالا بیاید و صفحه Login را ببینید.حداقل چیزی که لازم دارید این سه جزء است:خود جیرادیتابیس جداReverse Proxyمورد اول واضح است.مورد دوم مهم‌تر از چیزی است که معمولاً تصور می‌شود. تست روی دیتابیس داخلی یا دیتابیس موقت، تصویر دقیقی از رفتار واقعی جیرا به شما نمی‌دهد. اگر Production شما با PostgreSQL یا دیتابیس دیگری کار می‌کند، محیط تست هم باید تا حد ممکن به همان ساختار نزدیک باشد.مورد سوم هم زیاد نادیده گرفته می‌شود: Reverse Proxy.خیلی از مشکلات واقعی جیرا فقط پشت Proxy خودش را نشان می‌دهد؛ مخصوصاً مشکلات مربوط به URL، Redirect، Base URL، SSL و لینک‌ها.اگر محیط تست شما Proxy ندارد، دقیقاً همان دسته از مشکلاتی را تست نمی‌کنید که معمولاً بیشترین دردسر را در Production ایجاد می‌کنند.اشتباهی که خیلی‌ها در اولین راه‌اندازی جیرا با داکر انجام می‌دهندمسیر نصب جیرا و JIRA_HOME دو چیز متفاوت‌اند.مسیر نصبجایی است که باینری‌ها، Java، Tomcat و فایل‌های اجرایی قرار دارند. این بخش با ارتقا یا تعویض Image می‌تواند تغییر کند.JIRA_HOMEجایی است که داده واقعی جیرا قرار دارد:AttachmentsIndexLogsPluginsConfigurationLocal dataاگر در داکر این دو را درست جدا نکنید، یا برای JIRA_HOME یک Volume مشخص نکنید، اولین باری که کانتینر را بازسازی کنید ممکن است داده‌های محیط تست را از دست بدهید.و چون «فقط محیط تست» بوده، معمولاً کسی هم برایش بکاپ نگرفته است.اگر بقیه این نوشته را فراموش کنید، همین یک نکته به‌تنهایی ارزشش را دارد:JIRA_HOME داده واقعی شماست؛ با آن مثل یک مسیر موقت رفتار نکنید.بعد از اینکه محیط تست بالا آمد، چه چیزی را باید تست کرد؟محیط تستی که هیچ‌وقت استفاده نمی‌شود، تفاوت زیادی با نداشتن محیط تست ندارد.فهرست واقعی من برای تست این‌هاست:۱. هر تغییر Schemeقبل و بعد از تغییر، تعداد Schemeها را بررسی کنید. جیرا گاهی در اثر تغییرات ساده، Schemeهای جدید می‌سازد یا وابستگی‌هایی ایجاد می‌کند که بعداً مدیریتشان سخت می‌شود.۲. هر ارتقای نسخهارتقا را یک بار کامل روی محیط تست انجام دهید. نه با داده نمونه، بلکه با داده‌ای نزدیک به واقعیت و با همان افزونه‌هایی که روی Production دارید.۳. هر Script یا Automationمخصوصاً اسکریپت‌هایی که Issue را جابه‌جا می‌کنند، فیلدی را تغییر می‌دهند، یا Transition اجرا می‌کنند. چیزی که روی ده Issue درست کار می‌کند، الزاماً روی چند هزار Issue بدون مشکل اجرا نمی‌شود.۴. بازیابی از بکاپاین مورد را جدی بگیرید. بکاپی که یک بار Restore نشده باشد، هنوز بکاپ قابل اعتماد نیست. بازیابی از بکاپ را باید روی محیط تست تمرین کنید، نه روزی که Production از دسترس خارج شده است.راهنمای عملیاگر می‌خواهید یک محیط تست برای جیرا راه‌اندازی کنید، مراحل عملی را جداگانه نوشته‌ام:نصب جیرا با داکر برای محیط تستنصب جیرا در لینوکسدر آن راهنماها درباره این موارد توضیح داده‌ام:تفکیک درست JIRA_HOMEاتصال جیرا به PostgreSQLتنظیم حافظهاستفاده از Reverse Proxyنکات اولیه برای شبیه‌تر کردن محیط تست به Productionجمع‌بندیمحیط تست برای جیرا تجمل نیست.اگر جیرا در شرکت شما ابزار اصلی مدیریت کار، پشتیبانی، توسعه یا عملیات است، محیط تست ارزان‌ترین بیمه‌ای است که می‌توانید برای آن داشته باشید.هزینه چند گیگ RAM و کمی زمان برای راه‌اندازی محیط تست را با هزینه یک روز اختلال در جیرا مقایسه کنید.تقریباً همیشه جواب واضح است.اگر بعد از راه‌اندازی محیط تست به این نتیجه رسیدید که مشکل اصلی خودِ ساختار جیراست — نه نبودِ محیط تست — آن یک بحث جداگانه است. چیزی که معمولاً پشت جملهٔ «جیرا کار نمی‌کند» پنهان شده، ساختاری است که از روز اول برای آن تیم طراحی نشده بود.دربارهٔ این موضوع جدا نوشته‌ام: پیاده‌سازی و راه‌اندازی جیرامن محمد مهیار احمدی هستم، مشاور مستقل جیرا (Jira) و کانفلوئنس. در سایت jirasupport.ir درباره پیاده‌سازی، کانفیگ، نگهداری، Automation و بهینه‌سازی جیرا و کانفلوئنس می‌نویسم.mohammadmahyar1512mohammadmahyar1512Sun, 20 Sep 2026 16:23:26 +0330