با توجه به اینکه در شرکت ها و موسسات مختلف معمولا به صورت تیمی روی پروژه های نرم افزاری کار میشه تمام ابعاد کار باید برای تمام اعضای تیم قابل مشاهده و بررسی باشه، یکی از این موارد کدهای نرم افزار و محصولات مرتبط با اونه که باید در جایی که امکان از دست رفتن اونها وجود نداره نگهداری بشه، به این سیستم ها Version Control یا Source Control گفته میشه، این سیستم ها مسئولیت مجتمع کردن فایل ها در یک منبع، حفظ تاریخچه فایل ها و تمام تغییرات اونها، ثبت رد پای تغییرات در سیستم یا همون تاریخچه تغییرات و افرادی که باعث تغییرات بودن رو دارن.
Version Control ها ( از اینجا به بعد اختصارا به اونها VC میگم ) معمولا به دو دسته کلی تقسیم میشن، VC متمرکز و VC توزیع شده. دسته ایی که متمرکز یا همون Centralize هستن کنترل کامل تری روی تمام ابعاد کدها دارن و در لحظه می تونن عملکرد تمام افراد تیم رو مانیتور و بررسی و در صورت نیاز تغییراتی رو اعمال کنن و یا جلوی یکسری تغییرات رو بگیرن ولی خب همین مسائل باعث به وجود اومدن سربار میشه ( چون همیشه باید به سرور مرکزی متصل باشید و بدون ارتباط با سرور شما تمام اطلاعات رو از دست می دید ) و اگر مثلا تیم در کشورهای مختلف پخش شده باشه و شبکه شما هم ضعیف باشه خب شاید در پروژه های بزرگ کار رو یکم سخت کنه، که این مساله رو من خودم به شخصه تست نکردم ولی بعید میدونم توی پروژه های معمول ما مشکلی درست کنه، ولی سیستم های توزیع شده این امکان رو میدن که حتی اگر شما به شبکه متصل نیستید کارتون رو انجام بدید و به تمام تاریخچه ها و اطلاعات لازم برای کارتون روی رایانه خودتون دسترسی داشته باشید و حتی تغییراتی رو که در فایلها ایجاد می کنید در VC ثبت کنید و وقتی که دوباره به شبکه متصل شدید تغییراتتون رو در سرور اصلی اعمال کنید.
مایکروسافت در محصول TFS و VSTS از همون ابتدا یک سیستم VC Centralize داشت که اسمش هست (TFVC (Team Foundation Version Control ولی در سال ۲۰۱۳ با توجه به محبوب شدن Git و اینکه Git یک سیستم VC Distributed هست، تصمیم گرفت این نوع از سیستم های توزیع شده رو هم به محصول خودش یعنی همون TFS ما اضافه کنه تا تیم ها هر دو انتخاب رو داشته باشن و بسته به نیازشون تصمیم بگیرن.
با توجه به اینکه در شرکت ها و موسسات مختلف معمولا به صورت تیمی روی پروژه های نرم افزاری کار میشه تمام ابعاد کار باید برای تمام اعضای تیم قابل مشاهده و بررسی باشه، یکی از این موارد کدهای نرم افزار و محصولات مرتبط با اونه که باید در جایی که امکان از دست رفتن اونها وجود نداره نگهداری بشه، به این سیستم ها Version Control یا Source Control گفته میشه، این سیستم ها مسئولیت مجتمع کردن فایل ها در یک منبع، حفظ تاریخچه فایل ها و تمام تغییرات اونها، ثبت رد پای تغییرات در سیستم یا همون تاریخچه تغییرات و افرادی که باعث تغییرات بودن رو دارن.
Version Control ها ( از اینجا به بعد اختصارا به اونها VC میگم ) معمولا به دو دسته کلی تقسیم میشن، VC متمرکز و VC توزیع شده. دسته ایی که متمرکز یا همون Centralize هستن کنترل کامل تری روی تمام ابعاد کدها دارن و در لحظه می تونن عملکرد تمام افراد تیم رو مانیتور و بررسی و در صورت نیاز تغییراتی رو اعمال کنن و یا جلوی یکسری تغییرات رو بگیرن ولی خب همین مسائل باعث به وجود اومدن سربار میشه ( چون همیشه باید به سرور مرکزی متصل باشید و بدون ارتباط با سرور شما تمام اطلاعات رو از دست می دید ) و اگر مثلا تیم در کشورهای مختلف پخش شده باشه و شبکه شما هم ضعیف باشه خب شاید در پروژه های بزرگ کار رو یکم سخت کنه، که این مساله رو من خودم به شخصه تست نکردم ولی بعید میدونم توی پروژه های معمول ما مشکلی درست کنه، ولی سیستم های توزیع شده این امکان رو میدن که حتی اگر شما به شبکه متصل نیستید کارتون رو انجام بدید و به تمام تاریخچه ها و اطلاعات لازم برای کارتون روی رایانه خودتون دسترسی داشته باشید و حتی تغییراتی رو که در فایلها ایجاد می کنید در VC ثبت کنید و وقتی که دوباره به شبکه متصل شدید تغییراتتون رو در سرور اصلی اعمال کنید.
مایکروسافت در محصول TFS و VSTS از همون ابتدا یک سیستم VC Centralize داشت که اسمش هست (TFVC (Team Foundation Version Control ولی در سال ۲۰۱۳ با توجه به محبوب شدن Git و اینکه Git یک سیستم VC Distributed هست، تصمیم گرفت این نوع از سیستم های توزیع شده رو هم به محصول خودش یعنی همون TFS ما اضافه کنه تا تیم ها هر دو انتخاب رو داشته باشن و بسته به نیازشون تصمیم بگیرن.
مزایا و معایب TFVC و Git در TFS/VSTS
جالبه که هر کدوم از این دو VC معایب و مزایای خودشونو دارن بعضی از این موارد خروجی میزان اهمیتیه که تیم آقای برایان هری برای هر کدوم از این دو مورد در نظر دارن ولی در حال حاضر Git خیلی بیشتر توی چشمه و دارن زمان زیادی رو صرف بهتر کردن استفاده از Git در TFS می کنن! خروجی این مساله این شده که من در حال حاضر کار کردن با Git رو ترجیح می دم و اون هم به مزیت های نسبی استفاده از اون در TFS بر میگرده!
- در TFVC یک کنترل جامع روی تمام ابعاد پروژه داریم ولی Git این رو نداره و منی که مسئول بررسی وضعیت کدها هستم گاها با مناطقی روبرو میشم که در رادار من قابل مشاهده نیستن
- از نظر امنیت روی کدها و سطوح اونها TFVC خیلی قویتره ولی Git کلی تر برخورد میکنه و کار رو یکم سخت می کنه ( دقت کنید که داریم درباره پیاده سازی GIT در نرم افزار TFS مایکروسافت حرف میزنیم نه Git به شکل کلی و عمومی )
- کار کردن با TFVC برای برنامه نویس ها شاید آسون تر باشه و کار با Git به آموزش بیشتری نیاز داره، در هر دو سیستم ما Branch داریم ولی خب این کجا و آن کجا و در پیاده سازی به دو روش کاملا متفاوت عمل شده ( در یک پست دیگه به مبحث Branch ها رو بررسی می کنیم ).
- Code Review در توسعه نرم افزارها نقش خیلی پر رنگی داره و از اصلی ترین بندهایی که باعث شده Linux به ۱۵ میلیون خط کد بتونه انقدر ثبات داشته باشه همین موضوع هست، وقتی این قسمت رو در TFVC و Git مورد بررسی قرار می دیم می بینیم که فاصله زیادی وجود داره، منظورم از فاصله اینه که قسمت های جدیدی که دارن به TFS اضافه می شن خیلی کامل تر و کم نکته ترن ولی چیزهایی که قبلا تر اضافه شده گاها نقاط مبهمی دارن، مثلا همین Code Review در TFVC به دو روش تحت وب و با استفاده از Visual Studio قابل انجامه ولی در نهایت یک روش با ثبات با امکان مانیتور شدن Code Review ها و جلوگیری از ایجاد مشکلات به صورت سیستمی نیست و مسائل رو به دست توسعه دهنده میسپاره، در صورتی که در Git با استفاده از Pull Request تا زمانی که مجموعه قوانینی که کاملا قابل تنظیم هستن به جواب مطلوب نرسن، توسعه دهنده نمیتونه تغییرات خودش رو به سایر بخش ها منتقل کنه و این مساله از انتشار مشکلات جلوگیری می کنه و بسیار بسیار کاربردیه.
- یکی از نکات جالب جدیدی که به Git اضافه شده اینه که می تونید برای کارهایی که به شما اختصاص داده میشه یک Branch بسازید، مثلا در Scrum شما می تونید برای یک PBI یک Branch بسازید و کارهای خودتون رو مستقلا در اون برنچ انجام بدید و در نهایت با اتمام PBI برنچ مرتبط رو Merge و بعد حذف کنید.
- TFVC معمولا نیاز داره که از افزونه های مایکروسافت به نام Team Explorer Everywhere استفاده کنید یا برای بعضی محیطها از Plug in هایی که طراحی شده استفاده کنید مثل Php Storm که Plugin مخصوص TFVC داره، ولی برای محیط های غیر ویندوزی بهتره از Git استفاده کنید، چون نیازی به افزونه نداره و به شکل معمول ابزارهای موجود در این محیط ها از Git پشتیبانی می کنن.
- تعداد Repo های Git در یک Collection میتونه نامحدود باشه ولی فقط می تونید یک Repo از نوع TFVC داشته باشید و باید در همون Repo پروژه ها رو با Folder دسته بندی کنید.
در تصویر زیر Flow Diagram روش انتخاب یکی از این دو VC نمایش داده شده.
همچنین Cheat Sheet این دو VC در تصویر زیر نمایش داده شده.
در نهایت اینکه هر دو روش بسیار خوب پیاده سازی شدن، ولی بسته به نیاز شما و اینکه چه مسائلی برای شما اولویت داره می تونید بین این دو روش یکی رو انتخاب کنید، در حال حاضر من ترجیحم Git هست چون وجود Pull Request ها میتونه به تیم کمک زیادی کنه. تقریبا از آخرین باری که تیم Microsoft برای TFVC گامی برداشته زمان زیادی گذشته و طبق لیست موارد در حال انجام حتی اولویتی هم براش ندارن.