وبلاگ شخصی حامد شیربندی

حامد شیربندی

توسعه دهنده نرم افزار

Continuous Integration - بخش دوم : پیاده سازی در TFS

 مقدمه

در بخش اول این مقاله با مفهوم CI و لزوم پیاده سازی آن آشنا شدیم. در ادامه و در این بخش به نحوه ی پیاده سازی آن با استفاده از TFS می پردازیم.

به صورت پیشفرض انتظار می رود که شما با TFS آشنا بوده و از آن به عنوان یک سورس کنترل بتوانید استفاده کنید. همچنین پیش فرض ما استفاده از TFS Online مایکروسافت می باشد که به صورت رایگان و با یک سری محدودیت به توسعه دهنده ها ارائه میشود.


انتخاب ابزار مناسب CI

قبل از شروع کار بهتر است بدانیم که ابزارهای زیادی برای پیاده سازی CI وجود دارند نظیر octopus و jenkins که حتی به راحتی می توان آنها را داخل TFS استفاده کرد اما در این مقاله من فقط از امکانات داخلی خود TFS استفاده خواهم کرد و این بنا به 2 دلیل است :


- این تخصص اصلی من نیست (DevOps) و نمیخواهم با همه ی ابزارهای مختلف مربوط به آن درگیر شوم.

- تا زمانی که VS و TFS نیازمندی های من را طبق مسئله ی جاری به خوبی پاسخ دهند از آنها خارج نمیشوم و بابت یادگیری ابزار جدید هزینه نمیدهم.


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

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



تعریف Build Pipeline


همانطور که از نام آن پیداست، نشان میدهد که قرار است یک سری عملیات به صورت پشت سر هم و صف مانند روی سورس کد ما اتفاق بیفتد. اولین گام در پیاده سازی CI در TFS، ایجاد یک Build Pipeline است. این فرآیند شامل تعریف یک یا چند فاز میشود و هر فاز هم شامل یک یا چند Task است و هر تسک وظیفه ی اجرای عملیاتی را روی سورس ما به عهده دارد.
برای مثال من یک سناریو به شکل زیر مد نظرم است:

هرگاه هر Check in ی توسط یکی از اعضای تیم صورت گرفت و تغییراتی به سورس روی سرورس کنترل اعمال شد، ابتدا کل پکیج های نوگت Restore شوند، سپس در مرحله ی بعد میخواهم سورس را Build کنم که مطمئن شوم تغییرات جدید مشکل ساز نبوده اند. بعد از بیلد شدن میخواهم Unit Test های موجود در سورس را اجرا کنم تا از pass شدن آنها مطمئن شوم. این به من کمک میکند بفهمم علاوه بر نبود مشکل در Compile Time و بیلد شدن برنامه، در Run Time هم طبق تست هایی که نوشته ام باگی به وجود نیامده است.

بعد از تمام اینها من مطمئن هستم که یک نسخه ی یکپارچه در اختیار دارم و میخواهم از آن Publish بگیرم تا در مراحل بعد به کمک فرآیندهای CD یا همان Continuous Delivery همین نسخه را در اختیار مشتری قرار دهم.

حالا برای پیاده سازی سناریوی فوق به عنوان Build Pipeline کافی است وارد داشبورد پروژه در TFS شده و از منوی بالا روی Build and Release رفته و سپس روی Builds کلیک کنید. سپس کافی ست روی گزینه ی New Build Pipeline بزنید تا وارد فرم زیر شوید :





در اینجا با توجه به اینکه پیش فرض ما این است که از خود TFS به عنوان سورس کنترل استفاده کرده اید و الان ریپازیتوری مربوط به سورس برنامه ی شما روی آن قرار گرفته پس گزینه ی TFVC را انتخاب و روی Continue میزنیم.



تعیین Template


در قسمت بعدی باید یک Template انتخاب کنیم. کار این Template ها چیست؟ همانطور که از نام آن پیداست هر تمپلیت شامل یک قالب پیشفرض از فاز ها و تسک ها برای تعریف یک Build است. برای مثال از آنجایی که پروژه ی من یک پروژه مبتنی برا ASP.NET Core است بنابراین از تمپلیت آماده ی ASP.NET Core استفاده میکنم. کافی ست آن را جستجو و روی Apply کلیک کنید.





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


تعریف و تنظیم فاز و Task ها


پس از کلیک روی تمپلیت ASP.NET Core به محیط تعریف Build یا همان Build Pipeline میرویم:





اینجاست که میتوانیم فاز و تسک هایی که قبلا درباره آنها برایتان گفته بودم را مشاهده کنیم. از سمت چپ اگر نگاه کنید یک فاز به نام Ajent Job 1 داریم که شامل 5 تسک می باشد که همان سناریوی مد نظر ما را به تریتیب پیاده سازی کرده است.حالا باید تنظیماتی انجام دهیم.

دقت کنید که نام فازها اختیاری است و توسط هر فاز میتوانیم تسک هایی را روی یک Agent خاص اعمال کنیم. برای مثال میخواهیم سورس را روی 3 سرور مختلف بیلد کنیم و یا در هر فاز تسک های متفاوتی را اعمال کنیم و ...



تنظیم Agent Pool 

همانظور که میبینید الان در سمت چپ گزینه ی Pipleline فعال است و در سمت راست یک سری تنضیمات کلی برای فاز و تسک ها داریم. ابتدا باید یک نام برای این Build Pipeline در نظربگیریم. چون اسم پروژه ی من DevOpsProject بوده من نام DevOpsProject -CI را برای آن در نظر گرفته ام. سپس در بخش Agent Pool گزینه ی  Hosted VS2017 را انتخاب کرده ام. 

در مورد Agent Pool در مقاله های آتی بیشتر صحبت میکنیم اما تا اینجا این را بدانید که TFS نیاز دارد مطلع شود این سورس را روی چه سروری باید برای شما بیلد کند که این همان Agent شما خواهد بود که باید در نقش Build Server ظاهر شود. اگر شما یک سرور اختصاصی یا مجازی با دسترسی ریموت دارید میتوانید یک Agent در TFS تعریف کرده و آن سرور را در آن ثبت کنید تا همیشه آخرین ورژن سورس و نتیجه ی بیلد آن توسط TFS روی آن سرور ارسال شود.

فرض من بر این است که در حال حاضر سرور اختصاصی برای اینکار نداریم پس میتوانیم از Agent های رایگان خود مایکروسافت استفاده کنیم که برای همین منظور من گزینه ی Hosted VS2017 را انتخاب کردم. فقط این نکته را مد نظر داشته باشید که تعداد بیلد هایی که میتوانید انجام دهید محدود هستند پس اگر همیشه از این سرویس رایگان میخواهید استفاده کنید تنضیمات بیلد خودکار را یا خاموش کنید و یا اینکه آن را به گونه ای تنظیم کنید که حداکثر روزی 1 بار اجرا شود.


تنظیم اجرای Test ها

در قسمت بعدی هم یک پترن برای مشخص کردن پروژه های تست باید وارد کنیم که از طریق آن تست های پروژه اجرا شوند. من در همه ی پروژه هایم یک قرارداد نامگذاری برای لایه ها دارم و طبق این قرارداد تمام تست های unit در لایه هایی قرار داده میشوند که نام آنها به .UnitTests ختم میشود بنابراین من پترن را به شکل صحیح مقداردهی کرده ام تا همیشه مطمئن باشم همه ی تست های من شناسایی و اجرا خواهند شد.


فعال سازی Build خودکار

اگر میخواهید عملیات اجرای بیلد بعد از هربار Check in به صورت خودکار انجام شود از تب Triggers گزینه ی Enable Continuous Integration را فعال کنید.





تنظیم Publish

حالا دوباره به تب Tasks برمیگردیم تا سایر تنظیمات را نیز انجام دهیم. روی تسک Publish کلیک کرده و سپس تیک گزینه های Publish Web Projects و Zip Published Projects را برمیداریم، اینکار باعث میشود تا علاوه بر لایه های Presentation،سایر لایه ها مثل لایه های تست نیز پابلیش شوند چون در آینده میخواهیم در بخش CD یک سری تست UI را نیز اجرا کنیم. البته این پیش فرض من در همه ی  پروژه هایم است که همگی شامل یک سری Unit Tets و همچنین یک سری تست خودکار UI یا همان E2E هستند. تست های unit را طی فرآیند CI اجرا میکنم و تست های UI را نیز طی فرآیند CD و پس از Deploy در یک محیط Staging اجرا میکنم تا یک تاییدیه برای deploy در محیط Production داشته باشم.

نحوه ی پیاده سازی این موارد را نیز در مقالات آتی درمورد CD خواهم گفت.





تا همینجا کار تعریف بیلد خودکار یا همان فرآیند CI را انجام دادیم. فقط یک نکته در مورد تسک پایانی یعنی Publish Artifact، این تسک باعث میشود تا نتایج publish درون یک فایل که نام پیش فرض آن drop است ذخیره شده و در مراحل بعدی زمانی که میخواهیم CD را پیاده کنیم این فایل برای Deploy کردن پروژه استفاده میشود.



اولین Build خودکار با CI


تا اینجا هنوز Pipelineی که تعریف کردیم را ذخیره نکرده ایم. از منوی Save روی گزینه ی Save & Queue کلیک کنید سپس در فرم باز شده مجددا روی دکمه ی Save & Queue بزنید. با اینکار ابتدا کل فرآیند ذخیره میشود و سپس اولین بیلد خودکار در صف انجام قرار میگیرد. کافی است به منوی Builds بروید و ببینید که یک بیلد در حال اجرا است که با کلیک بر روی آن در جریان جزییات اجرای تک تک تسک ها قرار میگیرید. برای مثال این تصویری از بیلدهای پروژه ی مثال من است :






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



پیاده سازی آسودگی و لذت در کدنویسی!



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

نوشته شده توسط حامد شیربندی

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