TFS و Source Controls

السلام عليكم ...

الصراحة أنا تعرفت على git على يد الأخ حسن. لم أكن افهم الفائدة أو كيف استخدم تلك الأدوات "المعقدة" المستخدمة لإدارة المشاريع.

لذلك لن أدخل في النقاش من هذه الناحية,

لدي فقط تعليق بسيط:

اقتباس

ثالثاً أنت قلت أن الأدوات مفتوحة المصدر قام ببرمجتها مبرمجين .. فأنا لا أعرف هل مغلقة المصدر قام ببرمجتها أحد أخر غير المبرمجين ؟! لا بالطبع .. بل أزيدك من البيت شعراً .. إن الـ TFS تعمل به ميكروسوفت داخلياً وهو ما يسمى بالـ Dogfooding .. وهو مصطلح يعني أن الشركة المنتجة لبرنامج معين تقوم بتطبيقه في مؤسستها وهذا يعطي درجة اختبار أعلى .. خاصة في ميكروسوفت:

1) عدد المبرمجين ومن يعاونهم في كل الأدوار هائل ..

2) المبرمج يعمل بأداة صنعت من أجل المبرمج

الـ Dogfooding لها إيجابيات, كما أن لها سليبات. هناك شخص يسمى jalf كتب عن الموضوع,و كيف أن التغني بالموضوع هو أمر دعائي أكثر منه أمر ذو فعالية حقيقية.

تحياتي...

لا أعرف لماذا يتم النظر الى البرامج التجارية بهذه النظرة الدونية؟؟؟؟

وعليكم السلام ورحمة الله وبركاته

جزاك الله خيراً أخ خالد على الإضافة الرائعة ..

رأي jalf يستحق الاحترام .. وإن كنت أختلف معه في مقارنة Visual Studio ببعض الأدوات التي لا يمكن أن تقارن به .. أو الـ TFS بـ git وغيره لأنه لا مجال للمقارنة لأن التطبيقين لا يقدموا نفس الخدمة! بل إن git على سبيل المثال يقدم خدمة واحدة من خدمات ال TFS .. فإذا كان على jalf أن يقارن بينها كان يجب أن يحدد أنه يقصد الـ source control.

ولا أظن أن ميكروسوفت كإحدى مؤسسي البرمجة في العالم أنها لا تعلم بهذا الأمر أقصد مشاكل ال dogfooding وعيوبه .. وأتفق تماماً مع jalf في أن ال dogfooding لا يجب أن يكون هو الطريقة الوحيدة لاختبار البرنامج .. ولم أسمع في يوم ما أحد متحدثي ميكروسوفت يزعم هذا حتى jalf نفسه في أخر المقال أقر بهذا .. ولكني ما زلت أرى أن ال dogfooding مع بعض الطرق الأخرى يصل بك إلى مرحلة جيدة قد لا تصل لها إذا انتظرت رد عملاءك أو تعليقهم فقط على المنتج عندما يستخدمونه!

جزاك الله خيراً على الإضافة.

motamayez كتب:

لا أعرف لماذا يتم النظر الى البرامج التجارية بهذه النظرة الدونية؟؟؟؟

لا أظن هذا أخي المتميز .. فلا أظن أن أحداً ما قد يفكر بهذا .. لأننا أو معظمنا يعمل على أنظمة تشغيل أو برامج ليست مجانية .. وبدون البرامج التجارية لن تكون هناك صناعة برمجة أصلاً وستنقلب إلى هواية .. حتى أن بعض برامج مفتوحة المصدر إذا كانت مجانية التنزيل والتشغيل ولكنها في بعضها ليست مجانية الدعم .. وهكذا

المسألة والتي لا أراها منطقية .. هي نقطة الصراع بين مطوري البرمجيات مغلقة المصدر لاعتمادها في الغالب أو أن أكثريتها تعتمد على منصات ميكروسوفت البرمجية .. وبين مطوري برامج مفتوحة المصدر وهي كثيرة جداً

فهذا الصراع أنا لا أحبه لأنه يفتقد للمنطق وللعلم وللنظرة المستقبلية ولكني أركز كما ذكرت من قبل على التكنولوجيا وهل ستفيدني أو لا ..

فأنا مثلاً من محبي Google جداً وميكروسوفت جداً ومعجب جداً بالتطور والصراع الدائر بينهما الذي لربما يكون غير مرئي لأن هذا كله يصب في مصلحة المطورين ومستخدمي الحاسبات وهذا شيء رائع جداً في نظري وهذه قمة المتعة .. وليس هناك أي متعة في أن تكون هناك مشاجرات أو صراعات بين فريقي المستخدمين على الجانبين.

فلا أرى أنه يوجد أي نظرة دونية ولكن قد تكون رواسب الصراعات المختلفة التي ذكرتها من قبل قد تسيطر علينا أحياناً

ما قصدته انه مطور من قبل المبرمجين بحسب احتياجاتهم هم و ليس حسب سياسة تجارية او دعائية لشركة ما.

هذا الامر له ايجابياته و له سلبياته: ايجابياته ان ادوات البرمجة و التطوير فائقة المرونة و توفر العديد من الادوات اللتي تسهل عمل المبرمج. السلبية ان الادوات الغير البرمجية لا تجد نفس القدر من الاهتمام بالضرورة.

الـ build machine موضوع منفصل عن الـ source control و هو ليس ضروري جدا على اي حال, المفروض ان الشخص قبل ان ينشر الكود (قبل ان يعمل push للمستودع الرئيسي) ان يقوم هو بتجريب ما قام بتغييره و ان يشغل الـ tests على جهازه قبل تلويث المستودع الرئيسي بكود لا يتجاوز الاختبارات.

سؤال, هل tfs يدعم الـ distributed development؟ بمعنى ان المبرمج يمكن ان يقوم بعمل local commits و ان يقوم بعمل merge بين نسخة المستودع الرئيسي و نسخته المحلية على جهازه؟

اذا لم يكن يدعم هذه الخاصية فهو لا يستحق اي ضجة ولا ان يعيره احد اي اهتمام.

بعد شيء من البحث في جووجل يبدو ان TFS نظام مركزي مثل svn، يعني كل شي يتم عبر السرفر, حتى الـ branch

بمعنى آخر فهو لا يدعم الـ parallel development بشكل حقيقي

مستمتع بالنقاش ومتابع من البدايه.. ,عملت كثيرا باستخدام SourceSafe لكن للأسف لم أعمل على TFS

ولكن.. هل تقصد هذه النقطه يا أخ حسن..

اقتباس

To perform any version control operations, you need a workspace with a working folder. A workspace represents the client-side copy of the artifacts that are under version control on the Team Foundation Server, and it serves as an isolated area to perform your work. Each user can have multiple workspaces on a client machine. Each workspace, in turn, supports multiple mappings between a local file path, known as a working folder, and a path in the version control repository.

المصدر.. http://msdn.microsoft.com/en-us/magazine/cc163498.aspx

hasan_aljudy كتب:

ما قصدته انه مطور من قبل المبرمجين بحسب احتياجاتهم هم و ليس حسب سياسة تجارية او دعائية لشركة ما.

هذا الامر له ايجابياته و له سلبياته: ايجابياته ان ادوات البرمجة و التطوير فائقة المرونة و توفر العديد من الادوات اللتي تسهل عمل المبرمج. السلبية ان الادوات الغير البرمجية لا تجد نفس القدر من الاهتمام بالضرورة.

الـ build machine موضوع منفصل عن الـ source control و هو ليس ضروري جدا على اي حال, المفروض ان الشخص قبل ان ينشر الكود (قبل ان يعمل push للمستودع الرئيسي) ان يقوم هو بتجريب ما قام بتغييره و ان يشغل الـ tests على جهازه قبل تلويث المستودع الرئيسي بكود لا يتجاوز الاختبارات.

سؤال, هل tfs يدعم الـ distributed development؟ بمعنى ان المبرمج يمكن ان يقوم بعمل local commits و ان يقوم بعمل merge بين نسخة المستودع الرئيسي و نسخته المحلية على جهازه؟

اذا لم يكن يدعم هذه الخاصية فهو لا يستحق اي ضجة ولا ان يعيره احد اي اهتمام.

الTFS يدعم كل هذا فببساطة يمكنك عمل كل ما تريد من Branches على Hierarchy معين مثلاً يكون لديك Main Branch و يتفرع منه Dev Branch و يتفرع من الDev branch فروع لكل مطور اذا أراد, و يمكنك ضم الBranches في اي وقت (Merge) و عمل Resolve للConflicts و ... الخ

الBuild System مهم جداً لأنك مع وجود عدد كبير من المبرمجين لا يمكنك أن تثق أن المبرمج قام على جهازه بعمل الاحتياطات اللازمة أو ما يحدث كثيراً هو أن ينسى أن يقوم بعمل Check in لكل الملفات و هنا و بالرغم من أن كل شئ تمام على جهازة فقد أصبح الكود الرئيسي مكسور و لو لا تملك حل Continuous Integration فلن يمكنك اكتشاف هذه المشاكل بسهولة, كما أن لا تستطيع أن تجد نسخة البرنامج Binaries من الاسبوع الماضي مثلاً و تقارن نتائج الاختبارات على نتائج هذا الأسبوع مثلاً.

كل مرحلة لها أهميتها و لا يمكن الاعتماد على مرحلة واحدة فقط.

الTFS يدعم الDisconnected أو الOffline Mode فيمكنك ان تعمل كما تريد دون الحاجة للسيرفر في أي شئ, ثم تأتي في أي وقت و تربطه بالسيرفر.

و أيضاً لا تحاول أن تقارن Git بTFS فنظام Git مصمم ليعمل على مشاريع الOpen Source في حين أن TFS مصمم للعمل في الشركات,

اقتباس

و أيضاً لا تحاول أن تقارن Git بTFS فنظام Git مصمم ليعمل على مشاريع الOpen Source في حين أن TFS مصمم للعمل في الشركات,

كلام فاضي, git مصمم لادارة المشاريع البرمجية، ليس للامر علاقة بكون هذه المشاريع مغلقة او مفتوحة.

اخ احمد، ما قصدته هو هذا:

http://landheer-cieslak.com/wordpress/microsoft-team-foundation-server-vs-git/

As TFS is a centralized system, it has to talk to the server for everything you might want to do, which includes creating branches, merging, checking in/out, etc.

I had never realized how utterly brain-dead that really is! If there is any load on the server – which there is bound to be if you’re working with a fairly large development team – TFS slows down to a crawl.

بالنسبة لما طرحه الأخ حسن .. وأجاب عنه الأخوة ...

الـ TFS يدعم الـ Parallel development ويدعم الـ distributed Development وهذه المزايا مزايا أساسية Basic في الـ TFS

بخصوص ال distributed development فقد رد الأخ متميز عليها وأوفى وكفى جزاه الله خيراً وكذلك الأخ حازم وأشدد على نقطة الـ Offline mode فلا يجب أن تكون متصلاً بالسيرفر لتعمل على الجهاز .. ولكن اعمل كما شئت وعند عودة الاتصال بالسيرفر مباشرة سيقوم السيرفر بحساب كل التغييرات التي قمت بها على جهازك ويعطيك أي ملاحظات أو مشاكل قد تظهر ...... إلخ

أما بخصوص ال Parallel Development .. أولاً علينا أن نشرح ما هي الـ Parallel Development لأنه قد يكون المصطلح في بيئة عملنا غير بيئة العمل التي تعمل عليها مثلاً: نحن نقول Check in وأنت تقول Push وكلاهما واحد !

الـ Parallel Development بكل بساطة هو:

ومن هذا المنطلق أقولها وبكل بساطة هذه الميزة موجودة منذ الرعيل الأول للـ TFS منذ وقت ظهوره ... وتم تقويتها جداً في الإصدار الأخير الذي سيصدر بإذن الله غداً - بإذن الله - وانظر هذا الفيديو الذي يتحدث عن ال Parallel Development في الإصدارة الجديدة .. من هـــنـــا فستجد في الفيديو على الرغم من قوة هذه الميزة في الـ TFS إلا أنهم وجدوا أنها بعض الـ Pain كما يقولون .. لذا قاموا بتطويرها كما سيظهر الفيديو ..

وفي النهاية كل هذا يصب في مصلحة موضوع كبير اسمه Branching Strategies وسأتكلم عنه لاحقاً بإذن الله .. :)

hasan_aljudy كتب:

كلام فاضي, git مصمم لادارة المشاريع البرمجية، ليس للامر علاقة بكون هذه المشاريع مغلقة او مفتوحة.

اخ احمد، ما قصدته هو هذا:

http://landheer-cieslak.com/wordpress/microsoft-team-foundation-server-vs-git/

As TFS is a centralized system, it has to talk to the server for everything you might want to do, which includes creating branches, merging, checking in/out, etc.

I had never realized how utterly brain-dead that really is! If there is any load on the server – which there is bound to be if you’re working with a fairly large development team – TFS slows down to a crawl.

هذا رأي الكاتب وأنا أحترمه .. ولكني لم ألاحظه أبداً .. ولا أجد بطئاً في أي شيء ... حتى مع تزايد عدد الفريق .. وهو لم يخبرنا بكفاءة السيرفر الخاص به حتى نستطيع تقييم كلامه! إذاً كلامه لا معنى له بدون هذه الأرقام والـ Benchmarking ...

أيضاً أنا أعلم أن ال Branching يحتاج في ال TFS إلى عمليتين ليكتمل ... ولكن في TFS 2010 يختلف الوضع كما أوضحت في الملف المرئي في مشاركتي السابقة حتى هذا الشخص Matt والذي أظنه من فريق عمل TFS 2010 والله أعلم .. أجاب على صاحب المقالة بالآتي:

في نقطة أخرى الـ Baseless Merge هي من أسوأ النقط التي رأيتها في حياتي .. والتي أشار إليها صاحب المقال واعتبرها نقصاً في ال TFS والمشكلة أنها موجودة وهو لا يعلم! ولكني أعتبرها في مجال البرمجة شيء سيء جداً ولا يستخدم إلا عند الضرورة القصوى كعملية إصلاح أو ما شابه.

لا اعرف لماذا ترد بعنف يا اخ حسان و تصف كلامي بالفارغ لو لا تصدق ان GIT مصمم أساساً للمشاريع مفتوحة المصدر ابحث عن محاضرة Linus travolds التي ألقاها في جوجل و التي تتكلم عن git بالتحديد و لماذا بدا المشروع و ما هي اهدافه

الرجا الحفاظ علي جدية الموضوع 

لا تخف, شاهدت محاضرة لينوس عشرات المرات ;)

كلامك ان git مصمم للمشاريع المفتوحة بالفعل كلام فاضي لانه لا يستند على شيء، و حتى في المحاضرة اللتي اشرت اليها لا يوجد ما يشير اليه, بل العكس, لينوس يدعو جميع الشركات لاستخدام git لانه احسن الموجود من وجهة نظره.

سؤال آخر عن tfs, هل هو مجاني؟ هل هو مناسب و سهل في الاعداد و الاستخدام بحيث يستخدمه المبرمج على مشاريعه الشخصية؟

1 - طبعاً TFS ليس مجاني ..

2 - أنا أستخدمه في مشاريعي الخاصة منذ أكثر من عامين إلى ثلاثة أعوام الآن وهو على جهازي الذي أرسل منه الآن وبالطبع فأنا فبيئة عملي تدعم الـ TFS وأعمل به منذ الأيام الأولى في حياتي المهنية والخبرة هنا تختلف في أن تعمل به بمفردك فلن تظهر كل قوته الحقيقية .. وأن تعمل به ضمن فريق صغير ستظهر بعض فوائده وأن تعمل به ضمن فريق عمل كبير سيظهر لك مدى قوته التي لا تضاهى.

3 - تنزيله ليس مجرد إلا أن تضغط على الـ Installer وتتبع الخطوات التي ستظهر لو كنت ستقوم بتشغيله على Machine واحدة فلن يأخذ الأمر دقائق .. أما لو كنت تريده يعمل بنظام الـ Multi-Tiers فستحتاج لخبرة لكي تقوم بتنزيله في مؤسستك .. فهو مصمم ومدعم ليناسب جميع البيئات

أخى أحمد : أنا اقصد دعم التكامل مع منتجات تكمل دورة الحياة مثل Quality management و requirements document و هى متوفرة فى منتجات مثل RQM و RRC.

- اود الاستفسار منك عن التالى :

* Build machine - لم اقتنع بجدواها حقيقة و ان كانت بالفعل كما اوضحت تقوم بعمل بناء للكود لكل مره يتم عمل فيها ايداع للكود فى الستريم فهذاغير جيد و مكلف ولايغطى كل شئ خاصة مع الاكواد المفسرة مثل Javascript فكيف سيتم عمل بناء و اكتشاف للاخطاء لها ؟ مااعرفه عن RTC فى هذا الموضوع هو انه يقوم بعمل Static Analysis للكود لاكتشاف الاخطاء و التحذيرات لكن لايقوم بعمليه بناء كاملة فى كل مرة. لم افهم ايضا كلامك جيدا بعلاقته مع BVT و Unit Tests فى الاغلب ربط الاوتوميشن تيست مع السيرفر لايحتاج الى Build Machine و يمكن بادوات بسيطة للغاية عمل اجراء دورى للاختبارات و ارسال رسالة للمبرمج المعنى بالخطأ (Bugzilla , Git, Test Unit Framework, ... , etc) وهو شئ متوفر و ممكن بادوات مفتوحة المصدر دون الحاجة الى اى برنامج تجارى.

* مالذى يقدمه TFS كجديد فى موضوع Branching Strategies ؟ من كلامك لاارى اى شئ جديد عن الموجود حاليا فى اغلب برامج Source Control

*موضوع Parallel Development - هل يدعم TFS امكانية الربط مع Cross-repository - حتى الان ماافهمه انه Domain-Centric Repository و هل يدعم خواص مثل Discovery لسيرفرات TFS فى اماكن او فروع مختلفه ؟

أنا افهم من كلام اخى حسن انه يقصد المزايا اللتى تهم المبرمج او المطور. أنا فى رأى ان افضل ميزة فى RTC من ناحية التطوير هى Shared Streams حيث ان اى مطور يكون له امكانية عمل Streams خاصة به (Local Workspace Stream) و يستطيع ايضا مشاركتها مع عدد معين مع المطورين دون اى مساس لكود المستودع الرئيسى مما يسمح لمن يراجع الكود امكانية التعديل و المشاركة فى مستودع خاص. و من ثم عندما يقوم بعمل Merge مع المحتوى الرئيسى - حسب صلاحيته يمكن للTech. Leader مراجعة Work Changesets و الموافقة عليها او رفضها او طلب تعديل و التعليق على مايريد تعديله. لااعرف ان كانت هذه الميزة متاحة فى TFS أم لا لكن ان كانت تدعم بشكل فعلى Parallel Development فهذه المميزات لابد ان تكون متوفرة . باقى المميزات فهى للشركات الكبيرة و اللتى تمتلك اكثر من فرع فى اكثر من مدينة خاصة فيما يتعمل يشهادات الجودة و غيره من الامور الادارية.

والسلام ختام

اذا كنت تريد TFS مجاني يمكنك استخدامه على Code Plex

سأرد في البداية على الأخ أحمد .. ثم الأخ متميز

بخصوص ما أورده الأخ أحمد سأورده في نقاط:

1) بخصوص الـ Build Machine .. ينصح خبراء البرمجة دائماً بتطبيق مبدأ الـ Continuous Integration and Build Automation .. وهو يتمثل في الآتي:

• يُنصح أن يعمل المبرمجون على Branch يسمى مثلاً ال Dev Branch وهذا الفرع يعبر عن الـ unstable code والذي قد يعمل عليه مبرمج واحد أو أكثر من مبرمج أو ربما عدة فرق .. وقد يكون هناك أكثر من Dev Branch وهذا لكي يتم عزل الكود المتغير الذي قد يحتوي على أخطاء أو ما زال تحت التطوير.
  
• ويُنصح أيضاً بوجود Branch له مسميات عديدة مثل Main أو Trunk وما إلى ذلك وهو ما يحتوي على الـ Last Stable Code وكل الفروع Dev منبثقة من الـ Trunk أو الـ Main
  
• نأتي هنا لفائدة الـ Build Machine والتي ستقوم بدور الـ Continuous Integration and Build Automation .. فينصح أن كل فرع Dev يجب أن يكون مرتبط بمهمة لل Build Machine بحيث أنه لو طرأ تغيير Check in على هذا الفرع تقوم ال Build Machine بتنفيذ هذه المهمة .. وهذه المهمة قد تكون Build on every check in وقد تكون Build each day at specific time وغير ذلك من الاختيارات التي يستطيع الفرد التحكم فيها .. ومن أفضل هذه المهام لل Dev هي Build on every check in وهذا لكي يتوفر لدى جميع المبرمجين نسخة صحيحة 100% من ناحية الـ Syntax حتى لا يحدث Break للكود أو كسر للكود فيعمل الجميع بنجاح
  
• أولاً هذه ليست عملية مكلفة لأنك لست أنت الذي تقوم بها ولكن machine أخرى أو أكثر من machine تقوم بكل هذا بالنيابة عن أفراد المشروع .. ثانياً في كل مهمة لل Build machine يمكنك تحديد بعض المهام الفرعية والتي لا تعمل إلا بعد الانتهاء من المهمة الأساسية وهي Building the code ومن المهام الفرعية كالأتي: أن تأمر ال machine بتشغيل كل ال Unit Tests الموجودة في المشروع التي يمكنك كتابتها بأي Framework مثل MS Unit Test أو NUnit وما شابه لكي يتأكد جميع أفراد المشروع أنه لم يتم التعديل على كود معين أدى إلى كسر ال specifications المحددة عن طريق ال unit tests وقد يسأل سائل .. لماذا وأنا أستطيع أن أقوم بهذا على جهازي قبل أن أقوم بعمل Check in أرد وأقول أنه قد ينسى المبرمج أن يفعل ذلك مما يؤدي إلى خطر لن يمكنك اكتشافه بسهولة بعد ذلك خاصة لو تراكمت التعديلات بعد ذلك وأيضاً أقول لأنه ليس كل ال unit tests من الممكن أن تعمل على أجهزة المبرمجين فهناك أنواع أخرى تأخذ وقت طويل لن يستطيع المبرمج الانتظار حتى تنتهي فهذا مضيعة للوقت. ومن المهام الفرعية أيضاً هي ال Static Code Analysis وهي عبارة عن تحليل الكود والتأكد من أنه مكتوب بطريقة سليمة وإن لم يكن يتم طرح اقتراحات عن طريق ال compiler لكي يصلح من نفسه وهو عن طريق البرنامج الشهير FXCop المدمج مع نسخ VS منذ أعتقد 2005
  

هذا بخصوص الاستفسار الأول ..

2) أما الاستفسار الثاني:

بخصوص الـ branching strategies فهي أفكار لتنظيم الـ Source control ولا علاقة لها بتكنولوجيا أو برنامج بعينه كالـ TFS أو git وما إلى ذلك! ولكن الـ TFS يقدم الكثير من الأدوات التي تساعد وبقوة على تطبيق هذه الأفكار دون عناء وتعب .. ويمكن مشاهدة الفيديو الذي أرسلته في مشاركة سابقة رداً على الأخ حسن لتعلم ما أقصد .. أما بخصوص الـ Branching Strategies قد أعود لها في موضوع منفصل بعد ذلك.

3) أما الاستفسار الثالث:

بخصوص الـ Cross-Repository .. حقيقة أنا لا أعلم مقصدك بخصوص هذه الجملة .. فكما قلت من قبل قد تكون هناك بعض المصطلحات في بيئة العمل الخاصة ببعض التكنولوجيات المختلفة والتي لها مرادفات في بيئات عمل أخرى .. لذا أطلب منك شرحاً للمصطلح لكي أعطيك إجابة صحيحة :)

وأما عن أن الـ TFS يدعم خاصة الـ Discovery .. فهو نعم إذا قمت بإدخال اسم الـ Machine أو الدومين المتصل بالـ machine المتواجد عليها ال TFS عندئذ يقوم ال client بالتحدث مع السيرفر ويتم إضافته مباشرة إن كان لك صلاحيات ..

فال TFS يعتبر من أقوى البرامج التي توفر الصلاحيات والأمن إلى مستخدمي ال Source Control والذي لم أره من قبل أو أسمع به بمثل التفصيل الموجود في ال TFS فعلى سبيل المثال يمكنك أن تمنع بعض المبرمجين من برمجة أشياء معينة في فرع معين .. أو تسمح لهم بالدخول لملف معين دون أخر .. وهكذا ولكن هذا تبسيط مخل جداً لأن الموضوع أكبر من جملتين

أما بخصوص Local workspace فهي مدعمة بشكل كامل وكافي في ال TFS ويمكنك أيضاً مشاركة هذه ال workspaces عن طريق Shelv/unshelv المتوفرة في TFS

وجزاك الله خيراً :)

motamayez كتب:

اذا كنت تريد TFS مجاني يمكنك استخدامه على Code Plex

هذا صحيح ولكن هناك شروط لاستخدام Codeplex على ما أتذكر وللأسف هذا من الذاكرة ويمكنك الرجوع لها .. هو أنه لابد أن يكون الكود المكتوب مفتوح المصدر، وأن يتم نشره في مدة لا تزيد عن شهر وإلا سيتم حذف ال account ..

والله أعلى وأعلم

أخى أحمد : تعليقى على ردك على استفسارى كالتالى :

1- Build Machine فى اغلب المشاريع هى شئ منفصل كونه مدمج مع سيرفر TFS شئ ليس بالعملى و هذا مااقصد بمكلف على جهاز سيرفر واحد. ماتتحدث عنه يمكن عمله بدون الحاجة الى TFS - أشرت الى مبدأ Continuous Integration and Build Automation و لكن لم توضح تحديدا ماللذى يوفره TFS خلافا عن الوسائل التقليدية.

* تحليل الكود يتضمن ايضا كشف اخطاء التنفيذ فى اللغات المفسرة مثل JS و التى لن تكون متاحة باسلوب البناء. و هناك العديد من المكاتب مفتوحة المصدر التى تساعد على فحص كودك و تنظيفه قبل عمل اصدار له.

- متى يكون Build Machine مفيدا فى وجهة نظرى : اذا تضمن ادوات جيده لـ Traceability و Instrumenting غير ذلك فالوسائل التقليدية اسهل و اوفر ايضا.

2- بعدما قرأت عن Parallel Development فى TFS اعتقد ان كلمة Branching مربكة نوعا ما. وواضح وجود مصطلحات كثير مختلفه.

3- مااقصده هل يمكن ان اقوم بفصل أجزاء من مشروع على اكثر من سيرفر TFS بشكل منفصل و اقوم بدعم تخاطب بين السيرفرات فى عمليه مثل Daily Building و هل توجد specifications للـ Cross-Communication across TFS servers.

أخي أحمد ..

إلى الآن أنت لم يصلك المعنى الصحيح للـ build machine

أولاً: الـ build machine ليست شرطاً أن تكون هي نفس السيرفر الذي يعمل من خلاله ال TFS وحتى وإن كان هذا فلا مشكلة ولا ضغط في هذا على الإطلاق

ثانياً: ال TFS يمكنك أن يكون معك أكثر من build machine في نفس الوقت وقد تقوم كل منها بمهمة لأن هناك مشاريع ضخمة يمكنك توزيع المهام على أكثر من build machine

ثالثاً: كونك معتقداً أن ال build machine ودمجه مع TFS شيء ليس بالعملي .. فهذا رأي غير صحيح لأنه أولاً ال TFS يتيح لك أن تقوم بتنزيله أو لا .. كما أنه Fully integrated مع بيئة تطوير ميكروسوفت مما يجعله الخيار الأول والأقوى لهذه البيئة من أي أداة أخرى وأيضاً لأنه أفضل من Configurations hassle أو intercommunication mess بين الأدوات الخارجية وبعضها البعض فهو out of the box يعمل بدون أي ربط أو تعديل

ذكرت في كلامي أن تحليل الكود مهمة من مهمات ال build machine يمكنك إضافتها ولكن هذا ليس معناه أنك لا تستطيع أن تقوم بها بدون ال build machine ويمكنك استخدام تحليل الكود عن طريق ال Visual Studio مباشرة ..أما بخصوص ال traceability و ال instrumenting فهي موجودة في ال visual studio tester edition كخصائص basic وهي يمكن ربطها وبكل سهولة مع ال build machine وال TFS وحفظ النتائج على السيرفر بكل سهولة حتى يستطيع الفريق الرجوع لها في أي وقت.

لا أرى إرباكاً في مسألة ال parallel development .. فال branching مصطلح ثابت في كل وسائل ال source control وليس شيء مخصص لل TFS ولكن طريقة التطبيق تختلف من مكان لأخر .. بالظبط كطريقة كتابتك للكود يختلف من شخص لأخر .. ولكن الأسس واحدة

بخصوص ما ذكرت من تخاطب السيرفرات مع بعضها البعض ... لا يحتاج ال TFS لخاصية مخاطبة سيرفر أخر .. لأنك بالفعل تستطيع تقسم المشروع الواحد على أكثر من مشروع داخل ال TFS وهو مصطلح Team Project والذي يمكنك من ربط كل هذه المشروعات بطريقة سلسة جداً عن طريق Build machine أو machines فلا مشكلة في ذلك أبداً ... وهذا على اختلاف أعضائهم وأماكنهم في العالم ... إلخ

أخى أحمد :

الان افهم ان Build Machine هى كيان مستقل و يتم ربطه مع TFS و الميزة كما اشرت هنا انه Fully Integrated. لاتوجد ميزة حقيقية هنا بخلاف تكامله مع الادوات المتاحة. سؤالى الان : هل يدعم TFS ربط مع طرق Building مختلفة او نقول Build Machine مطورة من شركة اخرى ام انى مجبر على استخدام Build Machine الافتراضية ؟ intercommunication mess موضوع مختلف و لايمكن ان نقول اننا لاندعم التكامل بين منتجات اخرى بهدف تلافى هذه المشاكل و هذ المشاكل تحل مع وجود specifications واضحة.

نأتى لنقطة traceability و ال instrumenting - كيف يتم عمل Execution Traces Analysis و هل يدعم اكتشاف الاخطاء التى تحدث فى الكود التنفيذى و ربطها مع السورس كود. و فى هذه الحاله هى ليست مدعمة فى TFS بل مدعومة من خلال منتج اخر مستقل(visual studio tester edition). لو نتكلم عن ربط Build Machine و تكامله هل يمكن ان اربطه مع مكتبة مجانية و مفتوحة المصدر مثل TPTP (أنا هنا اتكلم انى مطور استخدم Eclipse وقمت بربطه مع TFS و اريد استخدام مميزاته و مع اقل تكلفة ممكنة).

* بالنسبة للـ Branching - المحتويات التقنية الخاصة بـ TFS تشير الى Private Branch للمطور. هذا غير شائع بالنسبة لى و الشائع اكثر Private Stream او Scoped Stream. كلمة Branching تستخدم اكثر عندما يتم عمل تجميد للكود Code Freezing و عمل Code splitting الى فرع اخر. و فى هذه الحالة الفرع القديم يكون Restricted. لكن ان نقول Branch لمطور هذه غريبه على و مربكة لي و هذا مااقصد ان يوجد ارتباك فى التفسيرات للكلمة.

* أنا اتكلم عن فريق يعمل فى مدينة و له TFS لمشاريعه و فريق فى مدينة اخرى و له TFS. السيرفرين فى منطقتين مختلفتين تماما. هل ماتقترحه عمل سيرفر موحد للفرعين يعمل عليه الفريقين. فمن المؤكد انه هناك حاجة الى Cross-Repositories و من خلال ماقرأته فيوجد قصور فى TFS انه مقصور على 3600 شخص. كيف يمكن التغلب على هذا القصور بدون وجود Cross-communication.

اقتباس

الان افهم ان Build Machine هى كيان مستقل و يتم ربطه مع TFS و الميزة كما اشرت هنا انه Fully Integrated. لاتوجد ميزة حقيقية هنا بخلاف تكامله مع الادوات المتاحة. سؤالى الان : هل يدعم TFS ربط مع طرق Building مختلفة او نقول Build Machine مطورة من شركة اخرى ام انى مجبر على استخدام Build Machine الافتراضية ؟ intercommunication mess موضوع مختلف و لايمكن ان نقول اننا لاندعم التكامل بين منتجات اخرى بهدف تلافى هذه المشاكل و هذ المشاكل تحل مع وجود specifications واضحة.

1) أريد أن أوضح لك فكرة عمل ال Build Machine عن طريق هذا الرسم من موقع ميكروسوفت

2) نعم بالطبع يمكن دمج أداة third party مع ال team foundation هذا لأنني نسيت أن أخبركم أن ال Team foundation يحتوي على extensibility model تمكن المبرمجين من التحدث إليه وأخذ بيانات منه أو برمجة plugins عليه .. وهذا مثال على ما أقول من هــــنـــا

اقتباس

نأتى لنقطة traceability و ال instrumenting - كيف يتم عمل Execution Traces Analysis و هل يدعم اكتشاف الاخطاء التى تحدث فى الكود التنفيذى و ربطها مع السورس كود. و فى هذه الحاله هى ليست مدعمة فى TFS بل مدعومة من خلال منتج اخر مستقل(visual studio tester edition).

كلمة traceability كلمة عامة وعائمة وعندما أجبت عليها كنت أعني ال traceability matrix والذي يمكنك من معرفة أي requirement مع أي use case مع أي task إلخ إلخ ليسهل لك مهمة التأكد من تطوير كل المهام .. أما ما تقصده أنت الآن في ردك بعد التوضيح هو أداة تقم باختبار كل ال execution paths الممكنة واختبارها وهو ما يسمى بال White box testing ولا أعلم هل هذا ما تقصده أم لا .. ولكن نعم يوجد أداة من إنتاج ميكروسوفت وتدعم الربط مع TFS واسمها Pex ومن الممكن أن تقرأ عنها هـــنـــا أو من المكان الأصلي للأداة من هــنـــا

أما ما كنت ذكرته بخصوص ال Instrumenting فكنت أقصد لكي يختبر كفاءة الكود يجب أن يتم عمل instrumentation للكود أثناء العمل لقياس بعض مقاييس الكفاءة ويختبر بعض الأخطاء أو للتأكد من Code Coverage والمشاكل وهذا أمر أخر مدعم عن طريق Visual Studio.

اقتباس

لو نتكلم عن ربط Build Machine و تكامله هل يمكن ان اربطه مع مكتبة مجانية و مفتوحة المصدر مثل TPTP (أنا هنا اتكلم انى مطور استخدم Eclipse وقمت بربطه مع TFS و اريد استخدام مميزاته و مع اقل تكلفة ممكنة).

يمكنك ربط ال TFS مع Eclipse عن طريق هذه الأداة من هـــنـــا وكما قلت هذا بفضل extensibility model الموجود في TFS

اقتباس

* بالنسبة للـ Branching - المحتويات التقنية الخاصة بـ TFS تشير الى Private Branch للمطور. هذا غير شائع بالنسبة لى و الشائع اكثر Private Stream او Scoped Stream. كلمة Branching تستخدم اكثر عندما يتم عمل تجميد للكود Code Freezing و عمل Code splitting الى فرع اخر. و فى هذه الحالة الفرع القديم يكون Restricted. لكن ان نقول Branch لمطور هذه غريبه على و مربكة لي و هذا مااقصد ان يوجد ارتباك فى التفسيرات للكلمة.

بخصوص هذا الأمر فهناك لبس ..

ال TFS يمتلك مصطلحان .. Branch وهذا يكون على السيرفر فقط .. و Workspace وهذا يكون local على جهاز كل Developer ...

عندما نقول أننا من الممكن أن نقوم بعمل Branch لكل Developer المقصود هنا أننا سنقوم بعمل branch على السيرفر .. ثم يقوم المبرمج بتنزيله على جهازه local باستخدام ال workspace ولا يعني هذا ما دمت لم تحجم الصلاحيات على ال branch أنه لا يستطيع أحد أخر قراءة ال branch .. إنما المقصود أنك من الممكن أن تفصل ال branches لأكتر من سبب

إما أنك تجعل branch لكل مبرمج أو لكل فريق sub team مثلاً

أو branch لكل feature

أو branch لتعزل فيه شيئاً

وهكذا .. فهي مصطلحات عامة وطريقة عمل يحددها فريق العمل .. وليست ملزمة في ال TFS فيمكن للمشروع كله أن يكون على branch واحد فقط على السيرفر يعمل عليه كل ال developers من خلال ال workspaces الخاصة بهم وإن كان هذا الأسلوب سيء جداً ..

ويمكنك أيضاً التقسيم لعدة branches على حسب طريقة عملك ولكن أيضاً هذا ليس ملزماً في ال TFS

اقتباس

* أنا اتكلم عن فريق يعمل فى مدينة و له TFS لمشاريعه و فريق فى مدينة اخرى و له TFS. السيرفرين فى منطقتين مختلفتين تماما. هل ماتقترحه عمل سيرفر موحد للفرعين يعمل عليه الفريقين. فمن المؤكد انه هناك حاجة الى Cross-Repositories و من خلال ماقرأته فيوجد قصور فى TFS انه مقصور على 3600 شخص. كيف يمكن التغلب على هذا القصور بدون وجود Cross-communication.

1) بخصوص العدد 3600 المذكور فأنا لم أسمع من قبل أن ميكروسوفت أعلنت أن هذا هو الحد الأقصى .. ولكن أنا أعلم أن ميكروسوفت عندما أعلنت عن TFS فإنها قالت أنها قامت باختباره لحد يصل إلى مؤسسات بها 3600 فرد ولم تختبره فوق ذلك .. وهذا مذكور في هذه المقالة من موقع msdn. وهنا ميكروسوفت تعلن أنه لكي يعمل 3600 عضو على جهاز TFS واحد فإنه يحتاج أن يكون مواصفاته كالتالي:

)

ومن الواضح أنك لو قمت بزيادة هذه السماحيات يمكنك أن تزيد العدد ولكن ميكروسوفت نبهت أنها لم تقم باختباره فوق هذا العدد وهذا لا يعني أنها لا يدعم أكثر من هذا .. ولكن التكنولوجيا لها حدود كما أن الهاردوير له حدود .. وكلما زادات الإمكانيات في المستقبل ظهرت بدائل أفضل .. ولا أظن أنه يوجد عاقل في مجال الـ IT يقول بأن السوفتير عموماً لا يعتمد على تطور الهاردوير خصوصاً ويرجع أيضاً لهذه المقالة التي توضح بعض التحذيرات والحدود لاستخدام TFS

2) وفي هذه الحالة وتحت هذه الفرضية .. فإنه يكفي فقط TFS واحد يعمل عليه عدة فرقة منفصلة في العالم ولكن لا يخفى عليك أنه ستقابلنا مشاكل بسبب ال reliability of the lines وسرعة الخطوط وخلافه .. لذا طرحت ميكروسوفت ضمن مجموعة Team Foundation برنامج Team Foundation Proxy من أجل تدعيم العمل في بيئة distributed geographically بطريقة أفضل وأسرع وأأمن .. وهذا الرسم يوضح ذلك:

وجزاك الله خيراً

جزاك الله خيرا اخى احمد :

من الرسمة التى ارفقتها يبدوا ان Build Machine مستقل و يتم ربطه بـ TFS هل هذا صحيح ؟ بااختصار لو فريق البيلد يريد الانتقال الى Build Machine هل سيقوم فقط بربط السكريبتات Ant Scripts او ماشابه من السكريبتات ؟ أم سيقوم بعمل تهجير كامل و كتابة سكريبت من اول و جديد وعلى منصة جديده. Build Machine اسم تجارى اكثر فى رأى. اغلب فرق Build Team و التى تعتمد على TPTP و خلافه من المنصات تقوم بعمل كل ذلك و بادوات مجانية و مفتوحة المصدر و يتم نشرها فى بورتال و فتح الديفيكتات ايضا بسكريبتات بسيطة.

موضوع Traceability هى فعلا كلمة عامة و تتضمن الكثير من التفرعات - انا احاول ان اعرف المميزات الذى يدعمها Build Machine فافترضت انه يقدم دعم جيد لهذا. أنا اعرف ان TFS يقدم دعم لـ Eclipse لكن سؤالى كالتالى : أنا حاليا املك العديد من الاختبارات و دعم التقرير مبنيه على TPTP و اريد ربط TPTP بدل من Build Machine فهل هذا ممكن ؟ من الرسم الموضح للـ Build Machine اجدها قريبه للغاية من TPTP.

بالنسبة لـ Scalability Limits فهذا ليس كلامى المصدر :

اقتباس

500 Team Projects is the maximum that one TFS server can support.

Up to 3600 TFS users

لااعتقد Team Foundation Proxy سيحل كافة المشاكل لكنه Workaround لحين دعم Cross-Communication و هذا مااعتقده. الشركات الكبرى عدد موظفيها يتخطون 3600 لكن فى اكثر من فرع و مدينة.

ال build machine ممكن أن تكون منفصلة وممكن أن تكون على نفس جهاز ال TFS حسب الحاجة والسيناريو الموجود وهنا تأتي قوة ال TFS التي لم أجدها في غيره ..

نعم هناك أدوات كثيرة مفتوحة المصدر .. ولكن لماذا أستخدمها ومعي Team Foundation Build وبه كل الإمكانيات القوية + الدعم الكامل لكل منتجاتي التي أعمل عليها .. كما أنه لا أظن أنه يوجد منتج متكامل واحد لهذا الحد .. فعليك تجميع أكثر من أداة لتصل إلى الغرض المطلوب! وهو ما لا أحبه!

وبخصوص Ant نعم يمكنك ذلك .. انظر هذه المقالة

في الحقيقة أنا لم أعمل على TPTP ولذلك لا أستطيع أن أفيدك في هذه النقطة ..

أما بخصوص المصدر .. فهو مصدر غير معتمد من ميكروسوفت ولن أعتمد على بياناته ما دامت معي البيانات الأصلية!.. وعلى كل هو لم يخطيء لأنه أورد البيانات التي أوردتها ميكروسوفت والتي قالت بأنها اختبرت هذا النظام إلى 3600 عضو .. لذا فالمصر نقل بتحريف بسيط ولم يورد الكلام بنصه ..

بخوص أن ال Proxy تحايل .. فهو ليس تحايلاً على الإطلاق بل هو إضافة قوية لل distributed programming وتزيد من سرعة التعامل مع السيرفر من أي مكان في العالم .. بالاعتماد على نظرية ال Caching ..

أخى أحمد :

اقتباس

كما أنه لا أظن أنه يوجد منتج متكامل واحد لهذا الحد .

لو سنتكلم عن منتجات تجارية فهناك RTC و يوجد تنافس كبير بينهم و كل منتج له مميزات و يمكن المقارنة بينهم بالتفصيل. بالمناسبة عائلة Jazz و التى تطور IBM RTC سميت بهذا الاسم نظرا لان هذا النوع من الموسيقى يتطلب استخدام اكثر من اداة موسيقية بشكل متجانس و منسجم. و هو ماينبطق على هذا النوع من البرامج التى تجمع العديد من الخصائص و التى هو موجهة للشركات التى تملك اكثر من فرع فى اكثر من مدينة و تريد ان تدير العمل بتجانس و بانسجام.

* الكاشينج موضوع اخر تماما و لايحل المشكلة بشكل كامل. مازال المنتج بحاجة الى دعم تخاطب متجانس على الاقل مع سيرفرات TFS من وجهة نظرى و لن اتطرق الى التخاطب الغير المتجانس.

* المصدر معلوماته مستقاه من MSDN و IBM.

كلامى بشكل عام موجه من ناحية المطور و المبرمج حيث ان TFS لن يمثل حاجة ضرورية لها مع وجود اكثر من اداه مجانية مفتوحة المصدر و يمكن ان يقوم بربطهم معا. لكن لاجدال فى اهميتها للادارة و تسهيل عمل Tech. Leader و غيره من المزايا التى تسهل عمل Technical Writer and UX guys وغيرهم. لكن لو تكلمنا من منظور شركة متوسطة ذات موارد محدوده و لاتمتلك العديد من الفروع فسيكون شئ مكلف لهم و سيفضلون ان يقوموا بعمل تجانس مع اكثر من اداة مفتوحة المصدر و مجانية تحقق لهم هدفهم على سبيل المثال اداه مثل BIRT تستطيع ان تحقق لهم تقارير دورية عن الديفتكتات و التخطيط و خلافه و تسهل جزئيا عمل الادارة بشكل بسيط و مجانى وهو شئ متوفر فى TFS و RTC بشكل سلس و مباشر لكنه بثمن بكل تأكيد.

وجزاك الله خيرا...

أسف للتأخير في الرد ولكن الموقع كان سيئاً جداً اليوم ولم أستطع الدخول عليه إلا الآن ..

في نقطة مهمة جداً ..

بخصوص السعر والتكلفة التي يتكلم عنها الكثيرون ..

يمكنك بـ 10000 جنيه مصري فقط .. أن تشتري كل برامج ميكروسوفت من الألف إلى الياء ويصلك كل التحديثات دورياً وهذا عن طريق الـ msdn subscription ...

أنا لا أرى أي فائدة من استعمال 100 أداة .. مع وجود أداة واحدة توفر لي كل شيء بل ولها دعم هائل وأقوى من أي دعم في الأدوات المنتشرة ...

هل من الأفضل أن أعمل بأداة واحدة أم 10؟

هل من الأفضل أن أتابع الدعم لأداة واحدة أم 10؟

هل من الأفضل أن أتعلم أداة واحدة أم 10؟

أنا أرى أن المقارنة لا يمكن إلا أن تصب في صالح الأداة الواحدة ..

ولكن قد يكون هناك ظروف تمنع من ذلك:

1) المشكلة الوهمية التي تمنع بعض المبرمجين من العمل على برامج تجارية وحب برامج مفتوحة المصدر ومحاربة غيرها بدون داعي

2) عدم وجود المال الكافي

3) TFS برنامج كبير وإن كنت لن أستعمل كل مزاياه فيكفي أن تستعمل برنامج مثل git أو SVN من أجل ال source control مثلاً

فدائماً أنا أقول لا يوجد شيء اسمه أفضل شيء ... ولكن السيناريو الذي أنت فيه يحدد لك مجموعة من الخيارات وربما يكون خيار واحد.

جزاك الله خيراً