دفاع از TFS – اول حرف دیگران رو بشنویم

هیچوقت فکر نمی کردم خودم رو در مقام دفاع از محصول یک شرکت دیگه ببینم، ولی خب شد!

نرم افزارهایی مثل TFS قابلیت هاشون در سازمان ها و تیم های بزرگ در صورتی که درست استفاده بشن بسیار پر رنگ نمود پیدا می کنه، ولی خب اونجا مشکل به وجود میاد که بخش بزرگی از سیستم های با ابعاد بزرگ در کشور ما روی Java هستن، و همین مساله باعث یک فاصله خیلی زیاد شده، اینکه دوستانی که روی پلتفرم Java هستن معمولا خبری از مایکروسافت ندارن و همیشه با دید بد و حتی تحقیر آمیز بهش نگاه می کنن، در صورتی که دنیای جاوا در زمینه ایی که TFS حضور داره شاید قدمت بیشتری داشته باشه ولی مطمئنا با یک رقیب سر سخت روبرو شده، رقیبی که روند ساخت پر فروشترین سیستم عامل دنیا رو مدیریت می کنه.

 

امروز افتخار اینو داشتم با یکی از دوستان که دارای همین فاصله و اختلاف نظر بین جاوا و مایکروسافت بود صحبتی چند ساعته داشته باشم، در شرکت هایی مثل SAP یا ساختارهای جاوایی به جای واژه ALM از  SCM استفاده می کنند ( System Configuration Management ). این دوستان با عنوان شغلی Configuration Management فعالیت می کنن در صورتی که این دو واژه در کنار هم معنی  متفاوتی رو در ذهن دوستان سمت مایکروسافت ایجاد می کنه ( وقتی کتاب های پایه مباحث Continuous Integration و Deployment رو بخونید تهش میشه اینکه پلتفرم براتون مهم نیست و با دوستان هر پلتفرمی می تونید صحبت کنید! ).

به هر حال، با شنیدن اسم مایکروسافت ایشون اول تعجب کرد که مایکروسافت هم مگر چنین ابزارهایی داره و مگر میشه ایجاد و تنظیم و از بین بردن سرورها رو با ابزار مایکروسافت مدیریت کرد؟ با توضیحات من و گفتن جزئیات ابزارها فقط تعجب ایشون بیشتر می شد و فکر نمی کردن مایکروسافت چنین ابزار کاملی رو توسعه داده باشه، البته واقعا تا قبل از بهار امسال واقعا همینطور بود ولی از بهار ۹۵ همه چیز عوض شد.

برای Configuration Management یا همون ALM خودمون شما یا میتونید از ابزاری مثل TFS که کاملا یکپارچه است و یا از ابزارهایی مثل Puppet و Jenkins و هزارتا ابزار دیگه برای پوشش کمبودهای این ابزارها استفاده کنید. در واقع شما یا از یک برند برای انجام کارهاتون استفاده می کنید مثل مایکروسافت و یا از چندین برند.

 

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

 ساختار ابزارهای DevOps مایکروسافت

همونطوری که می بینید تمام جایگاه های ۴ گانه توسط یک ابزار چه در محیط On Premise و چه در Cloud در نظر گرفته شدن و حتی بیشتر از ۵۰ درصد از این ابزارها در Web Access موجود در TFS مجتمع شدن.

 

حالا همین جایگاه ها رو برای سایر ابزارها نگاه می کنیم.

ساختار ابزارهای جایگزین مایکروسافت در DevOps

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

ولی جالب ترین نکته برای من این بود که ما در سمت مایکروسافت به علت اینکه مایکروسافت این امکان رو فراهم کرده که TFS با تمام ابزارهای دیگه یکپارچه بشه، از Jenkins یا Puppet یا Chef بی خبر نیستیم ولی سمت مقابل می تونم بگم از حجم تغییرات TFS متعجب شد.

 

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

 

معرفی Application Lifecycle management – ALM – بخش اول

نمودار ساختار چرخه مدیریت تولید نرم افزار

بعضی مواقع وقتی عنوان شغلیم رو برای بعضی از دوستا یا همکارا می گم اولین سوالشون اینه که ALM یا ِDevOps یعنی چی، نکته جالبش اینه که خیلی فرقی نمی کنه اون شخص در زمینه کامپیوتر تحصیل کرده یا نه، که البته طبیعیه چون به مرور انواع تخصص ها در تیم ها داره زیاد میشه و این یک خبر خوبه، به هر حال، تصمیم گرفتم در چند مقاله توضیح بدم که ALM در تئوری و در عمل یعنی چی.( من سعی می کنم خیلی وارد جزئیات نشم )

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

تصویر زیر جنبه های مختلف ALM رو نشون میده.

پروسه ALM

ALM مثل یک چسب نقش های مختلفی رو که به همراه هم برای رسیدن به هدف دارن تلاش می کنن در کنار هم قرار میده، این نقشها شامل و نه محدود به موارد زیر هستن:

  • Stakeholders
  • Business manager
  • Project manager, product owner, or Scrum master
  • Project Management Office (PMO) decision makers
  • Business analyst
  • Architect
  • User experience (UX) design team
  • Database administrators (DBAs)
  • Developers
  • Testers
  • Operations and maintenance staff

تمام تلاش هایی که برای به نتیجه رسیدن پروژه انجام میشه به صورت همکاری گروهی هستن و به این شکل بهترین نتیجه حاصل میشه، علت این تاکید ها روی همکاری اعضا تیم یا همون collaboration اینه که ALM وظیفه اصلیش ایجاد ارتباط مناسب بین افراد تیمه، به همین سادگی ولی همین عدم وجود ارتباط مناسب سرچشمه بسیاری از مشکلاته! که بعضا به دلایل فرهنگی و یا نبود ابزار مناسبه.

 

۴ روش نگاه کردن به ALM

معمولا به ۴ روش به ALM نگاه میشه که البته روش چهارم روش کامل هست و سه مورد دیگه معمولا نگاه سازمان ها به این مساله است.

  • Software development lifecycle – SDLC: این عمومی ترین نگاهه برای اینکه توسعه دهنده ها برای مدت زمان زیادیه که توسعه نرم افزار رو بر عهده دارن و شاید علت دیگه اش فاصله بین تیم های توسعه نرم افزار و تجاری هست.
  • Service management or operations: متاسفانه این بخش همیشه به شکلی کاملا جدا از فرآیند توسعه نرم افزار دیده شده.
  • Application Portfolio Management – APM: این همون بخشی هست که برنامه های تجاری رو ایجاد و مدیریت می کنه که به علت فاصله بخش توسعه نرم افزار و تجاری معمولا در برنامه هاشون فضای زیادی برای تیم نرم افزار در نظر نمی گیرن.

Application Portfolio Management view of alm

  • Unified view: خوشبختانه بعضی سازمان ها روی تمام فرآیند ALM از طریق در نظر گرفتن سه دیدگاه قبلی تمرکز کردن، این تنها راهیه که میشه کنترل رو به دست گرفت. برای یک CIO این مساله خیلی مهمه که همیشه دید جامع رو داشته باشه.

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

سه ستون سنتی ALM

منهای اینکه شما به کدوم یک از چهار روش بالا به ALM نگاه می کنید، ALM دارای ۳ ستون اصلیه که بر اساس اونها بنا نهاده شده.

ستون های ALM

Traceability (قابلیت ردیابی)

تا حالا شده از ایجاد تغییر در بخشی از کد بترسید چون نمی دونید ممکنه چه جاهای دیگه ایی از کد نیاز به تغییر داشته باشه؟ وقتی صحبت از ردیابی میشه یعنی اینکه اگر بخش تجاری بخواد ببینه درخواستی که داشته و باید به نرم افزار اضافه میشده در چه وضعیتیه و چه کارهایی براش انجام شده، افراد مرتبط کارهای انجام شده، باقی مونده، کدهای نوشته شده، تست ها و نتیجه اونها و اینکه اصلا وارد محیط عملیاتی شده و کی؟ این همون Release Note میشه که بعد از هر پابلیش در اختیار عموم قرار می گیره.

 

Automation of High-Level Processes

در هر سازمانی پروسه های نوشته یا نا نوشته وجود داره و ALM نیازداره تا حد ممکن این موارد به شکل خودکار انجام شن تا کارهای تکراری زمان تیم رو به خودشون اختصاص ندن، مثل ربات های خط تولید کارخانه های ماشین سازی. خب نوشتن کد رو که نمیشه اتوماتیک کرد، ولی اجرای تست ها، Build کدها، ایجاد Pakage های نرم افزار و انتقال به محیط های تست رو که میشه اتوماتیک کرد و خیلی موارد دیگه مثل انتقال تغییرات دیتابیس به محیط های مختلف در واقع Continuous Integration  و Continuous Deployment در همین راستا هستن.

 

Visibility into the Progress of Development Efforts

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

 

در  بخش  دوم این نوشته درباره تاریخچه ALM و روند تکامل اون از ALM 1.0  به ALM 2.0  و ALM 2.0+ نگاهی می ندازیم و در بخش سوم هم به شکل عملی به TFS 2017 نگاه می کنیم و موارد تئوری گفته شده رو در عمل بررسی می کنیم، البته در نظر بگیرید که پیاده سازی آخرین استاندارد و حتی استاندارد ۲٫۰ ALM اصلا کار آسونی نیست و هنوز هیچ شرکتی نتونسته حتی تمام جوانب ALM 2.0 رو پوشش بده.

 

 

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 هم سربار هزینه سرورها رو در گام اول داره.

 

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