وقتی که تیم های توسعه برنامه در روند تحویل پروژه عجله دارند و بر روی سرعت انجام پروژه تاکید دارند، ممکن است که روند کار خود را با بصورت نامنظم و پیچیده پیش ببرند.

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

زمانی که اعضای تیم از GitLab Flow استفاده میکنند، از توسعه feature driven و feature branches به همراه تریس کردن issue ها برای مطمئن شدن از کارآمد بودن هر یک از اعضای تیم، بهره مند می شوند. با استفاده از یک سری نکات موجود در GitLab Flow، تیم توسعه نرم افزار میتواند در آخر پروسه و نتیجه تاثیر گذار تر و تمیز تری داشته باشد.

قواعد GitLab Flow

در ادامه به بررسی 11 قاعده اصلی و مهم GitLab Flow می پردازیم :

1. در branch اصلی به جای direct commits از feature branches استفاده کنید.

یک روش ساده و آسان برای توسعه و تمیز نگه داشتن سورس کدها، استفاده از feature branch است. اگر یک تیم از SVN یا subversion که به صورت trunk base روند توسعه ی پروژه خود را دنبال میکنند، به تازگی از svn به گیت منتقل شده باشند، هنگامی که از گیت استفاده میکنند باید یک branch برای تمام چیزهایی که قرار است روی آن ها کار شود، ایجاد شود که اعضای تیم قبل از merge کردن بتوانند به راحتی کد ها را بررسی کنند.

2. به جای یک commit در branch اصلی، تمام commit ها را چک کنید.

بعضی از توسعه دهندگان، CI یا command line هایشان را جوری تنظیم می کنند که فقط چیزهایی که در main branch، Merge شده اند تست و آزمایش شوند.

اما امروزه این کار در چرخه ی گسترش نرم افزار بی تاثیر است و تمام مدیران و توسعه دهندگان محصولات، همیشه باید از green test های main branch مطمئن باشند.همچنین تست کردن main درست قبل از شروع فرایند توسعه ی یک feature جدید، برای آنها یک کار بی اهمیت و بیهوده محسوب می شود.

3. هر تست را بر روی تمام commit ها اجرا کنید. توجه داشته باشید تست هایی که اجرای آنها بیشتر از 5 دقیقه طول میکشد را میتوان به صورت parallel (موازی)اجرا کرد.

هنگام کار کردن بر روی یک feature branch و اضافه کرن commit های جدید، باید تست ها را به صورت درست و سریع اجرا کنید. اگر اجرای تست ها زمانبر بود و اجرای آنها زمان زیادی طول کشید، میتوانید تست ها را به صورت parallel اجرا کنید.

این کار را از سمت سرور در merge request انجام دهید و مجموعه ای از تست های تکمیلی را اجرا کنید. اگر یک مجموعه کامل از تست ها جهت توسعه نرم افزار وجود داشته باشد و یک مجموعه تست دیگر فقط برای ورژن و نسخه های جدید نرم افزار و برنامه باشد، این کار ارزش آن را دارد که همه ی تست ها را به صورت parallel یا موازی اجرا نمایید.

4. قبل از merging کردن کدها به branch اصلی آنها را بررسی کنید.

باید به این اصل توجه داشته باشید که کار چک کردن پروژه را نباید برای آخر کار یا آخر هفته بگذارید چون در ابتدا توسعه دهندگان باید issue هایی را که ممکن است بعدا در چرخه روند پروژه مشکل به وجود بیاورند را شناسایی کنند. به همین دلیل بررسی کد ها باید در اسرع وقت انجام شود. چون وقتی که مشکلات زود شناسایی می شوند، زودتر و راحت تر میتوان برای آنها یک راه حل پیدا کرد.

5. عمل Deployment یا جای گذاری بصورت اتوماتیک و خودکار، بر اساس branch ها یا tag ها انجام میشود.

توسعه دهنده ها برای جلوگیری از تکرار مجدد deploy یا گسترش دادن main ها، میتوانند یک production branch ایجاد کنند. از این رو اعضای تیم جهت ایجاد production branch ، به جای استفاده از یک اسکریپت یا انجام آن بصورت دستی، میتوانند از یک اتوماسیون یا یک branch مخصوص که باعث deploy شدن تولید میشود،استفاده کنند.

6. tag ها توسط کاربر تنظیم میشوند نه توسط CI

با توجه به اینکه command line به جای تغییر دادن مخزن ، کارهای دیگری انجام میدهد توسعه دهندگان از tags استفاده میکنند.

اگر تیم ها به معیار های مفصل و کاملتری نیاز داشته باشند، باید یک ورژن جدید از server report detailing نیز داشته باشند.

7. انتشارات بر پایه tag ها هستند.

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

8.Pushed commit ها از نو پایه گذاری نمیشوند.

وقتی که به یک branch عمومی فشار وارد میشود، توسعه دهندگان نباید آن را از نو و یک بار پایه گذاری کنند چون این کار باعث سخت و دشوار شدن کار شناسایی بهبود ها و نتیجه تست ها، در زمان استفاده از دستور cherry picking میشود.

در برخی مواقع میتوان squash و پایه گذاری مجدد را جهت آسان سازی عمل بازگردانی در پایان بررسی کد نادیده گرفت.

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

9.همه از main شروع میکنند و آن را هدف اصلی خود قرار میدهند.

قرار دادن main به عنوان هدف اصلی ، از به وجود آمدن branch های طولانی جلوگیری میکند. توسعه دهندگان ابتدا main را چک و بررسی میکنند سپس یک feature می سازند و در آخر یک merge request ایجاد می کنند که دوباره main را هدف قرار دهد. توسعه دهندگان قبل از merging کردن و از بین بردن هر کدام از مراحل ، باید یکبار دیگر همه چیز را به طور دقیق بررسی کنند.

10.قبل از پایه گذاری branch ها اول باید باگ و خطاهای موجود در main رفع شوند.

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

برای جلوگیری از آن، توسعه دهندگان همیشه باید با فشار و انتقال دادن آن تغییر به main، آن را حل و درست کنند، سپس آن را به یک patch-release Branch دیگر cherry-pick کند.

11.منعکس کننده معانی پیام های commit

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

یا حتی می توانند توضیح بدهند که چرا این آپشن از بین بقیه گزینه ها برای کمک به همکاران آینده انتخاب شده تا روند و پروسه ی توسعه را بهتر درک کنند.

نوشتن پیام های commit به صورت تشریحی ، برای بررسی کد ها و توسعه آن در آینده بسیار مفید است.

چه شیوه و تکنیک هایی باعث توسعه بهتر نرم افزارها میشوند؟

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