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

این چرخه عمر توسعه نرم افزار (SDLC) در هر شرکتی متفاوت است.

سیستم کنترل نسخه مورد استفاده، بررسی همتایان process، بررسی کد process، بررسی طراحی process، روش انجام CI، تست خودکار و تست دستی – همه بسیار متفاوت است بسته به روی کجاکارمیکنی.

روش برنامه‌ریزی، نوشتن، ساخت، بررسی، استقرار و انتشار نرم‌افزار یک شرکت برای موارد خاص آن‌ها بهینه‌سازی می‌شود، همه این‌ها با در نظر گرفتن نقاط قوت و معایب خاص خود.

شروع کردم به خواندن در مورد اینکه چگونه شرکت های بزرگ فناوری چرخه عمر توسعه نرم افزار خود را اجرا می کنند (SDLC) و این اصطلاح را شنید تنه–توسعه مبتنی بر چند بار این روشی است که گوگل از آن پیروی می کند و من کنجکاو بودم که تفاوت آن با روشی که اکثر شرکت های دیگر نرم افزار تولید می کنند چیست.

دو روش مختلف برای انجام انشعاب

انتشار شعبه

دو رویکرد متداول برای فعال کردن چندین توسعه دهنده برای کار وجود دارد روی یک پایگاه کد

اولین موردی که ما به آن اشاره خواهیم کرد رهایی شاخه روش. اسمش را هم دیده ام انشعاب ویژگی. اما هر دوی این رویکردهای یکسان از یک الگوی کلی پیروی می کنند.

معمولاً از طریق Git، توسعه‌دهندگان همگی پایگاه کد را شبیه‌سازی می‌کنند (بنابراین همه آنها کپی‌های یکسانی داشته باشند. روی ماشین های آنها). سپس آنها یک شاخه ویژگی/ انتشار جدید ایجاد می کنند روی main، و با تکمیل کار ادغام شوند. تاکید در اینجا این است که آنها فقط یک بار ادغام می شوند، در پایان، زمانی که همه کارها کامل شد – و آنها را ادغام می کنند. کل شاخه به main.

در اینجا مروری بر روش استفاده توسعه دهندگان از آن است رهایی شاخه روش:

نقاط سفید نشان دهنده ارتکاب هستند و خط سیاه و سفید یکدست پایینی نشان دهنده تعهد است main. این یک مثال بسیار ساده است، همانطور که شاخه ها را آزاد کنید اغلب با تعهدات بسیار بیشتر از آنچه در نمودار نشان داده ام (گاهی اوقات صدها) به پایان می رسند.

توسعه دهندگان منشعب می شوند main، تغییرات آنها را انجام دهید، و پس از تکمیل یا تصویب کد QA، دوباره در ادغام می شود main. یعنی رها کردن شاخه.

توسعه مبتنی بر تنه (TBD)

تیرنک-بآسید Dتوسعه (TBD) رویکرد دوم است. در اینجا، هر توسعه‌دهنده کاری را که انجام خواهد داد به دسته‌های کوچک تقسیم می‌کند و در آنها ادغام می‌شود main (که اغلب به آن اشاره می شود تنه) چندین بار.

در تیم های کوچک معمولاً شاخه ای ایجاد نمی کنند و شاخه را در تنه ادغام می کنند. آنها متعهد می شوند به طور مستقیم به صندوق عقب بدون شاخه

در یک تیم بزرگتر (با بررسی ها و تاییدیه های لازم برای MR) استفاده می کنند کوتاه مدت شاخه ها. یکی شاخه رهاسازی با 100 commit در TBD 10 درخواست ادغام با هر 10 commit خواهد بود.

در TBD، تغییرات کد آنها معمولاً بیش از چند ساعت باقی نمی ماند. آنها دائماً با کدهایی که دیگران می نویسند ادغام و یکپارچه می شوند.

Jez Humble یک مهندس قابلیت اطمینان سایت در گوگل و نویسنده کتاب تحویل مداوم است که می گوید “مشکل شعبه نیست، مشکل ادغام است” – این دقیقاً همان چیزی است که TBD سعی می کند حل کند

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

آیا TBD در مقیاس کار می کند؟

در یک گفتگوی گوگل، ریچل پوتوین، که یک مدیر مهندسی در گوگل است، یک پایگاه کد را توضیح داد که (از ژانویه 2015):

• 1 میلیارد فایل
• 2 میلیارد خط کد
• 86 ترابایت محتوا
• 45000 تعهد در روز کاری
• 15 میلیون خط در 250000 فایل در هفته تغییر می کند

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

گوگل همچنین دارای کد QA بسیار دقیق و دقیق است process (در مورد آن اینجا بخوانید) که هنگام استفاده از TBD، امکان تحویل سریع و کارآمد نرم افزار را فراهم می کند.

TBD همچنین برای متدولوژی های Agile که در آن باید نرم افزار را به طور مکرر برای دریافت بازخورد از مصرف کنندگان/مشتریان خود ارسال کنید، به خوبی کار می کند. شما می توانید به طور مداوم یکپارچه شوید و یک عکس فوری از وضعیت فعلی خود دریافت کنید.

اجازه دهید به طور خلاصه در مورد برخی از TBD بحث کنیم نقاط قوت.

نقاط قوت TBD

• با ادغام روزانه، بازخورد (چه از طریق کد QA یا بررسی همتایان) به سرعت می‌آید. این می تواند شما را از انجام کار اشتباه به مدت 3 هفته باز دارد، و سپس بازخورد دریافت کنید که کار شما در نهایت درست نیست، و باعث شود ضرب الاجل ها را از دست بدهید.
• یک مزیت ذهنی برای TBD وجود دارد، جایی که توسعه دهندگان احساس می کنند مانند تنه هستند است ما کد، به جای اینکه هرکسی شاخه های ویژگی خود را داشته باشد و فکر کند این شاخه است من کد این می تواند فرهنگ مشارکتی بیشتری را تقویت کند و ارتباطات را افزایش دهد.
• این منجر به یکپارچگی زودهنگام با سایر پروژه‌ها/بلیت‌های حین پرواز می‌شود و به شما کمک می‌کند استفاده مجدد از کد را ترویج دهید. “استفاده از کد” که با آن ادغام نشده است بسیار سخت تر است main و شما نمی دانید چه زمانی کامل می شود. همچنین هنگامی که شاخه انتشار 9 ماهه شما باید دوباره در صندوق عقب ادغام شود، جهنم ادغام را متوقف می کند.
• پروژه‌های بزرگ با کار زیاد مجبور می‌شوند به موارد تحویلی کوچک‌تر تقسیم شوند. این برای تخمین جدول زمانی و همچنین برای تقسیم کد شما به قطعات مدولار بسیار بهتر است.
• زمانی که بسیاری از توسعه دهندگان به صورت مجزا کار می کنند روی با انتشار شاخه‌ها، تشخیص توسعه‌دهندگان جوانی که در شعبه خود با مشکل مواجه هستند، دشوارتر است. اما اگر از آن‌ها انتظار می‌رود که کار خود را روزانه انجام دهند، می‌توانید برون‌داد روزانه آنها را نظارت کنید و در صورت لزوم به آنها کمک کنید.
• TBD واقعاً به خوبی با یکپارچگی مداوم ارتباط دارد. با تعداد زیادی تعهدات کوچک و افزایشی به یک پروژه نهایی نهایی، یک پایگاه کد همیشه آزمایش شده و همیشه یکپارچه با ادغام های وحشتناک (حداقل) دریافت می کنید.

نقاط ضعف TBD

• یکی از چالش های این رویکرد این است که شما شانس بیشتری برای شکستن تنه و جلوگیری از کار کردن افراد زیادی دارید. شما باید مطمئن شوید که commit های شما تست های واحد را همراه با یک بررسی کد خوب اجرا می کنند process بنابراین زمان بازگرداندن commit های تمام روز را از دست ندهید.
• سابقه تعهد شما به main احتمالاً پرمخاطب‌تر خواهد بود و تشخیص اینکه آیا چیزی اشتباه است یا نه، دشوارتر است. اگر ساعت 3 صبح با شما تماس گرفته شود و از شما خواسته شود که یک اشکال را برطرف کنید روی سایت پرود شما با چند ارتکاب اشتباه که رفت روی در ساعات کاری، روزی با 1 کامیت را ترجیح می دهید یا 200 کامیت؟
• اگر ساخت سریع ندارید process، در حالی که تیم شما دائماً متعهد می شود، مدت زیادی را منتظر خواهید بود تا چیزهایی ساخته شوند.
• اغلب اوقات با TBD شما به صورت تدریجی کد جدیدی اضافه می کنید تا کاری جدید انجام دهید، اما همچنین به مسیرهای “قدیمی” که جایگزین می کنید نیاز دارید تا همچنان کار کنند. به همین دلیل باید تکیه کنید روی تغییر ویژگی (معمولاً از یک پایگاه داده) برای تغییر همه چیز روی و خاموش. این می تواند سطح بیشتری از پیچیدگی را با اشکال زدایی اضافه کند.
• یک چالش نهایی می تواند این باشد که وقتی تعهدات دائمی دارید، دائماً در حالت سرگردانی هستید. شما باید مطمئن شوید که تیم شما مرتباً از صندوق عقب بیرون می‌آید و در حین ادغام چیزها روی یکدیگر زمین نمی‌خورد.

روش انتشار نرم افزار با توسعه مبتنی بر Trunk

تیم هایی که از TBD استفاده می کنند معمولا نسخه متفاوتی خواهند داشت process نسبت به تیمی که از شاخه های ویژگی استفاده می کند.

به طور کلی، اگر از شاخه های انتشار استفاده می کنید، آزاد می کنید main هر زمان که چیزی دارید که در آن ادغام می شود (بلیت، پروژه های تکمیل شده و غیره). روی). یا برخی تیم ها آزاد می کنند main روی یک برنامه، مانند یک بار در هفته.

در اینجا مروری بر چگونگی TBD است تیم ها نسخه های خود را انجام می دهند:

در TBD، شاخه‌بندی برای انتشار استفاده می‌شود تا به همه اجازه دهد به تعهد خود ادامه دهند main.

آنها یک “عکس فوری” از پایگاه کد شما در یک وضعیت پایدار، آماده برای استقرار و انتشار ارائه می دهند.

تنها دلیل TBD نمودار بالا ممکن است به جزئیات بیشتری نیاز داشته باشد زمانی که مشکلی با انتشار prj-123 پیش می‌آید. سپس نتیجه را در تنه قرار می دهیم و cherry commit ها را در شاخه انتشار ما انتخاب کنید تا در اسرع وقت آن را به حالت قابل اجرا برسانید.

بعضی جاها، اگر به طور منظم رها می شوند، حتی منشعب نمی شوند و فقط می توانند تنه را آزاد کنند هر زمان که لازم باشد بستگی دارد روی شرکت شما اغلب

نتیجه

یک سایت کامل وجود دارد روی تئوری و عمل TBD. با خیال راحت اینجا بیشتر بخوانید.

امیدوارم این توضیح داده باشد که چیست توسعه مبتنی بر تنه است و چرا استفاده می شود مطمئناً به کاهش برخی از مسائل مربوط به ادغام شاخه های با عمر طولانی که حاوی بازنویسی های اصلی هستند کمک می کند.

نوشته ام را به اشتراک می گذارم روی توییتر اگر از این مقاله لذت بردید و می خواهید بیشتر ببینید.