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

Each TPC needs a separate Build Controller

If you are going to start using TFS 2010 please be aware that each TPC (Team Project Collection) needs a separate Build Controller.

For those who are intended to use TFS 2010 as their ALM engine, TFS 2010 can contain several TPCs. Each TPC can contain several Team Projects. Each Team Project is a regular space in TFS that contains Work Item Management, Source Control and Build automation. Build automation in each Team Project contains several Build Definitions that build project with several conditions. Each Build Definition is assigned to a Build Controller. A Build Controller is a build server that builds project using conditions defined in Build Definitions.

In other hands while defining a new Build Definition you must specify its Build Controller. Unfortunately with TFS 2010 you can not use Build Controller defined for say TPC number one for say TPC number two. Each TPC must have its own Build Controller.

Considering that a Build Controller is really a server, assigning a server to each TPC defined in TFS is not very applicable in most companies and teams. There is an article in MSDN blogs that shows a way to use a single Build Controller in several TPCs. As the article itself emphasis, this hack is not recommended for operational installations. Some people like us have been forced to use a single TPC for all Team projects. This work-around has many disadvantages like interfere of Team Projects, security issues, etc, but at least have solved the problem of need to several servers as Build Controllers.

See also:
My question in StackOverflow
Related content in TFS forum
Related content in GeeksWithBlogs
Jim Lamb’s hack for the problem

Continuous Integration with TFS

It’s a few months that I am dealing with continuous integration, automatic builds, TFS and Team Foundation Build deeply. Experiences during this period learned me some points that I’m glad to share with all:

1. Don’t assume anything about build agent. Specifically don’t assume any library is installed on the agent, any assembly registered in build agent’s GAC, any specific file/folder structure exists in build agent, etc. Otherwise you may encounter build breaks in other agents or at another time. Best practices here is to assume that build agent has just .Net framework installed on it and nothing more.

2. Always add assembly references from source control maintained dlls in same project and just as relative path not as absolute path. Otherwise you may encounter build breaks.

3. Never ever let anyone direct access to live machine that is dedicated to install continuous integration results instantly, specifically for web application projects. Because someone may manually add/modify a file/folder in the web application path. So you may end with a software that needs manual modifications that are never documented nor automated.

4. Automate database creation. Either via maintaining database creation scripts in source control or with help of ORM’s database auto generating feature.

‫ALM چیست؟

ALM یا Application Lofecycle Management به طور اختصار یعنی مدیریت فرایند تولید نرم‌افزار با استفاده از ابزارهای کار تیمی مثل Source Control، Issue Tracking، Build Automation و… در واقع با کمک ALM کلیه امور مربوط به توسعه نرم‌افزار در یک تیم تولید نرم‌افزار به طور یکپارچه مدیریت و هدایت می‌شود. در اینجا منظور از امور تیم مواردی مثل زیر است:

۱- Source Control Management
‫۲- Issue/Bug/Feature Management
‫۳- Build Automation
‫۴- Architecure/Design (UML)‎
‫۵- Test: Unit Test – Acceptance Test – Load Test – …
‫۶- Release Management
‫۷- Deploy Management
‫۸- Project Management
‫۹- …

عکس زیر روابط این اجزا را به خوبی نمایش می‌دهد:

هر تیمی که همه این امور را داشته باشد و بتواند آنها را با کمک ابزارهای مناسبی مدیریت کند یعنی ALM دارد. ابزارهای ALM می‌توانند کاملاً یکپارچه باشند. مثلاً Visual Studio Team System که ابزار ALM مایکروسافت است، شامل عمده ابزارهای مورد نیاز مثل Source Control، Work Item Management، Buid Automation، Test و… است. ابزارهای ALM می‌توانند از جاهای مختلفی آمده ولی باز هم یکپارچه باشند. مثل وقتی که از ابزارهای SVN برای Source Control، از NAnt برای Build، از Jira برای Issue Tracking و… استفاده شود.

ALM اصطلاحی است که این روزها بیشتر از روزهای قبل مورد استفاده قرار می‌گیرد. مثلاً مایکروسافت که در نسخه‌های ۲۰۰۵ و ۲۰۰۸ ویژوال استودیو از اصطلاح Team System استفاده می‌کرد، تصمیم گرفته در نسخه ۲۰۱۰ ویژوال استودیو به جای Team System از همین واژه Application Lifecycle Management استفاده نماید.

منابع:
ویکی‌پدیا
کتاب ALM with VS 2010