یک تجربه: تاثیر Git در بهبود فرایند تضمین کیفیت

ضمن تشکر از آقای مهندس پیشوایی، تجربه ارزشمند ایشان در مهاجرت از SVN به Git را در ادامه با شما به اشتراک می‌گذاریم.

گیت (Git) یک سیستم مدیریت نسخه (Version Control System) توزیع شده است که در سال 2005 به وسیله تیم توسعه کرنل لینوکس به وجود آمد. این فناوری با وجود جوانی توانسته با سرعت چشمگیری جای خود در صنعت نرم افزار باز کند. بر اساس گزارشی از Infoworld در سال 2014 حدودا 70 درصد از برنامه نویسان جاوا از Git استفاده می‌کنند.

نباید به Git (و فناوریهای مشابه آن) صرفاً به چشم ابزاری نگاه کرد که با دستوراتی متفاوت همان کارهای CVS یا SVN را کمی سریعتر و بهتر انجام می دهد. بلکه باید به این فناوری‌ها به چشم پیشران‌هایی (Enablers) نگریست که می‌توانند فرایندهای سازمانی را بهبود بدهند. برای به کارگیری هر فناوری باید دستاوردها، ملزومات، تبعات و به روش‌های (Best Practices) آن را شناسایی نمود.

ما در شرکت اعوان تصمیم به مهاجرت از SVN به Git گرفتیم. برای این منظور پژوهش‌های چند جانبه‌ای صورت گرفت. از جمله با پیشنهادات متعددی در مورد شکل دادن فرایند توسعه بر اساس امکانات Git مواجه شدیم. از جمله معروف‌ترین پیشنهادات، فرایند پیشنهادی Vincent Driessen با عنوان A successful Git branching model است که البته انتقادات متعددی نیز به آن وارد شده است.

نهایتاً ما از بین گزینه های مختلف Gitlab را به عنوان سرور Git برگزیدیم و فرایند کاری تیم خود را نیز با الهام از فرایند پیشنهادی Gitlab به نام Gitlab Flow بنا کردیم. این فرایند و ابزار جدید به ما کمک کرد Code Review را به یک مرحله اصلی و غیر قابل حذف از فرایند پیاده‌سازی تبدیل کنیم.

[در پرانتز خوب است اشاره کنم DZone اخیراً نتایج یک نظرسنجی را منتشر کرد که در آن بیشتر شرکت‌ کنندگان Code Review را به عنوان مهم‌ترین عامل افزایش کیفیت مطرح کرده بودند و حتی اهمیت آن را از تست، تحلیل دقیق و یکپارچگی مستمر نیز بالاتر دانسته اند. مطالعه این گزارش خالی از لطف نیست.]

به طور خلاصه در این فرایند روی هر Repository یک یا چند نفر اصلی به عنوان Master و بقیه افراد به عنوان Developer تعریف می شوند. Developer ها نمی‌توانند روی branch‌های اصلی سرور فایل ارسال کنند. بنابراین هر کار جدیدی که بخواهند انجام بدهند باید یک شاخه (branch) جدید بسازند. پس از آنکه کارشان تمام شد روی Gitlab اقدام به ثبت Merge Request می‌کنند. Gitlab امکانی ایجاد می‌کند که Master بتواند فایل‌هایی را که Developer تغییر داده ببیند و کدهایش را بازبینی کند. اگر کد قابل تایید نباشد Master روی هر یک از خطوط کد که بخواهد یادداشت می‌گذارد و آن را به Developer برمی‌گرداند و در غیر اینصورت Merge Request را تایید می‌کند تا روی شاخه اصلی قرار بگیرد.