شش قدم تا مدیریت موفق‌تر انتشار نرم‌افزار با جیرا

یکی از سوالات مهمی که هر مهندس نرم‌افزاری لازم دارد تا به آن پاسخ دهد این است که «چه زمانی تغییرات جدید منتشر خواهند شد؟». البته دانستن پاسخ این سوال تنها با مسئول توسعهٔ نرم‌افزار (دولوپر) نیست. رهبر تیم لازم است که بداند چه زمانی آمادهٔ رفتن به مرحلهٔ بعدی هستند. مدیر پروژه نیز لازم است از این موضوع مطلع باشد تا بتواند برای اطلاع‌رسانی در خصوص ویژگی‌های جدید برنامه‌ریزی کند. جدای از این توسعه‌دهندهٔ‌ نرم‌افزار برای دریافت بازخورد کار‌های انجام شده لحظه شماری می‌کند. به طور کلی می‌توان پاسخ این سوال را یک تلاش تیمی دانست.

در دنیای دواپس (DevOps)، تغییرات جدید چند مرحله در روز با برنچ master ترکیب (Merge) می‌شوند، ولی دانستن این که تغییرات جدید چه زمانی آماده می‌شوند چندان آسان نیست. توسعه‌دهندگان کنترل کامل انتشار تغییراتشان برای کاربران نهایی را در دست دارند، همین امر نیز اهمیت قابلیت پیگیری تغییرات (Tracking) را دو چندان می‌کند. از این طریق است که تیم‌های IT و عملیات (Operation) می‌توانند در زمان رویداد‌های غیرمنتظره دقیقا مشخص کنند که کدام تغییرات در به وجود آمدن مشکلات تأثیر‌گذار بوده‌اند.

خبر خوب این است که بخش عمده‌ای از این روند می‌تواند توسط نرم‌افزار‌های Jira و یا Jira Service Desk و به روش خودکار انجام شود. در ادامه ۶ قدم مفید برای بهره گیری از پلتفورم جیرا در جهت مدیریت بهتر انتشار‌های نرم‌افزار را با هم مرور می‌کنیم.

۱) با استفاده از مسائل (Issues) جیرا‌، تغییرات را مشخص کنید

تعریف یک تغییر چیست؟ آیا می‌توان یک کامیت (Commit) را تغییر دانست؟ یا هر تغییر می‌تواند شامل چند کامیت مجزا باشد؟ عموما پیاده‌سازی یک تغییر قابل انتشار شامل چند کامیت مجزا می‌باشد.

یکی از پر استفاده‌ترین روش‌های مدیریت تغییرات در نرم‌افزار‌های مدیریت نسخه (Version Control) ساخت برنچ‌ ویژگی‌های جدید است. وقتی که کار بر روی آن‌ها به اتمام رسید نیز مجموعهٔ تغییرات ثبت شده در برنچ با استفاده از یک درخواست بررسی (Pull Request) با برنچ Master ترکیب می‌شوند. یک درخواست بررسی تعریف دقیق‌تری از یک واحد از تغییرات ارائه می‌کند. با این حال معمولا تغییرات کوچک اما مهم دیگری نیز لازم است تا بعد از ثبت درخواست بررسی بر روی برنچ اعمال شوند. برای مثال، ممکن است رنگ یک جزء از رابط کاربری نیاز به تغییر داشته باشد و یا جمله‌بندی یک بخش از رابط بتواند با کمی تغییر بهتر شود.

در چنین شرایطی ممکن است شما چند «درخواست بررسی» داشته باشید که نهایتا یک تغییر منطقی را شامل می‌شوند.

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

۲) روند کاری (Workflow) انتشار نرم‌افزارتان را در جیرا تعریف کنید

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

Screen-Shot-2016-05-04-at-11.06.50-AM

حالا بیایید چند وضعیت جدید به این ترکیب اضافه کنیم. برای پوشش مسئلهٔ پیش روی ما‌، لازم است به جای انتقال بلافاصله از حالت «در حال انجام» (In Progress) به وضعیت «انجام شده» (Done) وضعیت‌های زیر نیز تعریف شوند:

  • در حال انتظار برای انتشار (Awaiting Release): به این معناست که کار مربوطه به صورت کامل انجام شده و حالا آمادهٔ انتشار است.
  • منتشر شده برای تست (Released to Staging): مشخص می‌کند که روند انتشار برای محیط تست به صورت کامل انجام شده است.
  • منتشر شده برای محیط اصلی (Release to Production): هورا! تغییرات جدید به دست کاربر نهایی رسیده است.

در تصویر زیر نمایی از چگونگی افزودن این وضعیت‌ها روی روند‌کاری پایهٔ جیرا را مشاهده می‌کنید. برای راهنمایی بیشتر در این خصوص می‌توانید با تیم پشتیبانی پارس‌دانی‌سان تماس حاصل فرمایید:

jira_workflow_for_release_visibility-copy-600x361
۳) برد‌های چابک (Agile) را تنظیم کنید

وقتی که روند‌کاری جدیدتان را پیاده‌سازی کردید‌، به بخش تنظیمات پروژه‌های مورد نظرتان وارد شوید و روند کاری جدید را برای آن‌ها فعال کنید. اگر توسعه‌دهندگان‌تان از برد‌ها استفاده می‌کنند‌، وضعیت‌های جدید را به برد‌هایشان اضافه کنید. یک  راه آسان برای انجام این کار این است که به صفحهٔ تنظیمات برد وارد شده و روی بخش ستون‌ها (Columns) کلیک کنید. در این‌جا می‌توانید وضعیت‌های جدید را بکشید و در ستون Done رها کنید:

rapbidboard_columns-600x225

حالا، هر زمانی که توسعه‌دهنده‌ای بخواهد کارت مسئله‌ای را از برد «در حال انجام» به «انجام شده» منتقل کند‌، با پیغامی روبرو خواهند شد که از آن‌ها می‌خواهد وضعیت درست را در این خصوص مشخص کند. این‌جاست که می‌توانند وضعیت انتشار یک ویژگی را مشخص کنند:‌

rapidboard_drag-600x142

۴) مسائل جیرا را با انتشار‌ها مرتبط کنید

با فرض بر این که انتشار‌ها از طریق یک مخزن گیت (Git Repository) انجام می‌گیرند‌، می‌توانیم از تاریخچهٔ کامیت‌ها به منظور اطمینان یافتن از انتشار تغییرات درست بهره بگیریم. برای این کار‌، لازم است که بتوانیم کامیت‌ها را به مسئلهٔ مربوطه در جیرا متصل کنیم، تا بتوانیم بفهمیم که کدام تغییر با کدام مسئله در ارتباط است. یک راه برای دستیابی به این منظور‌، افزودن کلید مسئلهٔ‌ جیرا (Issue Key) به اول پیغام ثبت شده به همراه کامیت است:
git commit -am 'PROJ-255: change publish button colour to blue'

ممکن است بگویید که این کار مقداری سربار اضافه به روند توسعه اعمال می‌کند‌، اما مرتبط کردن مسئله با هر کامیت یک Best Practice محسوب می‌شود، چرا که قابلیت ردگیری درست و آسان تغییرات را فراهم می‌کند. راه حل جایگزین دیگر این است که کلید مسئله را در نام برنچ شامل تغییرات وارد کنید که روند مرتبط سازی کلید و کامیت مربوطه را در آینده آسان‌تر می‌کند.

نکته: اگر با استفاده از جیرا برنچ خود را ایجاد کنید‌، به صورت خودکار نام مسئله برای برنچ جدید انتخاب می‌شود.

۵) تمامی تغییرات مرتبط برای انتشار بعدی را پیدا کنید

حالا به مهم‌ترین مرحله از موارد ذکر شده می‌رسیم. با استفاده از این روش می‌توانید مشخص کنید که کدام تغییرات می‌توانند در انتشار جدید لحاظ شوند. بعد از ساخت یک انتشار جدید‌، کامیت مربوطه را با استفاده از یک شمارهٔ نسخه تگ کنید. در ادامه نمونه دستوری را که می‌توانید به این منظور به اسکریپت ساخت‌تان (Build Script) اضافه کنید را مشاهده می‌کنید:

git tag -s -a 6.0.0-OD-2016.12.1-1106 && git push $remote 6.0.0-OD-2016.12.1-1106

سپس می‌توانیم از گیت برای دریافت تمامی کامیت‌های ثبت شده پس از انتشار قبلی استفاده کنیم. از تاریخچهٔ گیت به طریق زیر تمامی کامیت‌هایی که کلید مسائل مورد نظر ما را در خود دارند لیست می‌کنیم:

git log 6.0.0-OD-2016.11.1-1091..6.0.0-OD-2016.12.1-1106 --pretty=oneline | perl -ne '{ /(\w+)-(\d+)/ && print "$1-$2\n" }' | sort | uniq
CONF-38645
CONF-40446
CONF-40973
CONF-41003
CONF-41014
CONF-41035

و به همین راحتی لیستی از مسائلی که می‌توانید به انتشار جدید اضافه کنید را خواهید داشت. با کمی تغییرات این خروجی می‌تواند به یک اسکریپت JQL تبدیل شود و به سرور جیرا ارسال شود:

issue in ('CONF-41003', 'CONF-40973', 'CONF-38645', 'CONF-40446', 'CONF-41014', 'CONF-41035') and status = 'AWAITING RELEASE'

برخی از این کامیت‌ها ممکن است تغییرات جزئی را شامل شوند‌، و ممکن است بخواهید آن‌ها را از نتیجهٔ این اسکریپت خارج کنید تا وضعیت‌شان به «در انتظار انتشار» تغییر نکند. پس از دریافت لیست‌، تمامی مسائلی که با انتشار پیش‌رو منتشر خواهند شد را با یک شمارهٔ ورژن جدید به روز کنید. این کار می‌تواند به صورت دستی و با استفاده از قابلیت «به روزرسانی دسته‌ای» (Bulk Update) جیرا انجام گیرد و یا به عنوان بخشی از اسکریپت ساخت پروژه و به صورت خودکار انجام گیرد. بستهٔ پایتون جیرا ابزار مناسبی برای تعامل با REST API جیراست که می‌تواند در این خصوص کمک کننده باشد.

۶) منتشر کنید و  افراد تیم را مطلع سازید

شما آمادهٔ انتشار نسخهٔ جدید هستید‌، حالا چه کار می‌توانید بکنید؟ الان وقت انتشار نسخه‌، به روزرسانی مسئلهٔ مربوطه در جیرا و خبررسانی به تیم است. در زمان انتشار لازم است که شماره نسخه و محیط هدف را بدانید، تا بتوانید وضعیت درست را از میان «انتشار برای تست» و «انتشار برای محیط اصلی» انتخاب کنید.

وقتی انتشار با موفقیت به پایان رسید‌، مسائلی را که در این انتشار وجود داشتند را با استفاده از JQL پیدا کنید (می‌توانید این کار را در زمان ساخت، و یا بخشی از یک پروسهٔ دستی انجام دهید):

fixVersion = '6.0.0-OD-2016.12.1-1106'

با استفاده از قابلیت به روزرسانی دسته‌ای یا REST API، وضعیت این مسائل را به وضعیت انتشار متناسب تغییر دهید. زمانی که این مسائل به روزرسانی شدند‌، توسعه دهندگان مرتبط با مسئله و دیگر افرادی از تیم که مسئله را زیر نظر دارند، پیغامی شامل وضعیت نهایی انتشار را دریافت می‌کنند.

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

منبع: Six steps to better release management in Jira software

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

شما می‌توانید از این دستورات HTML استفاده کنید: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>