مهاجرت به TFS 2017 – بخش اول – Code Search و مدیریت پکیج ها

تقریبا دو ماه از زمان ارائه نسخه جدید TFS که به نام TFS 2017 شناخته میشه و قبلا Code Name اون TFS15 بود می گذره، با توجه به زمانی که گذشته و نزدیک شدن ما به ارائه اولین آپدیت این نرم افزار فکر می کنم زمان مناسبیه که ببینیم آیا علتی داره خودمون رو به زحمت بندازیم و نسخه جدید رو نصب کنیم یا نه.

 

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

اطلاعات کامل Release Note برای TFS 2017 در این لینک وجود داره.

 

امکانات جدید اضافه شده به TFS 2017 به قرار زیر هستن:

  • Code Search
  • Package Management
  • Agile Improvements
  • Dashboards And Widget Improvements
  • Git Improvements
  • Build Improvement
  • Release Management Improvements
  • Test Improvements
  • MarketPlace Improvements
  • Administration Improvements
  • Personal Access Tokens

 

Code Search:

تا حالا امکان اینو داشتیم که خیلی راحت Work Item های موجود رو با استفاده از امکان جستجوی موجود در بالا و سمت راست صفحه TFS 2015 پیدا کنیم( اگر Template شما اسکرام بوده )، ولی هیچوقت این توانایی برای کدها اضافه نشد، به عنوان مثال شما به دنبال یک خط کد مشخص هستید و می خواید این خط کد رو در بیشتر از یک پروژه یا Repo Git جستجو کنید و این باعث به حداکثر رسیدن ارتباطات بین تیمی و اشتراک کدها میشه، این امکانیه که در Visual studio هم وجود نداره، ولی Code Search این امکان رو به شما میده.

آموزش افزونه CodeSearch TFS 2017

البته نصبش جزئیات متفاوتی از بقیه Extension ها داره و اونم اینه که باید در کنترل پنل اصلی TFS امکان Search رو فعال کنید تا این Extension بتونه نصب شه.

 

فعال کردن Search در TFS 2017

در این لینک جزئیات بیشتری از این افزونه ارائه شده.

 

Package Management :

همه با ابزارهایی مثل Nuget Package و NPM آشنا هستیم، مشکلی که در ارتباط این ابزارها با TFS وجود داشته اینه که کاملا مستقل از هم هستن و امکان کنترل مجتمعی روی Package ها وجود نداشت، به عنوان مثال من می خوام فقط عده خاصی( اعضای یک گروه تعریف شده در TFS ) که روی یک محصول کار می کنن Package X رو ببینن، در حال حاضر این مساله امکان پذیر نیست و بعلاوه تا حالا ما مجبور بودیم از UNC یا Nuget Package Server داخلی برای نگهداری Package ها استفاده کنیم، گروه های امنیتی TFS نمی تونن محدوده اختیار خودشون رو به UNC ما که همه Package ها روی اون قرار داره توسعه بدن.

Package Management In TFS 2017

 

با اضافه شدن Extension Package Management حالا فرآیند ایجاد و نگهداری و دسترسی به Package ها با سایر بخش های TFS مجتمع شده، به شکلی که پکیج ها در TFS نگهداری خواهند شد و دسترسی به هر کدوم از پکیج ها قابل تنظیمه و از همه مهم تر اگر نیاز دارید با ایجاد نسخه جدید از پروژه پکیج پروژه به شکل خودکار ایجاد و ورژن بندی بشه، حالا ابزارهاتون خیلی کامل تر شده.

مدیریت بسته ها در TFS 2017

امکانات خاص و متفاوت دیگه ایی هم به این Extension اضافه شده که می تونید با خواندن جزئیات در این لینک از اونها مطلع بشید.

بررسی سورس کنترل به دو روش TFVC و Git در TFS 2017

مقایسه TFVC و Git

 

با توجه به اینکه در شرکت ها و موسسات مختلف معمولا به صورت تیمی روی پروژه های نرم افزاری کار میشه تمام ابعاد کار باید برای تمام اعضای تیم قابل مشاهده و بررسی باشه، یکی از این موارد کدهای نرم افزار و محصولات مرتبط با اونه که باید در جایی که امکان از دست رفتن اونها وجود نداره نگهداری بشه، به این سیستم ها 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 نمایش داده شده.

فلو دیاگرام انتخاب بین TFVC و Git

جهت مشاهده تصویر در ابعاد واقعی روی اون کلیک کنید.

همچنین Cheat Sheet این دو VC در تصویر زیر نمایش داده شده.

مقایسه عملیات های موجود در TFVC و Git

جهت مشاهده تصویر در ابعاد واقعی روی اون کلیک کنید.

 

در نهایت اینکه هر دو روش بسیار خوب پیاده سازی شدن، ولی بسته به نیاز شما و اینکه چه مسائلی برای شما اولویت داره می تونید بین این دو روش یکی رو انتخاب کنید، در حال حاضر من ترجیحم Git هست چون وجود Pull Request ها میتونه به تیم کمک زیادی کنه. تقریبا از آخرین باری که  تیم Microsoft برای TFVC گامی برداشته زمان زیادی گذشته و طبق لیست موارد در حال انجام حتی اولویتی  هم براش ندارن.

 

Visual Studio Team Services یا Team Foundation Server مساله این است

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

خب باید این موضوع رو  بگم که شرایط کشور ما روی  نظری که من میدم تاثیر مستقیم داره و عمده مساله ایی که باید در نظر بگیرید روابط خاص بین شرکت مایکروسافت و مشتریانی هست که مبدا اونها ایرانه. خب بذارید برگردیم به صحبت اصلی خودمون  من در دو بخش این مقایسه رو انجام میدم یکی از نظر فنی و دوم از نظر  مسائل غیر فنی.

مقایسه TFS و VSTS

 

مسائل فنی:

هر دو در زمان راه اندازی پیچیدگی های خودشون رو دارن روی Azure هم شما اول باید اکتیو دایرکتوریتون رو ست کنید و گروه های کاریتون رو باید مشخص کنید تا مدیریت امنیت براتون دغدغه نشه!( چون اگر دقت نکنید مدیریت امنیت و دسترسی به پروژه ها بین تیم ها خیلی زود براتون تبدیل به یک کلاف سردرگم میشه )

در VSTSنیازی به تنظیم سرور نداریم چون به شکل Software as a service ارائه میشه، در این زمینه VSTS به علت اینکه به شکل خودکار به روز رسانی ها رو دریافت می کنه ( سرویس VSTS از نظر امکانات سه ماه از TFS جلوتره و معمولا بعد از این مدت هست که امکانات جدید رو در TFS هم  خواهیم داشت ) و نیازی به سروری در سازمان شما وجود نداره بخشی از سربار کار شما رو کم می کنه ولی برای زمان Test ها و یا Build ها از شما هزینه می گیره، آخرین باری که چک کردم بر اساس زمان استفاده محاسباتش رو انجام میده، در واقع شاید در ابتدا دردسرش کمتر باشه ولی خب باید مراقب مبلغ شارژش باشید البته من اینجا به بحث های دیگه ایی مثل مدیریت Artifact ها ورود نمی کنم ولی بدونید خروجی Build هاتون هم مهمه و میتونه فضای زیادی رو روی Azure به خودش اختصاص بده که اون هم جز هزینه هاتون خواهد بود.

در عوض سمت TFS تنظیم سرو اصلی ، تنظیم سرورهای Build و هر گونه سرور دیگه ایی مثل Test سرورها و یا Stage های پابلیش نرم افزارتون با خود شماست و ساده بگم باید مراقب این سرورها باشید و BackUp Plan برای دیتاهاتون داشته باشید، Backup از سرورها لازم نیست ولی حتما باید  BackUp از اطلاعاتتون در TFS بگیرید و بدونید که ایجاد سیستم BackUp گیری اتوماتیک کمکی بهتون نمی کنه و روی برگردوندنش ممکنه به مشکل بخورید و راه حل ۱۰۰% تظمین شده ایی نیست. در مورد به روز رسانی هم زحمتش با خودتونه بسته به اینکه چه نسخه رو میخواید به چه نسخه ایی Upgrade کنید مسائل متغیره، ممکنه مجبور شید تو دو مرحله به روز رسانی رو انجام بدید و ممکنه تو یک مرحله هم بتونید ولی تمام اینها در زمانیه که Domain شما ثابته ولی اگر کاربرهاتون رو بخواید بین دو Domain جابجا کنید و در عین حال نخواید تغییرات کاربرها مثل تاریخچه ها، Shelveset ها ،Annotation ها بهم بخوره باید یک فرآیند تبدیل کاربر رو هم سپری کنید که ممکنه مجبور شید دیتابیس TFS رو دستی تغییر بدید ( اینکار هیچ جایی توضیه نشده ولی من مجبور شدم، انجام دادم و نتیجه ایی رو که میخواستم گرفتم ). در این روش طبیعتا ما شارژ ماهیانه ایی نداریم.

در هر دو روش اگر تیمتون بزرگ تر از ۴۰ توسعه دهنده است یک نفر رو باید برای کارهای مرتبط با VSTS/TFS در نظر بگیرید.

 

مسائل غیر فنی:

خب این بخش شاید کم اهمیت تر از بخش اول نباشه، ببینید مساله ایی که هست اینه که اگر شما از VSTS استفاده کنید شرکت مایکروسافت گزینه Export در اختیار شما قرار نمیده! این یعنی اینکه بعد از دو ماه استفاده از این سرویس شما به قدری ارزش افزوده در این سرویس دارید که برای شما هزینه بر خواهد بود که اون رو کنار بذارید و برید سراغ TFS، به عنوان مثال شما بعد ۳ ماه تصمیم به تغییر  می گیرید ولی با اینکار تمام تاریخچه کارهاتون رو از دست خواهید داد و انگار از صفر شروع کردید، مثلا نمیدونید که تغییرات روی جدول Person توسط چه افرادی بوده و چرا و در چه تاریخی و در چه برنچی! می بینید؟ حجم دیتایی که ازدست می دید باعث میشه کارهای روزانتون تاثیر بپذیرن، مایکروسافت زمانی که اعلام کرد گزینه Export حذف خواهد شد اجازه Export گرفتن به نسخه خاصی از TFS رو برای مدت محدودی فعال کرد و بعد برای همیشه این گزینه غیر فعال شد.

خب چیزی که درباره Export گفتم یک جنبه مهم دیگه هم داره، فرض کنید من یک پروژه رو به شرکت شما Outsource می کنم ( همون برون سپاری خودمون) و از شما می خوام که در انتهای پروژه و یا در فواصل معین تمام اطلاعات ایجاد شده رو در اختیار من بذارید، خب اینجا دیگه اصلا نمیشه از VSTS استفاده کنید اگر هم تا حالا استفاده کرده باشید که بسته به نظر کارفرما شرایط متفاوت خواهد کرد.

فرض کنید شما کارفرما هستید و بعد از مدت ها انتظار و صرف هزینه نتیجه پروژه رو به شکل یک فایل Zip شده در اختیارتون بذارن! نه روند مدیریت پروژه مشخصه ( اینکه چه Feature هایی تعیین شده و برای اونها چه افرادی چه Task هایی رو انجام دادن و خیلی مسائل دیگه در زمینه Agile و Scrum )، تاریخچه کدها و دیتابیس شما و ارتباط اونها با Work Item ها هم مشخص نیست و تستی هم اگر وجود داشته باشه به شما تحویل نمیشه و خیلی ارژش افزوده های دیگه ایی که ALM و DevOps ایجاد می کنه، حداقلش اینه که در روشی که مجری از VSTS استفاده کرده باشه اصلا گزینه دیگه ایی رو نمیشه متصور شد.

 

خلاصه اینکه اگر از VSTS استفاده می کنید براتون شارژ ماهانه داره و برای همیشه بهش وابسته می شید و نیاز پیدا می کنید چرایی فایل Zip شده رو به کارفرما توضیح بدید. ( من وارد موارد پیچیده تر نشدم مثل مواردی که یک شرکت به دو شرکت تقسیم میشه و کدهاشون باید از هم جدا شه )، و TFS هم سربار هزینه سرورها رو در گام اول داره.

 

با آرزوی موفقیت همه شما همکاران عزیز

بررسی ALM/DevOps با استفاده از راه کار های ارائه شده توسط شرکت مایکروسافت – بخش اول

در سال های اخیر در بخش فرآیند تولید نرم افزار تغییرات زیادی صورت گرفته به عنوان مثال در گذشته مایکروسافت هر چندسال یکبار نسخه جدیدی از محصولات خود را معرفی می کرد ولی در حال حاضر این مساله هر ۳ ماه یکبار رخ می دهد، تعداد خطاها در محصولات این شرکت بسیار کمتر شده، امنیت نرم افزارها ارتقا یافته، این شرکت تا ۳ سال پیش حتی فاقد Unit Test برای محصولات خود بود.

جواب تغییراتی از این قبیل در شرکت هایی مثل Microsoft, Amazon, Oracle, IBM, Twitter اعمال روشی جدید به نام ALM یا DevOps است. با استفاده از این روش ها خط تولید نرم افزار مثل خط تولید شرکت های بزرگ خودرو سازی شد و فرآیندهایی که در آنها توانایی خودکار سازی وجود داشت توسط رایانه ها انجام گرفت در نتیجه نیروی انسانی سازمان زمان بیشتری برای انجام وظایف مهم تر کسب کرد به عنوان مثال در مایکروسافت تمام محصولات دارای Unit Test شدند تا استاندارد تولید نرم افزار در این شرکت ارتقا یابد، در Twitter در هر شبانه روز بیش از ۲۴ بار سرویس این شرکت Publish شد، در آمازون پس از طی فرآیندی مشخص، کد نوشته شده برای هر سرویس  به شکل خودکار Publish شد. هر چقدر ابعاد سیستم های نرم افزاری بزرگتر شدند، نیاز به ساختارهایی برای مدیریت جامع آنها و حذف انسان از فرآیندها بیشتر احساس شد.

 

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

طبق گزارشات Gartner مایکروسافت یکی از رهبران این حوزه به شمار می آید زیرا برای تمام ابعاد تولید و نگهداری نرم افزار راه حل ارائه نموده است.

 

ابزارهایی که مایکروسافت برای پیاده سازی DevOps بهره می برد به شرح زیر هستند:

·       Microsoft Team Foundation Server به عنوان قلب سیستم و یکپارچه کننده تمام زیر سیستم ها

·       Microsoft Visual Studio

·       Powershell

·       Microsoft Test manager

·       Build & Release Agents

ساختار کلی DevOps استک مایکروسافت

در پست های بعدی به شرح کامل این موارد خواهم پرداخت.