توسعه مبتنی بر ترانک (Trunk) چیست؟

منتشر‌شده در freecodecamp به تاریخ ۱۵ مارس ۲۰۲۱
لینک منبع What is Trunk Based Development? A Different Approach to the Software Development Lifecycle

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

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

مطالعه مقاله بهترین زبان برنامه‌نویسی برای یادگیری در سال ۲۰۲۱ چیست؟ توصیه می‌شود.

دو روش مختلف برای شاخه‌دهی

شاخه‌دهی با مشخصه (ویژگی)

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

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

مروری بر نحوه استفاده توسعه‌دهندگان از روش شاخه‌های ویژگی.

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

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

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

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

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

شاید مطالعه مقاله افزونه‌های ضروری کروم برای مهندسان یادگیری ماشینی و دانشمندان داده برای شما مفید باشد.

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

در یک سخنرانی در گوگل، راشل پوتوین، مدیر مهندسی در گوگل، یک کدباز را توصیف کرد که شامل موارد زیر بود (ژوئن ۲۰۱۵) :

• ۱ میلیارد پرونده
• ۲ میلیارد خط کد
• ۸۶ ترابایت محتوا
• ۴۵۰۰۰ رفت و آمد در هر روز کاری
• ۱۵ میلیون خط در هر هفته به ۲۵۰ هزار پرونده تغییر کرد.

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

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

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

نقاط قوت TBD

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

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

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

روش TBD واقعا به طور تمیز با ادغام پیوسته مرتبط است. با تعداد زیادی اشتراک کوچک و افزایشی به یک پروژه نهایی تمام‌شده، شما یک کدباز همیشه تست شده و همیشه یکپارچه با (حداقل) ادغام وحشتناک دریافت می‌کنید.

نقاط ضعف TBD

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

به احتمال زیاد سابقه کامیت شما نسبت به مستر، پردردسرتر خواهد بود و دیدن این که آیا مشکلی وجود دارد یا خیر، سخت‌تر خواهد بود. اگر ساعت ۳ صبح با شما تماس گرفته شود و از شما خواسته شود تا یک اشکال را در سایت پرود خود با برخی از کامیت‌های خطرناک که در طول ساعات کاری ادامه داشت، تعمیر کنید، آیا ترجیح می‌دهید یک روز با ۱ کامیت یا ۲۰۰کامیت را داشته باشید؟

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

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

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

ممکن است به مطالعه مقاله ساخت ماشین‌حساب برنامه‌ریزی مالی با استفاده از Streamlit پایتون علاقمند باشید.

چگونه نرم‌افزار را با TBD منتشر کنیم؟

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

مروری بر نحوه عملکرد تیم‌های TBD در رهاسازی و انتشار:

در TBD، شاخه‌بندی به طور کلی تنها برای رها‌سازی استفاده می‌شود. آن‌ها یک «عکس فوری» از پایگاه کد شما در یک وضعیت پایدار، آماده برای استقرار و انتشار ارائه می‌دهند.

تنها دلیلی که نمودار TBD در بالا ممکن است به جزئیات بیشتری نیاز داشته باشد، زمانی است که چیزی در مورد انتشار prj-۱۲۳ اشتباه باشد. سپس ما نتیجه را به ترانک وارد می‌کنیم و گلچین کامیت‌ها را به شعبه انتشار خود وارد می‌کنیم تا در سریع‌ترین زمان ممکن به وضعیت قابل کار برسیم. برخی مکان‌ها، اگر به طور منظم آزاد می‌شوند، حتی شاخه نمی‌شوند و می‌توانند ترانک را در صورت نیاز آزاد کنند.

نتیجه‌گیری

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

این متن با استفاده از ربات مترجم مقاله برنامه نویسی ترجمه شده و به صورت محدود مورد بازبینی انسانی قرار گرفته است.در نتیجه می‌تواند دارای برخی اشکالات ترجمه باشد.

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