سفارشی سازی Activity Build در TFS 2015

Activity Build

در این مقاله نشان می دهیم که چگونه Activity Build های سفارشی بسازیم. در ابتدا مرحله موجود را به build definition اضافه می کنیم، سپس یک اسکریپت PowerShell ایجاد کرده و آن را به build definition اضافه می کنیم.

Team Foundation Server 2015 Build Process

ویژوال استودیو ۲۰۱۰ به همراه Team Foundation Server 2010 با مبتنی بر XAML کردن build workflow تغییر عمده ای را ارائه دادند. اجازه دهید که این معماری را با معماری جدید در Team Foundation Server 2015 مقایسه کنیم.

با معماری قبلی، رابطه یک به یک میان افراد پروژه و Build Controller وجود داشت و به سادگی حداقل یک مسئول برای یک Build Controller نیاز بود. بنابراین اگر ما می خواستیم Build ای برای دو مجموعه در یک Team Foundation Server اجرا شود، به دو  Build Controller و حداقل دو Build Agent نیاز داشتیم. نمودار زیر این معماری را نمایش می دهد:

Activity Build

شکل ۱: معماری Build مربوط به نسخه های قدیمی TFS

در نسخه جدید معماری build یک تفاوت بسیار مهم داریم که به جای اینکه build controller به مجموعه های پروژه متصل شوند، پیوندی بین Build Agent و Team Foundation Server داریم.

Activity Build

شکل ۲: معماری Build مربوط به TFS 2015

Build Process

فرایند build به طور کامل به شکل زیر است:

  1. سیستم build بر مبنای Task می باشد. Team Foundation Server این Task ها را برای agent ارسال می کند. لیستی از این Task ها در Open source link در دسترس می باشد.
  2. Agent براساس قابلیت ها از این منبع انتخاب می کند. این قابلیت ها می تواند سیستم عامل، دات نت فریم ورک پردازنده برای agent باشد. این ها به صورت زوج مرتب های نام-مقدار در می آیند. می توان چندین agent داشت.

Activity Build

شکل ۳: قابلیت های میزبانی

  1. سپس agent متغیرهای محیطی را براساس اطلاعات build مشخص می کند. لیست متغیرهای محیطی در این لینک موجود می باشد.
  2. Agent، Taskهای مختلف را اجرا می کند.
  3. Agent، log backها را برای نمایش log به صورت همزمان به TFS برمی گرداند. این log ها به صورت real time نمایش داده می شوند.

Team Foundation Server 2015 برای buildهای غیر ویندوزی نیز پشتیبانی فراهم نموده است. نیازی به ایجاد build definition به صورت کامل نیست چرا که قالب های آماده ای موجود می باشد. سفارشی سازی بسیار آسان است چرا که ما فقط باید custom task ها را اضافه کنیم.

ایجاد یک Build Definition

  1. اجازه بدهید که یک Build definitionای ایجاد کنیم که شامل یک “Visual Studio Build” یک مرحله ای می باشد. شکل زیر build definition را نمایش می دهد:

Activity Build

شکل ۴: Simple Build Definition

  1. روی Add build Steps کلیک کرده و مرحله مورد نظر را که “Publish Build Artifacts” می باشد از تب Build انتخاب کرده و روی Add کلیک می کنیم.

Activity Build

 

شکل ۵: اضافه کردن یک  مرحله به Build Definition

در نهایت روی close کلیک می کنیم.

  1. حال باید مرحله ای که به تازگی اضافه کردیم تنظیم کنیم. باید برای آرگومان های زیر مقادیری مشخص نماییم.

 

  • Copy Root: این آرگومان فولدر ریشه را مشخص می کند که شامل فایل هایی است که می خواهید کپی کنید. اگر آن را خالی بگذارید خودش از repository(مخزن) کپی می کند.
  • Contents: فایل های هستند که می خواهید به مکان خاصی کپی نمایید. با وارد کردن **\bin فایل ها را در هر فولدری که نام آن bin است کپی می کند.
  • Artifact Name: نام artifact
  • Artifact Type: این می تواند دو گزینه داشته باشد، Server(TFS) و اشتراک فایل (از مسیر UNC استفاده می کند)

در این جا ما یک shared folder با نام BuildDrops ایجاد کردیم که جایی است که می خواهیم فایل های باینری را بریزیم.

Activity Build

شکل ۶: تنظیم آرگومان ها برای Build Step

  1. Build را ذخیره می کنیم و بعد از اتمام موفقیت آمیز آن، می توانیم تب Artifacts را انتخاب کنیم و artifact خود را در آن پیدا کنیم.

Activity Build

  1. DropLoc را جستجو کرده و فایل های باینری ریخته شده در مکان مشخص را پیدا می کنیم.

حالا وقت آن است که ببینیم چگونه یک step موجود را به build definition اضافه کنیم، با ایجاد یک اسکریت PowerShell یک task جدید ایجاد می کنیم و به عنوان یک step به build definition  اضافه می کنیم.

در این جا یک اسکریپت ساده PowerShell ایجاد کرده و آن را به source control اضافه می کنیم. سپس یک step جدید به build definition اضافه می کنیم و آن را به جایی که فایل .ps1 وجود دارد ارجاع می دهیم.

  1. اسکریپت PowerShell را با چند دستور ایجاد می کنیم. در اینجا یک فایل ساده که یک سری آرگومان ارسال شده و همچنین متغیرهای محیطی را نمایش می دهد.
param ( $User )

Write-Host 'This is coming from build task'

$message = [System.String]::Format(“Hello {0}!", $User)

$BuildNo = [System.String]::Format(“Build no {0}!", $Env:BUILD_BUILDNUMBER)

$BuildName = [System.String]::Format(“Build no {0}!", $Env:Build_DefinitionName)

$BuildQueuedBy = [System.String]::Format(“Build no {0}!", $Env:Build_QueuedBy)

Write-Host $message

Write-Host $BuildNo

Write-Host $BuildName

Write-Host $BuildQueuedBy

 

حالا باید فایل .ps1 درون source control را بررسی نماییم.

Activity Build

شکل ۸: اضافه کردن فایل اسکریپت PowerShell به source Control

  1. حالا این اسکریپت را به عنوان یک Task جدید اضافه می کنیم. Add Build step را انتخاب کرده و اسکریپت PowerShell را به عنوان type انتخاب می کنیم.
  2. نام فایل اسکریپت را از طریق browse مشخص می کنیم و پارامتری را که باید به عنوان آرگومان مشخص شود انتخاب می کنیم.

Activity Build

شکل ۹: نام فایل اسکریپت

  1. Build را بعد از اضافه کردن task جدید در اسکریپت PowerShell ذخیره می کنیم. Build را اجرا کرده و بعد از اتمام موفقیت آمیز نتیجه را می بینیم.

Activity Build

در این مقاله درباره چگونگی اضافه کردن یک custom task در Team Foundation Server 2015 بحث کردیم. یک task جدید می تواند یک فایل اسکریپت PowerShell، یک فایل json با افزونه یا حتی یک آیکونی باشد که نیاز داریم به صورت embed استفاده نماییم. در این جا ما درباره استفاده از PowerShell صحبت کردیم.

  • پسورد: www.mspsoft.com
مسعود شریفی پور

از سال 88 که با برنامه نویسی آشنا شدم خیلی علاقه مند بودم یک بستر آموزشی بسازم در فضای وب و به انتشار آموزش های در این زمینه بپردازم.حالا یک تیم داریم و با قدرت رو به جلو حرکت میکنیم.

نوشته‌های مرتبط

دیدگاه‌ها

*
*

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