پیکربندی های گردش کار را پیکربندی کنید

در حالی که این صفحه در مورد Triggers برای کلیه محصولات JIRA اعمال می شود ، محرک ها برای همکاری نزدیک با ابزارهای توسعه طراحی شده اند و در هنگام استفاده از نرم افزار JIRA قدرتمندترین آنها هستند.

محرک ها ابزاری قدرتمند برای نگه داشتن مسائل JIRA شما با اطلاعات موجود در ابزارهای توسعه شما (Fisheye/Crucible ، Bitbucket Cloud و GitHub) هستند. به جای تکیه بر توسعه دهندگان برای به روزرسانی دستی وضعیت مسائل پس از تعهد کد ، تکمیل بررسی ها ، ایجاد شاخه ها و غیره ، می توانید محرک ها را در گردش کار خود پیکربندی کنید تا در صورت بروز این رویدادها در ابزارهای توسعه شما ، به طور خودکار مسائل را انتقال دهند. به عنوان مثال ، شما می توانید یک ماشه را پیکربندی کنید تا هنگام ایجاد یک شاخه ، به طور خودکار یک مسئله را از "انجام" به "در حال انجام" منتقل کنید.

این صفحه به شما کمک می کند تا با استفاده از محرک ها شروع به کار کنید. ما به شما نشان خواهیم داد که چگونه می توانید محرک ها را در یک گردش کار تنظیم کنید و نحوه انتقال خودکار را نشان دهید. ما همچنین راهنمایی هایی در مورد نحوه پیکربندی بهترین یک ماشه ارائه خواهیم داد و به شما در عیب یابی محرک های خود کمک می کند.

قبل از اینکه شروع کنی

در حال حاضر ، شما نمی توانید محرک های گردش کار را برای پروژه های مدیریت شده تیمی پیکربندی کنید. دستورالعمل های موجود در این صفحه فقط در مورد پروژه های مدیریت شده شرکت اعمال می شود.

قبل از شروع استفاده از محرک ها ، باید ابزارهای توسعه خود را به JIRA وصل کنید. حداقل حداقل به یکی از موارد زیر نیاز خواهید داشت:

• ابر بیتباکت
• GitHub (با استفاده از برنامه)
• Bitbucket Server (همه نسخه های فعلی)
• Fisheye/Crucible (همه نسخه های فعلی)
• Github Enterprise 11. 10. 290 (یا بعد)

برای راهنمایی در مورد نحوه اتصال این ابزارها به JIRA ، به ادغام با ابزارهای توسعه مراجعه کنید. این صفحه همچنین شامل جزئیات مربوط به عملکرد بهبود یافته با اتصال ابزارهای توسعه اطلس است.

راهنما: تنظیم محرک ها

در این مثال ، شما یک گردش کار JIRA را با محرک ها پیکربندی می کنید. در پایان این بخش ، شما می توانید درک کنید که چگونه می توانید محرک ها را پیکربندی کنید و یک گردش کار معمولی با محرک ها به نظر می رسد.

معرفی

تصویر زیر و جدول زیر یک گردش کار را نشان می دهد و محرک های مشابه آنچه پیکربندی می کنید. آنها تعامل معمولی بین JIRA و ابزارهای توسعه را در یک چرخه توسعه نرم افزار منعکس می کنند. برای این مثال از نرم افزار JIRA ، Server Bitbucket و Fisheye/Crucible (3. 5. 2) استفاده می شود ، اما می توانید با استفاده از هر یک از ابزارهای توسعه پشتیبانی شده ، چیزی مشابه را پیکربندی کنید.

پیشرفت را شروع کنید (انتقال یک مسئله از انجام → در حال انجام)

شعبه ایجاد شده (سرور Bitbucket) Commit Created (Bitbucket Server)

بررسی را شروع کنید (انتقال یک مسئله از Progress → در بررسی)

درخواست کشش ایجاد شده (سرور Bitbucket) درخواست بازگرداندن مجدد ((سرور Bitbucket) آغاز شده (Crucible)

راه اندازی مجدد پیشرفت (انتقال یک مسئله از بررسی → در حال انجام)

درخواست کشش کاهش یافته (سرور Bitbucket) بررسی رد شده (Crucible) بررسی رها شده (Crucible)

انجام شده (انتقال یک موضوع از بررسی → انجام شده)

بررسی درخواست ادغام شده (سرور Bitbucket) بررسی بسته (Crucible)

مرحله 1. ایجاد/ویرایش یک گردش کار

ساده ترین راه برای ایجاد گردش کار توسعه نرم افزار ، ایجاد یک پروژه جدید ، انتخاب یک نوع پروژه مربوطه است. این پروژه جدید شما را با گردش کار توسعه نرم افزار تنظیم می کند ، که یکسان با آنچه در بالا نشان داده شده است.

اگر از قبل گردش کار مشابهی دارید ، به آن بروید و آن را ویرایش کنید:

مرحله 2. یک ماشه را به یک انتقال اضافه کنید

ما با اضافه کردن یک "تعهد ایجاد شده" شروع به انتقال "شروع پیشرفت" خواهیم کرد. اطمینان حاصل کنید که گردش کار را ویرایش می کنید (مشاهده نمی کنید).

1. در حالت نمودار ، شروع شروع پیشرفت را در گردش کار انتخاب کنید (خط از "برای انجام" به "در حال پیشرفت"). پانل نمایش جزئیات انتقال را نشان می دهد.
2. روی پانل روی Triggers کلیک کنید. صفحه نمایش "Transition: Start Progress" نشان می دهد که برگه "محرک ها" را نشان می دهد.
3. روی Add Trigger کلیک کنید ، سپس تعهد ایجاد شده در گفتگوی ظاهر شده را انتخاب کنید. یک پنجره Diagnostics نمایش می دهد. متوجه خواهید شد که ماشه برای کلیه ابزارهای توسعه ای که جیرا به آن متصل است اضافه می شود.
4. برای افزودن ماشه ، روی Add Trigger کلیک کنید. در لیستی در پایین برگه "محرک ها" ظاهر می شود. می توانید با کلیک روی جزئیات مشاهده ، بررسی کنید.

خودشه! فراموش نکنید که پیش نویس گردش کار خود را منتشر کنید.

مرحله 3. ماشه را آزمایش کنید

اکنون که شما "تعهد ایجاد شده" را به انتقال "شروع پیشرفت" اضافه کرده اید ، بیایید با انجام تعهد آن را آزمایش کنیم.

1. در پروژه JIRA خود مسئله ای ایجاد کنید. این پروژه باید از گردش کاری که تازه ویرایش کرده اید استفاده کند. وضعیت مسئله جدید شما باید "انجام" باشد. به کلید مسئله توجه داشته باشید ، زیرا برای مرحله بعدی به آن احتیاج دارید.
2. مقداری کد را به مخزن ابر Bitbucket خود مرتکب شوید. شما می توانید هر چیزی را مرتکب شوید ، با این وجود باید کلید مسئله را در پیام تعهد خود درج کنید. در این مثال ، کلید مسئله TIS-1 است که در پیام تعهد نشان داده شده در تصویر ارجاع شده است.

3. دوباره مسئله خود را در جیرا بررسی کنید. وضعیت از "برای انجام" به "در حال انجام" تغییر یافت. اگر روی برگه تاریخچه یا برگه فعالیت کلیک کنید ، می توانید انتقال خودکار را که وضعیت مسئله را تغییر داده است مشاهده کنید.

مرحله 4. بقیه محرک ها را اضافه کنید

اکنون که یک ماشه را اضافه کرده و آزمایش کرده اید ، همان فرآیند را دنبال کنید تا بقیه محرک ها را در لیست بالا اضافه کنید.

تبریک! شما یک گردش کار با محرک ها تنظیم کرده اید.

اگر در پیکربندی ماشه خود یا کار کردن با آن مشکلی دارید ، بخش عیب یابی را در زیر بررسی کنید.

اگر می خواهید در مورد نحوه عملکرد محرک ها اطلاعات بیشتری کسب کنید ، به بخش درک محرک های زیر مراجعه کنید.

درک محرک ها

مباحث زیر توضیح می دهد که چگونه محرک ها با جزئیات بیشتری کار می کنند ، بنابراین می توانید از آنها به طور مؤثر استفاده کنید.

وقایع را تحریک کنید

رویدادها (به عنوان مثال تعهد ایجاد شده) با ادغام JIRA با ابزارهای توسعه خاص به طور مستقیم یا با یک برنامه ، برای محرک ها در دسترس هستند. در جدول زیر رویدادهایی که برای هر ابزار توسعه فعال شده است ، لیست شده است.

Bitbucket ، GitHub Enterprise ، GitHub (برنامه)

مصلوب

فیش

• درخواست PULL ایجاد شده
• درخواست ادغام شده
• درخواست کشش کاهش یافته (فقط Bitbucket)
• درخواست بازگشایی شده (فقط سرور Bitbucket)
• تعهد ایجاد شده
• شاخه ایجاد شده

• بررسی آغاز شد
• ارسال شده برای تأیید
• بررسی رد شد
• بررسی رها شده
• بررسی بسته شد
• بررسی خلاصه

• تعهد ایجاد شده
• شاخه ایجاد شده

محرک ها و انتقال جهانی

ما توصیه می کنیم که محرک های انتقال جهانی را پیکربندی نکنید ، مگر اینکه اطمینان داشته باشید که دقیقاً می دانید که ماشه چگونه بر رفتار مسئله تأثیر می گذارد.

یک انتقال جهانی به هر وضعیتی در یک گردش کار اجازه می دهد تا به یک وضعیت خاص منتقل شود. این در بیننده/ویرایشگر گردش کار توسط یک سیاه و سفید با اشاره به وضعیتی که انتقال جهانی را هدف قرار می دهد ، نشان داده شده است. برای اطلاعات بیشتر در مورد انتقال جهانی ، به پیکربندی گردش کار پیشرفته مراجعه کنید.

پیکربندی محرک های انتقال جهانی اغلب می تواند منجر به انتقال غیر منتظره به وضعیت هدف برای انتقال جهانی شود. به عنوان مثال ، در نظر بگیرید که آیا "تعهد ایجاد شده" را برای انتقال جهانی به وضعیت "در حال پیشرفت" پیکربندی کرده اید. تعهد کد می تواند در بسیاری از مراحل در طول چرخه عمر یک شماره (به عنوان مثال نوشتن کد اولیه ، تغییر کد پس از بررسی و غیره) اتفاق بیفتد. این می تواند منجر به انتقال نادرست به "در حال پیشرفت" از تعدادی از وضعیت ها شود ، مانند "در بررسی" یا "انجام شده".

اگر از انتقال جهانی در گردش کار خود استفاده کنید ، احتمالاً چندین انتقال به وضعیت خواهید داشت. این بدان معناست که کاربران گزینه های مختلف گردش کار را در مورد یک مسئله (به عنوان مثال "پیشرفت شروع" و "در حال پیشرفت") خواهند داشت. برای مخفی کردن گزینه ها ، شرایط "مخفی کردن از کاربر" را به انتقال مربوطه اضافه کنید.

مراجعه به مسئله JIRA در یک تعهد ، شعبه ، درخواست کشش یا بررسی

در جدول زیر نحوه مراجعه به موضوع JIRA در یک تعهد ، شعبه ، درخواست کشش یا بررسی توضیح داده شده است تا این وقایع باعث انتقال برای این مسئله شود (مشروط بر اینکه شما محرک های انتقال را تنظیم کرده اید).

ایجاد تعهد

کلید مسئله را در پیام تعهد درج کنید.

به عنوان مثال ، یک پیام متعهد مانند این "تعهد اولیه TIS-1" به طور خودکار مسئله TIS-1 را از "برای انجام" به "در حال انجام" منتقل می کند.

شاخه ایجاد کنید

هنگام ایجاد شاخه ، کلید شماره را در نام شعبه وارد کنید.

به عنوان مثال ، اگر شاخه خود را "TIS-2-Peature" نامگذاری کنید ، به طور خودکار مسئله TIS-2 را از "برای انجام" به "در حال انجام" منتقل می کند.

ایجاد/بازگشایی/کاهش درخواست ادغام

اطمینان حاصل کنید که درخواست کشش شامل تعهداتی است که موضوع را مرجع می کند (در پیام های تعهد خود).

به عنوان مثال ، اگر یک درخواست کشش ایجاد کنید که دارای عنوان "TIS-3" باشد ، به طور خودکار شماره "TIS-3" را از "در حال انجام" به "در بررسی" منتقل می کند. اگر مجدداً درخواست کشش را بازگشایی ، کاهش یا ادغام کنید ، مسئله "TIS-3" را بر این اساس نیز انتقال می دهد.

شروع/رد/رها کردن/نزدیک بررسی

هنگام ایجاد بررسی ، کلید شماره را در عنوان بررسی قرار دهید.

به عنوان مثال ، اگر بررسی خود را "داستان جدید TIS-4" نامگذاری کرده و بررسی را شروع کنید ، به طور خودکار شماره TIS-4 را از "در حال انجام" به "در بررسی" منتقل می کند. اگر بررسی را رد ، رها یا بسته کنید ، بر این اساس مسئله "TIS-4" را نیز انتقال می دهد.

نقشه برداری کاربر از ابزارهای توسعه به JIRA

فرایند زیر نحوه نقشه برداری یک کاربر ابزار توسعه به کاربر JIRA برای محرک های گردش کار را شرح می دهد. این در مورد همه رویدادها صدق می کند ، اما هر ابزار توسعه از آدرس ایمیل و نام کاربری متفاوتی برای نقشه برداری استفاده می کند (به دنبال توضیحات فرآیند زیر به نقطه گلوله مراجعه کنید).

• فرآیند: کاربر که این رویداد را در ابزار توسعه آغاز می کند با تطبیق آدرس ایمیل به کاربر JIRA نقشه برداری می شود ، سپس نام کاربری ، یعنی.
  • کاربر تک جیرا با آدرس ایمیل تطبیق یافته - مسئله را به عنوان کاربر JIRA انتقال دهید.
  • هیچ کاربر JIRA با آدرس ایمیل تطبیق یافته - مسئله را به عنوان یک کاربر ناشناس انتقال دهید. وقتی نمی توانیم کاربر را با ماشه مطابقت دهیم ، مسئله را با یک کاربر ناشناس جابجا می کنیم. این بدان معنا نیست که کاربران ناشناس با دسترسی به سایت JIRA شما وجود دارند.
  • چندین کاربر با آدرس ایمیل تطبیق در JIRA - سعی کنید نام کاربری مطابق با آن گروه از کاربران را پیدا کنید. اگر یک کاربر JIRA با نام کاربری تطبیق وجود دارد ، مسئله را به عنوان کاربر JIRA انتقال دهید. اگر نام کاربری تطبیق وجود ندارد ، مسئله را به عنوان یک کاربر ناشناس انتقال دهید.

  سرور Bitbucket

  آدرس ایمیل و نام کاربری مورد استفاده برای نقشه برداری کاربر

  آدرس ایمیل و نام کاربری مورد استفاده برای نقشه برداری کاربر برای Server Bitbucket 7. 14+ در صورت استفاده از OAUTH

  همه رویدادهای درخواست PULL

  آدرس ایمیل سرور Bitbucket و نام کاربری کاربر که درخواست کشش را انجام داده است.

  آدرس ایمیل سرور Bitbucket و نام کاربری کاربر که درخواست کشش را انجام داده است.

  کاربر Bitbucket باید حداقل با آدرس ایمیل پیکربندی شده در نمایه خود ، حداقل یک مرتبه انجام دهد. در غیر این صورت ، درخواست کشش را نمی توان برای کاربر JIRA نقشه برداری کرد. این بدان معنی است که مسئله به عنوان یک کاربر ناشناس منتقل می شود.

  آدرس ایمیل مرتبط با تعهد و نام کاربری سرور Bitbucket که آدرس ایمیل به آن نقشه می کند. اگر آدرس ایمیل به نام کاربری نقشه نکند ، از نویسندگان "نام" از این تعهد استفاده می شود.

  آدرس ایمیل مرتبط با تعهد و نام کاربری سرور Bitbucket که آدرس ایمیل به آن نقشه می کند. اگر آدرس ایمیل به نام کاربری نقشه نکند ، مسئله به عنوان یک کاربر ناشناس منتقل می شود.

  آدرس ایمیل سرور Bitbucket و نام کاربری کاربر معتبر که شعبه را به سرور Bitbucket سوق داده است.

  آدرس ایمیل مرتبط با کاربر سرور Bitbucket که آخرین تعهد را در شعبه انجام داده است. اگر آدرس ایمیل به کاربر JIRA نقشه نکشید ، مسئله به عنوان یک کاربر ناشناس منتقل می شود.

  fisheye/crucible

  آدرس ایمیل و نام کاربری مورد استفاده برای نقشه برداری کاربر

  آدرس ایمیل مرتبط با تعهد و نام کاربری Fisheye که آدرس ایمیل به آن نقشه می کند. اگر آدرس ایمیل به نام کاربری نقشه نکند ، از نویسندگان "نام" از این تعهد استفاده می شود.

  این رویداد برای کاربر JIRA نقشه برداری نمی شود. این بدان معنی است که مسئله به عنوان یک کاربر ناشناس منتقل می شود.

  همه رویدادهای مرور

  آدرس ایمیل Crucible و نام کاربری کاربر معتبر که این بررسی را انجام داده است.

  ابر بیتباکت

  آدرس ایمیل و نام کاربری مورد استفاده برای نقشه برداری کاربر

  همه رویدادهای درخواست PULL

  آدرس ایمیل Bitbucket و نام کاربری کاربر که درخواست کشش را انجام داده است. توجه داشته باشید ، کاربر Bitbucket باید حداقل یک تعهد (با آن آدرس ایمیل پیکربندی شده برای مشخصات آنها) انجام دهد ، در غیر این صورت درخواست کشش نمی تواند برای کاربر JIRA نقشه برداری شود. این بدان معنی است که مسئله به عنوان یک کاربر ناشناس منتقل می شود.

  آدرس ایمیل مرتبط با تعهد و نام کاربری Bitbucket که آدرس ایمیل به آن نقشه می کند. اگر آدرس ایمیل به نام کاربری نقشه نکند ، از نویسندگان "نام" از این تعهد استفاده می شود.

  این رویداد برای کاربر JIRA نقشه برداری نمی شود. این بدان معنی است که مسئله به عنوان یک کاربر ناشناس منتقل می شود.

  GitHub / GitHub Enterprise

  آدرس ایمیل و نام کاربری مورد استفاده برای نقشه برداری کاربر

  درخواست PULL ایجاد شده / درخواست را ادغام کنید

  آدرس ایمیل GitHub و نام کاربری کاربر که درخواست کشش را انجام داده است. توجه داشته باشید ، کاربر GitHub باید حداقل یک تعهد (با آن آدرس ایمیل پیکربندی شده برای نمایه خود) انجام دهد ، در غیر این صورت درخواست کشش نمی تواند برای کاربر JIRA نقشه برداری شود. این بدان معنی است که مسئله به عنوان یک کاربر ناشناس منتقل می شود.

  آدرس ایمیل مرتبط با تعهد و نام کاربری GitHub که آدرس ایمیل به آن نقشه می کند. اگر آدرس ایمیل به نام کاربری نقشه نکند ، از نویسندگان "نام" از این تعهد استفاده می شود.

  آدرس ایمیل مرتبط با کاربر سرور Bitbucket که آخرین تعهد را در شعبه انجام داده است. اگر آدرس ایمیل به کاربر JIRA نقشه نکشید ، مسئله به عنوان یک کاربر ناشناس منتقل می شود.

  رسیدگی به رویداد و محدودیت رویداد

  در بیشتر موارد ، پردازش وقایع از ابزارهای توسعه شما به انتقال خودکار مسئله باید یکپارچه باشد. با این حال ، گاهی اوقات ممکن است تأخیرهایی در انتقال مسائل وجود داشته باشد یا به دلیل نحوه برخورد با وقایع یا محدودیت رویداد ، به هیچ وجه در حال انتقال یا موضوعاتی نیست.

  • رسیدگی به رویداد - بسته به اینکه آیا ابزار توسعه از طریق اتصال DVCS یا پیوند برنامه به JIRA متصل می شود ، رویدادها متفاوت انجام می شوند. این می تواند تأثیر بگذارد که وقایع به تأخیر بیفتند یا از بین بروند در صورت عدم دسترسی JIRA:

  Bitbucket Cloud و GitHub Enterprise

  رویدادهای Bitbucket Cloud و GitHub Enterprise از طریق اتصال DVCS در JIRA پردازش می شوند. اتصال DVCS رویدادها را از Bitbucket Cloud و GitHub Enterprise از طریق دو مکانیسم هماهنگ سازی: یک هماهنگ سازی با وب سایت و یک همگام سازی برنامه ریزی شده پردازش می کند.

  • هماهنگ سازی WebHook: اتصال DVCS از Webhooks در Bitbucket و GitHub Enterprise برای ارسال داده ها در هنگام وقوع یک رویداد استفاده می کند. این مکانیسم استاندارد برای پردازش رویدادها است ، به این معنی که تقریباً بلافاصله پس از یک رویداد Cloud/GitHub Bitbucket باید به طور خودکار به طور خودکار منتقل شود.
  • هماهنگ سازی برنامه ریزی شده: اگر هنگام وقوع یک رویداد Bitbucket Cloud/GitHub Enterprise ، با JIRA تماس نگیرد ، این رویداد توسط کانکتور DVCS ذخیره می شود و در هماهنگ سازی برنامه ریزی بعدی (هر 60 دقیقه به طور پیش فرض) ارسال می شود. این یک مکانیسم پشتیبان گیری در صورت عدم موفقیت هماهنگ سازی وب سایت است.

  سرور Bitbucket و Fisheye/Crucible

  رویدادهای سرور Bitbucket و Fisheye/Crucible از طریق لینک برنامه پردازش می شوند. با این حال ، سرور Bitbucket و Fisheye/Crucible وظیفه اطمینان از ارسال وقایع را بر عهده دارند و آنها را در زمان وقوع این رویداد یک بار ارسال می کنند. این بدان معنی است که اگر JIRA هنگام ارسال رویدادها در دسترس نباشد ، وقایع از بین می روند.

  • محدودیت های رویداد - محدودیت های رویداد بر روی همه ابزارهای توسعه اعمال می شود تا JIRA با رویدادهای بیش از حد بیش از حد بارگیری نشود. هر رویدادی که پس از فراتر از حد رویداد ارسال شده است از بین می رود. محدودیت رویداد برای هر ابزار توسعه در زیر ذکر شده است:

  Bitbucket Cloud و GitHub Enterprise

  • هماهنگ سازی ناشی از وب: 10 شاخه ؛100 تعهد
  • هماهنگ سازی برنامه ریزی شده: 600 شاخه (فاصله همگام سازی در دقیقه x 10) ؛6000 تعهد (فاصله همگام سازی در دقیقه x 100) محدودیت رویداد برای همگام سازی های برنامه ریزی شده می تواند کمتر از 600 شاخه و 6000 تعهد باشد ، در صورت کاهش فاصله همگام سازی ، اما هرگز بیشتر نیست.

  سرور Bitbucket

  10 شاخه ؛100 تعهد در هر هماهنگ سازی محدودیت دیگری که در بالای 10 شعبه اعمال می شود و 100 تعهد محدودیت 100000 مسئله تغییر یافته است. به عنوان مثال ، اگر 100 مرجع بیش از 1000 کلید شماره را انجام دهد ، از حد تغییر موضوع فراتر می رود.

  fisheye/crucible

  6000 رویداد در هر هماهنگ سازی

  چگونه محرک ها با سایر عملیات/محدودیت های گردش کار ارتباط دارند

  هنگامی که یک انتقال به طور خودکار انجام می شود ، هرگونه شرایط ، اعتبار سنجی یا مجوزهای پیکربندی شده در انتقال را نادیده می گیرد.

  با این حال ، توابع پست هنوز اجرا می شوند. شما باید مراقب باشید که اگر عملکرد پست شما به کاربر نیاز دارد ، انتقال شما توسط یک کاربر ناشناس اجرا نمی شود (به بخش نقشه برداری کاربر در بالا مراجعه کنید).

  عیب یابی

  اگر در تنظیم یک ماشه یا فعال کردن یک ماشه مشکل دارید، مراحل زیر را برای عیب یابی مشکل خود دنبال کنید.

  1. از تشخیص ماشه استفاده کنید

  اولین قدم شما در عیب یابی یک ماشه بررسی عیب یابی آن در Jira است. تشخیص می تواند به شما بگوید که آیا مشکلی در اتصال به ابزارهای توسعه شما وجود دارد یا اینکه آیا مشکلی به طور خودکار همانطور که انتظار می رفت تغییر نکرده است.

  1. Navigate to the Jira administration console> Issues> Workflows>گردش کار خود را پیدا کنید و روی View (ستون عملیات) کلیک کنید
  2. در حالت متن (و نه حالت نمودار)، روی انتقال مورد نظر کلیک کنید.
  3. در صفحه انتقال (برگه Triggers نشان داده خواهد شد)، برای نشان دادن اطلاعات عیب یابی، روی مشاهده جزئیات برای محرک مورد نظر کلیک کنید.
     • بخش "منابع محرک" مشکلات مربوط به ادغام بین Jira و ابزارهای توسعه شما را فهرست می کند. به عنوان مثال، اینکه آیا نوع صحیح احراز هویت را پیکربندی کرده اید یا خیر.
     • بخش «شکست های انتقال» مشکلاتی را فهرست می کند که علی رغم شلیک ماشه در انتقال خودکار شکست خورده اند. به عنوان مثال، یک کاربر ناشناس به انتقال نگاشت شده است، اما انتقال دارای یک تابع پست است که به یک کاربر غیر ناشناس نیاز دارد.

  2. مشکلات رایج را بررسی کنید

  اگر نمی توانید مشکل خود را با اطلاعات مربوط به عیب یابی ماشه حل کنید، فهرست مشکلات رایج زیر را برای دلایل و راه حل های احتمالی بررسی کنید.

  من نمی توانم یک ماشه به یک انتقال اضافه کنم:

  علل احتمالی.

  Jira یا ابزارهای توسعه شما نسخه صحیحی نیستند

  نصب/ارتقا به نسخه صحیحشما باید Jira 6. 3. 3+ و یکی از ابزارهای توسعه زیر را برای فعال کردن محرک های گردش کار داشته باشید: Bitbucket Server ( Bitbucket Server 3. 2. 0+)، Fisheye/Crucible 3. 5. 2+، Bitbucket، GitHub Enterprise

  ابزارهای توسعه شما به درستی به Jira متصل نیستند

  پیکربندی اتصال خود را بررسی کنید:

  • Jira + Bitbucket Server/Fisheye/Crucible: باید یک پیوند برنامه دو طرفه را با استفاده از Oauth با 2LO و 3LO پیکربندی کنید.
  • Jira + Bitbucket Cloud/GitHub Enterprise: باید کانکتور DVCS را به درستی پیکربندی کنید.
  • Jira + Bitbucket Cloud/Github: بررسی کنید که برنامه Github به درستی نصب شده باشد.

  ماشه ای که می خواهید اضافه کنید قبلاً به انتقال اضافه شده است

  همه محرک ها در هر انتقال منحصربه فرد هستند، یعنی فقط یک بار می توانید یک ماشه به یک انتقال اضافه کنید.

  موضوع تغییر نمی کند:

  علل احتمالی.

  پروژه شما از گردش کاری که با تریگرها پیکربندی شده است استفاده نمی کند

  Navigate to your project's summary> Administration>گردش کار، و بررسی کنید که پروژه شما از گردش کاری که با تریگرها پیکربندی کرده اید استفاده می کند.

  شما در جایی که محرک ها اضافه شده اند ، تغییرات گردش کار خود را ذخیره نکرده اید

  به گردش کار که به محرک اضافه شده اید بروید. بررسی کنید که با مشاهده انتقال گردش کار و تأیید حضور محرک های شما منتشر شده است.

  توسط DVC های شما نمی توان به جیرا رسید

  یک ساعت صبر کنیداگر هنوز نمی توان بعد از یک ساعت به آن رسید ، بررسی کنید که اتصال به DVC های شما به درستی پیکربندی شده است ، به ادغام با ابزارهای توسعه مراجعه کنید.

  اگر محرک ها پیکربندی نشده باشند یا JIRA از Bitbucket Cloud/GitHub Enterprise قابل دسترسی نباشد ، ممکن است تاخیر تا یک ساعت باشد ، زیرا هنوز هم هماهنگ ساعتی از تعهدات/شاخه ها/درخواست های کشش بدون در نظر گرفتن پیکربندی Triggers وجود دارد. برای اطلاعات بیشتر ، به بخش رسیدگی به رویداد و محدوده رویداد در بالا مراجعه کنید.

  مخزن DVCS شما به حساب DVCS هماهنگ مرتبط نیست

  Navigate to the Jira administration console> Add-ons>حساب های DVCS و مخزن خود را فعال کنید.

  اگر شما Bitbucket Cloud یا GitHub Enterprise را برای AutoLink مخازن جدید پیکربندی نکرده اید ، ممکن است مخازن داشته باشید که فعال نیستند (یعنی به حساب DVC خود مرتبط هستند). این بدان معناست که وقایع موجود در مخزن نامشخص به JIRA ارسال نمی شود ، از این رو مسئله به طور خودکار انتقال نمی یابد ، حتی اگر یک ماشه را پیکربندی کرده باشید.

  تعهدات شما خیلی قدیمی است

  فقط مرتکب کمتر از 21 روزه می شود ، باعث انتقال خواهد شد. این برای جلوگیری از بارگذاری فله از ایجاد انتقال فله است.

  این عمل برای کاربران ناشناس مجاز نیست

  بررسی کنید که هر کاربر در ابزارهای توسعه شما به کاربر JIRA نقشه می کند.

  برخی از عملیات مسئله هنگامی که انتقال توسط یک کاربر ناشناس انجام می شود ، استثنائاتی را به وجود می آورد. اینها هستند:

  • رویداد CreatiSsue (این احتمالاً مربوط به انتقال "ایجاد" یا "ایجاد مسئله" در گردش کار شما است)
  • توابع ارسال شده که یک کاربر را فرض می کند ، انتقال را انجام می دهد

  در صورتی که این رویداد در ابزار توسعه نمی تواند برای کاربر JIRA نقشه برداری شود ، یک انتقال تحریک شده توسط یک کاربر ناشناس انجام می شود. برای اطلاعات بیشتر ، به بخش نقشه برداری کاربر در بالا مراجعه کنید.

  حداکثر تعداد انتقال خودکار مجاز برای یک مسئله از آن فراتر رفته است

  بررسی کنید که انتقال گردش کار شما به یک حلقه نامحدود پایان نمی یابد.

  رویدادهای انتقال خودکار مسئله به اشتباه توسط ابزار توسعه سرکوب می شوند

  تنظیمات مخزن/پروژه را تغییر دهید تا امکان ارسال رویدادها فراهم شود.

  در صورت ارسال رویدادهای کپی ، مخازن Bitbucket Server (Bitbucket Server 3. 3 - 3. 5) یا Fisheye (3. 5+) را پیکربندی کرده اید. رویدادهای مخزن تکراری ممکن است هنگامی که همان مخزن را که توسط ابزارهای توسعه چندگانه نمایه شده است ، به جیرا ارسال شود. توجه داشته باشید ، JIRA هنگام پردازش محرک های گردش کار ، به طور خودکار رویدادهای تعهد تکراری (JIRA 6. 3. 3+) و رویدادهای ایجاد شعبه (JIRA 6. 3. 11+) را حذف می کند.

  شما نباید رویدادهای مخزن را از سرور Bitbucket یا Fisheye سرکوب کنید ، مگر اینکه رویدادهای تکراری باعث ایجاد نادرست مشکلات شوند.

  مسئله انتقال می یابد اما همانطور که انتظار می رود:

  علل احتمالی.

  شما یک ماشه را در یک انتقال جهانی پیکربندی کرده اید

  بررسی کنید که چگونه رویداد ماشه بر موضوعات موجود در وضعیت های مختلف تأثیر می گذارد. در نظر بگیرید که ماشه را از انتقال جهانی حذف کنید.

  ما توصیه می کنیم که محرک های انتقال جهانی را پیکربندی نکنید ، مگر اینکه اطمینان داشته باشید که دقیقاً می دانید که ماشه چگونه بر رفتار مسئله تأثیر می گذارد. برای اطلاعات بیشتر به محرک ها و انتقال های جهانی در بالا مراجعه کنید.

  شرایط گردش کار ، اعتبار سنج ها و مجوزها عمداً برای انتقال خودکار مسئله نادیده گرفته می شوند

  اگر انتظار داشتید که شرایط گردش کار ، اعتبار سنج ها یا مجوزها برای انتقال خودکار به کار گرفته شود ، لطفاً توجه داشته باشید که هیچ یک از این موارد صدق نمی کند. مربوط به این ، توابع پست در مورد انتقال خودکار مسئله اعمال می شود.

  گردش کار شما در چندین پروژه به اشتراک گذاشته می شود

  اگر می خواهید محرک هایی برای برخی از پروژه ها اعمال کنند ، اما نه برخی دیگر ، ممکن است نیاز به کپی کردن گردش کار خود داشته باشید.

  محرک ها به گردش کار اعمال می شوند. اگر یک گردش کار در چندین پروژه به اشتراک گذاشته شود ، شامل کلیه محرک هایی است که برای آن پیکربندی شده اند.

  کپی کردن وقایع انتقال خودکار مسئله توسط ابزارهای توسعه چندگانه ارسال می شود

  تنظیمات مخزن/پروژه را در یک (یا بیشتر) ابزارهای توسعه خود تغییر دهید تا از ارسال وقایع جلوگیری کنید.

  رویدادهای مخزن تکراری ممکن است هنگامی که همان مخزن را که توسط ابزارهای توسعه چندگانه نمایه شده است ، به جیرا ارسال شود. JIRA به طور خودکار رویدادهای تعهد تکراری (JIRA 6. 3. 3 و بعد از آن) و رویدادهای ایجاد شعبه (JIRA 6. 3. 11 و بعد) را حذف می کند.

  اگر از آخرین نسخه JIRA استفاده نمی کنید و رویدادهای مخزن کپی را ایجاد می کنید که باعث انتقال نادرست می شود ، می توانید سرور Bitbucket (Bitbucket Server 3. 3 - 3. 5) و مخزن Fisheye (3. 5+) را برای سرکوب رویدادهای ارسال شده به JIRA برای محرک های گردش کار پیکربندی کنید.

  اطلاعات ثبت شده برای انتقال صحیح نیست:

  علل احتمالی.

  کاربران در ابزارهای توسعه شما برای کاربران در JIRA نقشه نمی کنند

  بررسی کنید که هر کاربر در ابزارهای توسعه شما به کاربر JIRA نقشه می کند.

  اگر کاربران به درستی نقشه برداری نشوند ، کاربر برای انتقال مسئله ناشناس خواهد بود. برای اطلاعات بیشتر ، به بخش نقشه برداری کاربر در بالا مراجعه کنید.

  مسئله شناخته شده: کاربر صحیح فقط در برگه های "تاریخ" و "فعالیت" برای مسائل در جیرا و در ایمیل های اعلان نشان داده شده است. در سایر اعلان ها (به عنوان مثال برگه "انتقال" برای مسائل) یک کاربر ناشناس نشان داده شده است.

  این یک مسئله شناخته شده است که در نسخه آینده برطرف خواهد شد.

  3. کمک بگیرید

  اگر هنوز نمی توانید مشکل خود را برطرف کنید ، تعدادی از منابع کمکی دیگر در دسترس است ، از جمله انجمن های برنامه های ما ، جامعه اطلس و تیم پشتیبانی ما.

  هنگامی که یک انتقال به طور خودکار انجام می شود ، هرگونه شرایط ، اعتبار سنجی یا مجوزهای پیکربندی شده در انتقال را نادیده می گیرد.

  با این حال ، توابع پست هنوز اجرا می شوند. شما باید مراقب باشید که اگر عملکرد پست شما به کاربر نیاز دارد ، انتقال شما توسط یک کاربر ناشناس اجرا نمی شود (به بخش نقشه برداری کاربر در بالا مراجعه کنید).