preloder
یک تجربه

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

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


گیت (Git) یک سیستم مدیریت نسخه (Version Control System) توزیع شده است که در سال ۲۰۰۵ به وسیله تیم توسعه کرنل لینوکس به وجود آمد. این فناوری با وجود جوانی توانسته با سرعت چشمگیری جای خود در صنعت نرم افزار باز کند. بر اساس گزارشی از Infoworld در سال ۲۰۱۴ حدودا ۷۰ درصد از برنامه نویسان جاوا از 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 را تایید می‌کند تا روی شاخه اصلی قرار بگیرد.
 

[تعداد: 0    میانگین: 0/5]
برچسب ها
نمایش بیشتر

نوشته های مشابه

‫۷ نظرها

  1. سلام خسته نباشید،
    اگر ممکنه یه آموزش کامل و جامع فارسی برای گیت و کار با اون بهم معرفی بکنید(اگر فیلم باشه که چه بهتر)

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

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

    ارادتمند.

  4. چه قدر هندونه زیر بغل همدیگه میگذارید و در نوشابه برای همدیگه باز می‌کنید! تازه این گزارش که حرف خاصی برای گفتن نداشت. یه کم بیشتر به محتوای سایتتون برسید

    1. جناب ناشناس, اگر تجربه و “حرف خاصی” دارید برای جاواکاپ بفرستید تا آن را برای مخاطبان منتشر کنیم و برای شما هم نوشابه باز کنیم!
      نظر شما محترم است.

پاسخی بگذارید

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

دکمه بازگشت به بالا