یکی از سوالات مهمی که هر مهندس نرم‌افزاری لازم دارد تا به آن پاسخ دهد این است که «چه زمانی تغییرات جدید منتشر خواهند شد؟». البته دانستن پاسخ این سوال تنها با مسئول توسعهٔ نرم‌افزار (دولوپر) نیست. رهبر تیم لازم است که بداند چه زمانی آمادهٔ رفتن به مرحلهٔ بعدی هستند. مدیر پروژه نیز لازم است از این موضوع مطلع باشد تا بتواند برای اطلاع‌رسانی در خصوص ویژگی‌های جدید برنامه‌ریزی کند. جدای از این توسعه‌دهندهٔ‌ نرم‌افزار برای دریافت بازخورد کار‌های انجام شده لحظه شماری می‌کند. به طور کلی می‌توان پاسخ این سوال را یک تلاش تیمی دانست. در دنیای دواپس (DevOps)، تغییرات جدید چند مرحله در روز با برنچ master ترکیب (Merge) می‌شوند، ولی دانستن این که تغییرات جدید چه زمانی آماده می‌شوند چندان آسان نیست. توسعه‌دهندگان کنترل کامل انتشار تغییراتشان برای کاربران نهایی را در دست دارند، همین امر نیز اهمیت قابلیت پیگیری تغییرات (Tracking) را دو چندان می‌کند. از این طریق است که تیم‌های IT و عملیات (Operation) می‌توانند در زمان رویداد‌های غیرمنتظره دقیقا مشخص کنند که کدام تغییرات در به وجود آمدن مشکلات تأثیر‌گذار بوده‌اند. خبر خوب این است که بخش عمده‌ای از این روند می‌تواند توسط نرم‌افزار‌های Jira و یا Jira Service Desk و به روش خودکار انجام شود. در ادامه ۶ قدم مفید برای بهره گیری از پلتفورم جیرا در جهت مدیریت بهتر انتشار‌های نرم‌افزار را با هم مرور می‌کنیم. ۱) با استفاده از مسائل (Issues) جیرا‌، تغییرات را مشخص کنید تعریف یک تغییر چیست؟ آیا می‌توان یک کامیت (Commit) را تغییر دانست؟ یا هر تغییر می‌تواند شامل چند کامیت مجزا باشد؟ عموما پیاده‌سازی یک تغییر قابل انتشار شامل چند کامیت مجزا می‌باشد. یکی از پر استفاده‌ترین روش‌های مدیریت تغییرات در نرم‌افزار‌های مدیریت نسخه (Version Control) ساخت برنچ‌ ویژگی‌های جدید است. وقتی که کار بر روی آن‌ها به اتمام رسید نیز مجموعهٔ تغییرات ثبت شده در برنچ با استفاده از یک درخواست بررسی (Pull Request) با برنچ Master ترکیب می‌شوند. یک درخواست بررسی تعریف دقیق‌تری از یک واحد از تغییرات ارائه می‌کند. با این حال معمولا تغییرات کوچک اما مهم دیگری نیز لازم است تا بعد از ثبت درخواست بررسی بر روی برنچ اعمال شوند. برای مثال، ممکن است رنگ یک جزء از رابط کاربری نیاز به تغییر داشته باشد و یا جمله‌بندی یک بخش از رابط بتواند با کمی تغییر بهتر شود. در چنین شرایطی ممکن است شما چند «درخواست بررسی» داشته باشید که نهایتا یک تغییر منطقی را شامل می‌شوند. به جای ترکیب تمام این درخواست‌ها با یکدیگر‌، شاید بهتر باشد که تمامی آن‌ها را به عنوان یک واحد از تغییرات و در کنار هم ثبت کنید. اینجاست که سیستم مسائل جیرا وارد می‌شود. جیرا نه تنها روند کارهای شما را تعقیب می‌کند‌، بلکه می‌تواند اشخاص مرتبط با موضوع را از ثبت تغییرات جدید مطلع سازد. هر شخصی در سازمان شما می‌تواند مسائل جیرا را زیر نظر (Watch) داشته باشد تا از ثبت دیدگاه‌های جدید و یا تغییر در روند انجام آن‌ها بلافاصله مطلع گردد. ۲) روند کاری (Workflow) انتشار نرم‌افزارتان را در جیرا تعریف کنید به طور پیش‌فرض‌، روند‌های کاری مرتبط با مدیریت انتشار نرم‌افزار در جیرا پیاده‌سازی نشده‌اند. اما از آن‌جایی که پلتفورم جیرا قابلیت انعطاف‌پذیری بالایی دارد‌، کاربران را قادر می‌سازد تا حالت‌های (Status) بیشتری را برای پیگیری وضعیت انتشار نرم‌افزار تعریف کند. روند کاری پیش‌فرض جیرا به صورت زیر شامل سه وضعیت می‌باشد: حالا بیایید چند وضعیت جدید به این ترکیب اضافه کنیم. برای پوشش مسئلهٔ پیش روی ما‌، لازم است به جای انتقال بلافاصله از حالت «در حال انجام» (In Progress) به وضعیت «انجام شده» (Done) وضعیت‌های زیر نیز تعریف شوند: در حال انتظار برای انتشار (Awaiting Release): به این معناست که کار مربوطه به صورت کامل انجام شده و حالا آمادهٔ انتشار است. منتشر شده برای تست (Released to Staging): مشخص می‌کند که روند انتشار برای محیط تست به صورت کامل انجام شده است. منتشر شده برای محیط اصلی (Release to Production): هورا! تغییرات جدید به دست کاربر نهایی رسیده است. در تصویر زیر نمایی از چگونگی افزودن این وضعیت‌ها روی روند‌کاری پایهٔ جیرا را مشاهده می‌کنید. برای راهنمایی بیشتر در این خصوص می‌توانید با تیم پشتیبانی پارس‌دانی‌سان تماس حاصل فرمایید: ۳) برد‌های چابک (Agile) را تنظیم کنید وقتی که روند‌کاری جدیدتان را پیاده‌سازی کردید‌، به بخش تنظیمات پروژه‌های مورد نظرتان وارد شوید و روند کاری جدید را برای آن‌ها فعال کنید. اگر توسعه‌دهندگان‌تان از برد‌ها استفاده می‌کنند‌، وضعیت‌های جدید را به برد‌هایشان اضافه کنید. یک  راه آسان برای انجام این کار این است که به صفحهٔ تنظیمات برد وارد شده و روی بخش ستون‌ها (Columns) کلیک کنید. در این‌جا می‌توانید وضعیت‌های جدید را بکشید و در ستون Done رها کنید: حالا، هر زمانی که توسعه‌دهنده‌ای بخواهد کارت مسئله‌ای را از برد «در حال انجام» به «انجام شده» منتقل کند‌، با پیغامی روبرو خواهند شد که از آن‌ها می‌خواهد وضعیت درست را در این خصوص مشخص کند. این‌جاست که می‌توانند وضعیت انتشار یک ویژگی را مشخص کنند:‌ ۴) مسائل جیرا را با انتشار‌ها مرتبط کنید با فرض بر این که انتشار‌ها از طریق یک مخزن گیت (Git Repository) انجام می‌گیرند‌، می‌توانیم از تاریخچهٔ کامیت‌ها به منظور اطمینان یافتن از انتشار تغییرات درست بهره بگیریم. برای این کار‌، لازم است که بتوانیم کامیت‌ها را به مسئلهٔ مربوطه در جیرا متصل کنیم، تا بتوانیم بفهمیم که کدام تغییر با کدام مسئله در ارتباط است. یک راه برای دستیابی به این منظور‌، افزودن کلید مسئلهٔ‌ جیرا (Issue Key) به اول پیغام ثبت شده به همراه کامیت است: git commit -am ‘PROJ-255: change publish button colour to blue’ ممکن است بگویید که این کار مقداری سربار اضافه به روند توسعه اعمال می‌کند‌، اما مرتبط کردن مسئله با هر کامیت یک Best Practice محسوب می‌شود، چرا که قابلیت ردگیری درست و آسان تغییرات را فراهم می‌کند. راه حل جایگزین دیگر این است که کلید مسئله را در نام برنچ شامل تغییرات وارد کنید که روند مرتبط سازی کلید و کامیت مربوطه را در آینده آسان‌تر می‌کند. نکته: اگر با استفاده از جیرا برنچ خود را ایجاد کنید‌، به صورت خودکار نام مسئله برای برنچ جدید انتخاب می‌شود. ۵) تمامی تغییرات مرتبط برای انتشار بعدی را پیدا کنید حالا به مهم‌ترین مرحله از […]