Як оцінити перехід на сервер Team Foundation

Зараз моя команда розробників використовує таке програмне забезпечення у нашому робочому процесі:

• JIRA
• Бамбук (атласька безперервна інтеграція)
• Greenhopper (спритний управління проектами в Атласі)
• Злиття
• Git, розміщений на BitBucket
• Visual Studio 2012

Як бачимо, ми вкладаємо великі кошти в екосистему Атласа. Ми розглядаємо можливість переходу до TFS, щоб ми могли отримати смаки вдосконалених інтеграцій Visual Studio, таких як огляди коду та, що ще важливіше, Microsoft Test Manager.

Мій попередній досвід роботи з TFS був з 2005 або 2008 роками (я не пам'ятаю), і у мене погані спогади про це, хоча і не так вже й погано, як мій час з ClearCase.

На які критерії нам слід звернути увагу, щоб правильно оцінити наш перехід до TFS?

Невелике опитування Мартіна Фаулера багато говорить про стан TFS в попередні роки. "небезпечно" цілком правильно. (Я думаю, що це стосується того, що він не розпізнає зміни, внесені поза VS, тому ви можете створити проект WCF, потім скористатися зовнішнім інструментом svcutil для створення свого клієнта, а потім перевірити всі ваші зміни в .. але TFS буде радісно ігноруйте зміни клієнта, оскільки вони не були внесені до VS).

Вам доведеться порахувати вартість: потрібна версія VS для отримання смакоти - огляди коду, наприклад, вимагають Premium Edition, який значно дорожче, якщо ви отримуєте VS через MSDN. Крім того, доступ до системи для користувачів, які не VS, є нормальним, але якщо вони хочуть отримати повний доступ замість перегляду веб-сторінок, що скорочується, тоді вам доведеться розкрити CAL для них. Загальна вартість TFS може бути досить багато. Навіть недавній звіт Forrester(за замовленням Microsoft, тому вам доведеться трохи прочитати між рядками) сказано, що TFS потребує значної підтримки адміністрації - для підтримки TFS для їх вивчення 122 користувачів потребували 2 консультантів та 6 адміністраторів (які витратили 25% свого часу). (працює на 4,5 адміністратора над цими 122 користувачами ... це багато в порівнянні з моїм налаштуванням та підтримкою повноцінного рішення SVN, а також виконую свою щоденну роботу). TFS може докласти чимало зусиль, щоб продовжувати працювати, як очікують люди.

З мого досвіду роботи з TFS2012 (забудьте попередні версії, оскільки вони лайно), це те, що це дуже складний адміністратор системи, особливо якщо ви виходите за межі попередньо визначених налаштувань. Наприклад, якщо ви використовуєте MSBuild для створення всього, ви все добре. Але якщо у вас є, скажімо, завантаження старих проектів .vdproj, які вже не підтримуються MSBuild, вам доведеться відредагувати величезний сценарій збірки xaml, щоб змусити його створювати ці проекти. Після декількох днів роботи над цим, найкраще, що я міг зробити, - це відновити рішення, передавши його в devenv, і навіть тоді отримати результати збірки та підсумок збірки було неможливо. Аналогічні результати мали й інші команди, які використовували NUnit для своїх тестів - якщо ви використовуєте вбудований MSTest, він працює. Інакше ти сильно напханий.

Як користувач, я вважаю, що інтеграція викликає більше неприємностей. Я віддаю перевагу TortoiseSVN, і я майже всю свою роботу над SCM роблю через це (адже це дивовижний інструмент). З TFS ви отримуєте новий екран всередині VS для кожної операції. Отже, у вашому середовищі є нова вкладка для команди провідника, інша для збірок і ще одна для кожного резюме збірки, яку ви хочете побачити (і якщо ви хочете переглянути деталі збірки, помилка, наприклад, у вас є натискати занадто багато посилань). Я виявив, що кількість документів, які я відкрила під час використання TFS, була більше, ніж вихідні файли!

Те саме стосується реєстрацій, внесення змін, необхідних натисканням декількох вкладок на панелі "Очікують зміни" в VS, щоб призначити робочий елемент та прокоментувати ваші реєстрації. Це невелика річ, але мені здалося, що це дратує, коли я звик до більш спрощених інструментів.

Розширення системи збирання було ще однією областю, якої мені не вистачало. Додавання нових функцій у збірку складно через конфігурацію xaml, і отримати результати цих функцій на екрани збірки - дуже важко, або неможливо. Тож якщо вам подобається додавати такі речі, як складність коду чи статичний аналіз, або навіть автоматичне тестування через, скажімо, селен або розгортання ... забудьте про це. Якщо ви не використовуєте інструменти Microsoft для цих аспектів (наприклад, fxcop).

Оновлення робочого процесу було черговим хитком - хоча powertoys надзвичайно допомагав, все-таки було незручно виправити робочий процес, і ви все одно не можете налаштувати дошку scrum з інформацією, яку ви дійсно хочете бачити - знову ж, ви отримуєте за замовчуванням або нічого .

Об'єднання також було болісним, я думаю, що є дуже вагома причина, коли MS прийняла git для TFS (зауважте, що це працює лише з абсолютно новими проектами TFS, ви не можете конвертувати з TFS в git backends).

Так що загалом це не дуже погано, як це працює, але я знайшов багато інших інструментів набагато краще. Недоліком цих інструментів є те, що вони не повністю інтегровані, але IMHO - це сила, оскільки ви можете вибрати та вибрати найкращі біти, які ви хочете. Завдяки TFS ви отримуєте майже все, що хтось інший хоче від вас. Якщо ви вирішите, що система помилок у TFS погана (і я думаю, що ви будете), вам буде важко змінитися на іншу.

TFS слід розглядати разом з іншими великими, жирними інструментами для повного життєвого циклу. Більшість розробників ненавидять такі речі, оскільки вони не люблять обмеження, які ці інструменти в кінцевому підсумку накладають на них.

Я б спробував це, проте завантажте 30-денні випробування та встановіть його. Оцінюючи, пам’ятайте, що тут і там дещо змінити, не використовуйте його лише для перевірки вихідного коду, перевіряйте необхідним робочим днем ​​і отримуйте звіти на основі цього робочого місця. Спробуйте призначити контрольну реєстрацію декількома робочими програмами та спробуйте поєднати робочі твори разом, як пов’язані між собою. Спробуйте включити щось інше в систему збирання, подивіться, як отримати щоденний звіт про хід роботи з звітних служб, прив’яжіть документ до вимоги робочого процесу та відстежте його через триагу помилок до кодування, яке потрібно побудувати для переробки, а потім випустити. Відгалужуються і зливаються багато. Якщо ви не можете легко зробити всі ці речі, то ви також можете дотримуватися git. Немає сенсу використовувати TFS, якщо ви не скористаєтесь більшості його функцій ALM.

Я перейшов з компанії з великим стеком атласів (і Mercurial) до компанії з важким стеком TFS. Я знаходжу два роздратування.

Перший - Контроль над джерелами .

Коли ви звикли до DVCS, повернення до CVCS є болючим. TFS особливо болісний, оскільки, при всій цій інтеграції для роботи, він наполягає на тому, щоб постійно підключатися до сервера.

Однак, на щастя, Microsoft нещодавно дозволила інтегрувати управління версіями Git в решту стеку TFS. Тож вам не потрібно відмовлятися від Git, і я раджу вам цього не робити, враховуючи, що всі це вже знають.

Я ще не впевнений, наскільки добре інструмент перегляду коду працює проти Git, однак, враховуючи, що він, здається, дуже покладається на шевельсети (трохи схожий на скрині, але не настільки потужний). Але потім покладатися на полиці для перегляду коду болісно саме по собі, оскільки це відмовляє від регулярних комісій.

Інше роздратування є причиною, чому більшість людей не вважають за краще віддалятися від TFS: Visual Studio Integration .

Я ще не повинен з'ясувати когнітивні міркування, які стоять за цим, але, з мого досвіду (і враховуючи, що це загальне значення), люди, які звикли до TFS, люблять інтеграцію. Вони ні за що не люблять переїжджати за межі своєї IDE.

Я, з іншого боку, не грівся до цього через рік. Мені здається, що це захаращено і важко орієнтуватися, порівняно з тим, що мій сервер побудови знаходиться в одній вкладці браузера, мої квитки в іншій вкладці браузера тощо. (Редагувати: Як зазначає Андрій, є веб-інтерфейс, але він також незрозуміло незграбний, коли ви звикли до останніх версій Джири та Дженкінса. Але все-таки це працює принаймні в інших браузерах, ніж IE.) це щось.)

Я ніколи не дивлюся на склади, якщо я не намагаюся зробити це, і тоді мені важко дізнатися, чи хтось ще це робить. Я не бачу змін інших людей, якщо мене не просять переглянути.

Але, ваш пробіг може відрізнятися. Як я кажу, деяким людям здається це незамінним. Я просто не можу не помітити, що це люди, які ніколи не робили це по-іншому.

Крім того, не зауважте, що це два негативи, один з яких може бути особистим, у досить великій інфраструктурі. Більшість мого досвіду хороша, і TFS не такий поганий, як деякі люди змусять вас повірити. І більшість речей, які ви вважаєте, що вам не вистачає, можливо, можна ввімкнути (це дуже налаштовано); враховуючи, що ви рухаєте цілу команду, а не одну людину, ви можете виявити менший опір.

У мене дуже позитивний досвід використання TFS 2012. Настроїти та запустити свій сервер TFS досить просто. Автоматизація побудови CI дуже проста та проста (а збірка для реєстрації в Gated просто приголомшлива. Ми не змогли досягти такої ж функціональності з Team City). Взаємодія команди також дуже прозора і відверта. Ви можете легко пов’язати ваші реєстрації з робочими програмами TFS, керувати відставаннями, відслідковувати дефекти, робити перегляд коду тощо. Є навіть вбудований месенджер =)

Однак майте на увазі, що якщо ви звикли до робочого процесу вашого JIRA, налаштування робочого процесу TFS може бути важкою задачею. Я б запропонував прийняти один із попередньо визначених робочих процесів TFS. Крім того, вам доведеться зберігати злиття, коли ви базуєте знання, або переходите на SharePoint, оскільки в TFS немає вбудовування вікі.

TFS набагато дешевше, якщо у вас підписка на MSDN (я вважаю, що у більшості компаній-розробників, що працюють з стеком технологій MS, є), у такому випадку у вас TFS безкоштовно.

Я думаю, що немає ніяких причин продовжувати використовувати інструменти сторонніх партій, якщо ви всі ваші розробники працюєте з Visual Studio. TFS забезпечує інтегровану, надійну, але просту у використанні систему ALM. Я з радістю відповім на ваші запитання, якщо у вас є такі.

Люди повинні знати, що TFS - це не просто VCS, це ALM .

Здається, багато людей просто хочуть ДКС, але йти на TFS - це неправильний шлях.
Що стосується CVCS, я все ще віддаю перевагу SVN.
Для соло або відкритого джерела обов'язково переходьте на GIT.

Але TFS2012 непогано, його легко зрозуміти на злитті / вилці, а потім на SVN.
А послуга фундації команди безкоштовна для 5 приватних репо користувачів / необмежених користувачів.

Клієнт також безкоштовний, TFS explorer будує поверх VS2010 і він безкоштовний.
Для Eclipse у ньому є плагін Eclipse - TFS скрізь.

Я не бачу проблем із витратами на це.
TFS express (безкоштовно) може працювати з SQL Server Express (також безкоштовно).