‫امکانات جانبی برای TFS

از زمانی که کار با TFS 2010 را شروع کرده بودم به تدریج کمبود بعضی امکانات را حس کردم. مثلاً Policy اجباری بودن comment به هنگام check-in یا تعیین کل buildهای در حال اجرا یا ابزارهایی برای ساده شدن مکانیزم backup/restore.

قرار بود یک سری از این ابزارها را خودمان بسازیم. مثلاً با API مربوطه در TFS کار کرده و تیکه کدی برای اعمال یک سری Policyهای خاص در زمان check-in بنویسیم. خوشبختانه این بار کمبود وقت و تنبلی به نفع ما تمام شد. چون طی مدت این یک سال خود مایکروسافت مجموعه‌ای از این ابزارهای کوچک و به در بخور را ایجاد، در کنار هم گذاشته و تحت عنوان TFS Power Tools منتشر کرده است.

این مجموعه علاوه بر این کار بیشتر درخواست‌های ما را پوشش داده بلکه تعدادی امکان مفید دیگر را هم اضافه کرده است. برای کسب اطلاعات بیشتر به لینک دریافت آن یعنی Team Foundation Server Power Tools December 2011 مراجعه کنید.

تسلیم می‌شویم

در یکی از مجموعه‌ها خیلی اصرار کردم که به جای TFS از SVN استفاده شود. اما نتوانستم حرفم را به کرسی بنشانم. الان در آن مجموعه تقریباً از همه امکانات سورس کنترلی TFS استفاده شده و به غیر از دو سه ماه اول که دوستان خطاهای Runtime برنامه‌شان را هم به گردن TFS می‌انداختند مشکل خاصی وجود ندارد.

در مجموعه دیگری بدون آن که خیلی اصرار کنم موفق شدم به جای TFS یا هر سورس کنترل دیگری از git استفاده کنم. اما حالا سخت پشیمانم و نادم. چون بر و بچ محترم حال ندارند چند تا نکته ساده را هم رعایت کنند. به فکر آقایان و خانم‌ها خطور نمی‌کند که:

۱- قبل از صدور دستور commit، فایل‌های تغییر یافته‌شان را save کنند،

۲- حذف و اضافه فایل به پروژه در ویژوال استودیو نیاز به Save all یا اقلاً یک Rebuild Solution دارد،

۳- اگر دو نفر یک جای یکسان از یک فایل واحد را تغییر دهند، merge conflictی به وجود می‌آید که خود git نمی‌تواند آن را به طور خودکار resolve (حل) کند. و این از منطق کار تیمی و منطق فکری نشات می‌گیرد و جز نقایص git یا هر سورس کنترل دیگری نیست،

۴- ساختار پروژه در ویژوال استودیو خودش در یک فایل خاص با پسوند csproj نگهداری می‌شود پس به وجود آمدن merge conflict در آنجا هم امکان‌پذیر است،

۵- برای پیشگیری از merge conflict اول هر روز کاری یا حتی دو سه بار در روز، قبل از شروع کار باید اول تغییرات دیگران را دریافت کرد،

۶- نگهداری فایل یک کلاس یا winform با بیش از ۱۵۰۰ خط کار درستی در یک محیط تیمی و تحت سورس کنترل نیست،

۷- …

تنها فرق حالت اول و دوم این است در که در حالت اول خود ویژوال استودیو همه کارها را انجام می‌دهد. مثلاً قبلاً از check-in شما را مجبور می‌کند که همه فایل‌ها را save کنید. بنابراین کسی مجبور نیست از معدن گچش استفاده کرده و حواسش به save فایل‌ها قبل از ارسال به سرور باشد.

این است که دست‌هایمان را به نشانه تسلیم بالا برده و اجازه می‌دهیم دوستان به جای استفاده از git، سورس مشترکشان را روزی ده بار از طریق usb flash با هم به اشتراک بگذارند و خودشان نقش سورس کنترل را بازی کنند.

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

.
.
.
.

باشد که روزی به راه راست هدایت شویم.

‫Burn down chart دقیق در TFS

Burn down chart یکی از ابزارهایی است که در اسکرام برای مشاهده و پیش بینی روند پیشرفت اسپرینت به کار برده می‌شود. اگر برای اسکرام از TFS 2010 و قالب Scrum for Team System استفاده می‌کنید، رعایت نکات زیر لازم می‌شود تا نمودار دقیقی داشته باشید.

۱- قبل از شروع هر اسپرینت، یعنی قبل از این که وضعیت آن از Not Started به In Progress تغییر کند، زمان‌های Estimation effort و Remaining Work را در تک تک SBTها به طرز صحیح وارد کنید و سعی کنید آنها را تغییر ندهید. در غیر این صورت نمودار شما به جای این که رو به پایین باشد رو به بالا خواهد بود:

۲- وارد کردن درست تاریخ‌ها و دیگر اطلاعات اسپرینت هم فراموش نشود.

۳- اعضای تیم نباید یادشان برود که وضعیت PBI/SBTها را از حالت Not Started خارج کرده و به وضعیت‌های In Progress یا Done ببرند. در غیر این صورت نمودار هرگز به روز نشده و فقط یک خط افقی را نمایش خواهد داد.

۴- اعضای تیم باید وضعیت هر PBI/SBT را درست همان موقع که شروع می‌کنند یا به پایان می‌رسانند به روز رسانی کنند. در غیر این صورت نمودار Burn down chart غیر واقعی خواهد بود.

۵- گزارش Burn down chart تا زمانی که تاریخ شروع اسپرینت فرا نرسیده و وضعیت اسپرینت مورد نظر از حالت Not Started خارج نشده باشد چیز مفهومی را نشان نخواهد داد. چه شیب صحیح و چه مجموع ساعات کاری:

۶- هر چقدر که PBIها به SBTهای ریزتری شکسته شده باشند، دقت Burn down chart بالاتر خواهد رفت.

۷- در نهایت اگر موارد نیاز رعایت شده باشد نموداری شبیه به نمودار زیر به دست خواهد آمد:

پ.ن.: در اسکرام هر پروژه به تعدادی اسپرینت معمولاً دو هفته‌ای، هر اسپرینت به تعداد Backlog Item یا PBI و هر PBI به تعداد Task یا SBT تقسیم می‌شود. هر PBI نمایانگر یکی از سناریوهای مشتری مثل «مدیریت کاربران» یا «پرداخت وام» است و معمولاً پیاده‌سازی آن ۲ تا ۳ روز طول می‌کشد. هر SBT هم معمولاً ۴ تا ۶ ساعت زمان می‌برد.

‫ایجاد پروژه در TFS به روش اسکرام

یکی از کارهایی که همیشه انجام می‌دهم ایجاد یک پروژه در TFS 2010 به روش اسکرام است. بد ندیدم که بعضی از مراحل آن را در اینجا بیاورم:

۱- کسب اطمینان از نصب SfTS در TFS. این ابزار امکانات اسکرام را در TFS و Visual Studio فراهم می‌کند.

۲- اجرای ویژوال استودیو در حالت Admin.

۳- انتخاب گزینه New Team Project…‎ از پنجره Team Explorer.

۴- نام گذاری پروژه و انتخاب Template با نام Scrum for Team System و ادامه همه مراحل.

۵- راست کلیک روی اسم پروژه در Team Explorer و انتخاب گزینه‌های Team Project Settings و Group Membership.

۶- دابل کلیک روی گروه دلخواه و اضافه کردن کاربران مورد نظر از طریق Windows User or Group.

۷- باز کردن آدرس وبی TFS که معمولاً به صورت http://servername:8080/tfs/web/‎ است.

از اینجا به بعد باید مراحل مخصوص اسکرام دنبال شود. یعنی اسپرینت‌ها، Backlog Itemها، Taskها و… تعریف شوند. هر اسپرینتی هم باید به صورت work item ثبت شود و هم به صورت ساختار داخلی Iteration.

۸- اضافه کردن iterationهای مورد نظر بر اساس تعداد اسپرینت‌ها. دقت شود که برای تیم‌های کوچک فقط Team Sprint مهم است.

۹- بعد از مشخص کردن همه Iterationها چیزی شبیه به عکس زیر دیده خواهد شد.

۱۰- تعریف Releaseها، Sprintها و Team Sprintها بر اساس درخت Iterartion. وارد شدن تاریخ‌ها نباید فراموش شود. از این سه تا work item فقط نوع Team Sprint برای ما اهمیت دارد.

۱۱- تعریف رابطه Implemented by و Implements بین Releaseها، Sprintها و Team Sprintها.

۱۲- تعریف Backlogها (PBI) و  Taskها (SBT) و روابط بین خودشان و Team Sprintها.

۱۳- استفاده از Queryهای موجود برای مشاهده Work Itemهای تعریف شده.

۱۴- تکمیل تدریجی اطلاعات Work Itemها.

۱۵- استفاده از Sprint Burndown Chart و دیگر گزارشات برای کسب اطلاعات بیشتر از وضعیت پروژه.

۱۶- از Portal پروژه هم می‌توان استفاده کرده و به خیلی از اطلاعات و امکانات پروژه دسترسی پیدا کرد.

‫‫معرفی کتاب ALM with Visual Studio 2010

کتاب Professional Application Lifecycle Management with Visual Studio 2010 راجع به فازهای مختلف توسعه‌ی نرم‌افزار با استفاده از ویژوال استودیو ۲۰۱۰ و TFS صحبت می‌کند. فازهای مختلف توسعه‌ی نرم‌افزار که اصطلاحاً Application Lifecycle Management یا ALM نامیده می‌شود عبارت است از مراحلی که که از تحلیل و درک سیستم شروع شده، با مراحل طراحی، پیاده‌سازی و تست ادامه پیدا کرده و تا مرحله استقرار ادامه پیدا می‌کند. دیگر موارد مورد نیاز از جمله متودولوژی، سورس کنترل، مدیریت پروژه و… نیز جزیی از ALM هستند.

مجموعه Visual Studio 2010 و TFS 2010 با کمک هم، همه‌ی این مراحل را پوشش می‌دهند. یعنی شما با کمک این دو تا هم می‌توانید نمودارهای مختلف UML را که برای بخش‌های مختلف تحلیل و طراحی مورد نیاز هستند را تهیه کنید، هم مراحل کد نویسی، پیاده‌سازی و انواع تست را طی کنید و هم تمام نیازهای Source Control، مدیریت پروژه و… را انجام دهید.

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

بخش اول: معماری
معرفی امکانات Visual Studio 2010 برای تحلیل و طراحی سیستم. این بخش شامل توضیحاتی راجع به تحلیل، طراحی، معماری نرم‌افزار و مفاهیم مرتبط در UML بوده و به شما نشان می‌دهد چطور می‌توانید با استفاده از Visual Studio 2010 انواع و اقسام نمودارهای UML را تهیه کنید.

بخش دوم: برنامه‌نویس‌ها
معرفی خود ویژوال استودیو و امکانات مختلف آن برای برنامه‌نویسان از جمله: Code Analysis، Code Metrics، Profiling، IntelliTrace و کمی Unit Test.

بخش سوم: تست
معرفی انواع و اقسام تست از جمله Load Test، Web Performance، Manual Test، Coded UI Test و معرفی Lab Management.

بخش چهارم: TFS
معرفی معماری TFS و نحوه‌ی کار با Version Control و Build Engine آن.

بخش پنجم: مدیریت پروژه
معرفی امکانات مدیریت پروژه، استفاده از متودولوژی‌های و گزارشات مرتبط که همگی از طریق TFS مهیا شده‌اند.

آیا خواندن این کتاب مفید بود؟

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

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

‫چرا SVN بهتر از TFS است؟

دلایل خیلی زیادی برای این برتری وجود دارد. ولی فعلاً به این یکی بسنده کنید. فرایند پشتیبان‌گیری و برگرداندن پشتیبان‌ها (backup/restore) در svn خیلی ساده ولی در TFS خیلی پیچیده است.

برای پشتیبان‌گیری از مخزن SVN کافی است فولدر آن را در ویندوز کپی کرده و در جای مطمئنی نگه دارید. برای برگرداندن پشیبان هم کافی است فولدر پشتیبان را مجدداً در جای قبلی کپی کنید.

اما در TFS 2010 شما باید به کلی از کارهای admin ویندوز و  Sql Server مسلط باشید و برای انجام یک restore ناقابل مراحل زیادی را طی کنید. اگر باور نمی‌کنید نگاهی به لینک‌های زیر که همگی مربوط به فرایند backup/restore در TFS 2010 است نگاهی بیندازید.

Create simple CodeActivity for TFS Build 2010

Sometimes that you need to customize TFS Build 2010, you need to create a custom CodeActivity. A CodeActivity is written in C# and you can do what you can’t in TFS Build itself, there. The simplest way to create a custom CodeActivity, deploy and use it, is as follow:

1. Create a .Net 4.0 based Class Library project. CodeActivity exists in .Net framework 4.0 only.

2. Add a Code Activity to it by right click on the project, select Add New Item and navigating to Workflow tab.

3. Add a reference to “C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEReferenceAssembliesv2.0Microsoft.TeamFoundation.Build.Client.dll”.

4. Add “[BuildActivity(HostEnvironmentOption.All)]” as your CodeActivity’s class attribute.

5. Add desired arguments and codes.

6. Build the project.

7. Copy generated dll to “C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEPrivateAssemblies”. If you don’t do this, you will not be able to use Visual Studio to add your CodeActivity to any build process template.

8. Add generated dll to a specific location in TFS Source Control.

9. Open up your desired build process template.

10. Add generated dll to the toolbox by right clicking on empty space in General tab, select “Choose Items…”, click Browse, navigate to “C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEPrivateAssemblies” again and select your generated dll. After this you will see your CodeActivity there.

11. Drag Code Activity on the desired placed in process template.

12. Add any arguments that you want to be accessed via Build Definition to the template process and pass them to your CodeActivity’s arguments. To add any arguments to a template process, open Arguments tab in the bottom-left corner of the screen and add them there.

13. Check-in template process. If you don’t so, you will not see your added arguments in Process tab of build definitions.

14. Open Build Definition that uses this build process template. You will see any arguments that you have previously added to build process. You can set any value in them.

Note: Above addresses are based on a x64 installation.
Note: For more info refer to Jim’s guide and Ewald’s guide.

How to add parameter to Build process parameters?

If you have added some new Activity or CodeActivity to your build process template but you don’t want to edit template process each time you want modify properties of Activity or CodeActivity, you must add that parameter to “Build process parameters” list of your desired build definition. By doing this, there is no need to modify template process and check-in back it each time.

Jason has described this and has showed how you can do it by editing XAML file directly. But if you are searching for an easier way, follow these steps:

1. Open build process template.
2. Open Arguments tab at the bottom-left corner of the screen.
3. Add your parameters as “In” arguments.
4. Pass value of these arguments to properties of desired build/workflow activities.
5. Save and check-in template process.
6. Open up Build Definition that uses this template process.
7. Go to Process tab and navigate to Misc section. You will see your added arguments there, that are added as “Build process parameters”.
8. Fill your values there to be used by TFS Build.

Custom workflow activity’s problem with Visual Studio designer

After reading Jim Lamb’s guide for creating a custom workflow activity for TFS Build 2010, I created a project to create my own custom workflow activity too, by following Jim’s guides line by line. At the end, despite my correct custom activity, when I tried to use that in a typical template process by dragging it onto the workflow I just saw a deny symbol and couldn’t put my activity on that workflow.

After so many verifications of my custom activity and so many googling, I decided to add my activity by editing XAML file directly in notepad. Unfortunately when loaded the workflow in the Visual Studio again, a red label with message “Activity could not be loaded because of errors in the XAML.” was showing instead of my activity. So googled again and found Ewald Hofman’s solution. Based on his guides I installed my assembly in GAC and the red error message label disappeared. I was having still 2 more problems. First, Jim’s sample code was working with no problem, but my activity needed registration in GAC. Second, despite of disappearing red label, I was still unable to drag my activity to workflows, I was forced to edit XAML file directly.

After a whole challenging day, I realized that Jim’s sample assembly exists in C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEPrivateAssemblies previously! I don’t know how Jim’s ActivityPack has gone to that location but I know when I copied my custom activity’s assembly to that location, my 2 problem solved too. So I could use Visual Studio designer to drag my custom workflow activity into any workflow or template process I want.

Customizing build process in TFS 2010

If you ever has need to customize build process in Team Foundation Build 2010, you may noticed that there is several ways to do it while each way is suitable for a specific range of requirements:

1. Running external tools like batch files or ftp.exe or MSBuild Community Tasks via InvokeProcess or via MSBuild Activity.

2. Invoke .Net classes and methods like System.IO.File.Delete() via InvokeMethod.

3. Creating your own custom workflow activity for TFS Build 2010.

For our specific need that is synchronizing a remote server via FTP, none of first 2 ways is suitable. In first way, running external programs, this is very hard to synchronize a whole remote directory and its sub-directories just via ftp.exe and a bunch of batch file commands like FOR. In addition, this may impose dependency to external tools in the server.

In the second way, running .Net classes and methods, we have to create our own ftp utility or use third party tools like ftp.exe or MSBuild Community Tasks. In addition this causes using intensive usage of TF Build activities that’s not easy to copy to new Team Foundation builds in new projects.

Third and last way, creating your own activity is harder to implement but has many advantages over other ways including:

1. High flexibility because this is entirely written by yourself.

2. Maintaining is easier because all of your work is kept in a single Visual Studio project.

3. It is easier to deploy it in new team builds because it is simply just one single workflow activity.

4. It is easier to configure. You configure it via its arguments and variables. No need to modify template process itself.