none
TFS для небольшой команды RRS feed

  • Вопрос

  • Привет всем!

    Такой вопрос - можно ли использовать TFS для следующего сценария? Есть небольшая команда, ведущая разработку на VS2008 исключительно под .NET. 50% времени разработка ведется в офисе, 50% - дома. При этом хотелось бы и дома, и на работе иметь контроль версий, удобное объединение домашних разработок в офисе, issue tracker (дома достаточно иметь оффлайн версию), средства тестирования и билда (в офисе). При этом публиковать TFS в интернете для доступа из дома нельзя по организационным причинам. Заранее спасибо.

    • Перемещено SachinW 2 октября 2010 г. 0:55 MSDN Forums Consolidation (От:Visual Studio Team System)
    7 августа 2009 г. 5:21

Ответы

Все ответы

  • Если TFS не будет доступен через Интернет, то и контроль версий, и issue tracker не будут доступны из дома. Это же просто сетевые сервисы. В остальном не вижу проблем: вечером, в конце рабочего дня в офисе, разработчики синхронизируют код. На следующий день работают дома, а через день, утром, опять синхронизируются и работают в офисе. Правда я исхожу из предположения, что ваши разработчики работают на ноутбуках, которые забирают домой. Носить код домой на флешках и каждый раз перетерать его то дома, то на работе - ИМХО - большой риск запутаться.
    • Предложено в качестве ответа Vitaly Zayko 7 августа 2009 г. 10:42
    7 августа 2009 г. 10:42
  • Да, к сожалению TFS не имеет инструментов для оффлайн разработки. Если не удается выставить TFS в интернет, то может можно открыть доступ к Team System Web Access? Этот сервис даст нормальный доступ к рабочим элементам и документам.

    7 августа 2009 г. 11:14
  • Если не удается выставить TFS в интернет, то может можно открыть доступ к Team System Web Access? Этот сервис даст нормальный доступ к рабочим элементам и документам.
    Это пожалуй интересный вариант.. Главное, что в любой момент можно будет создать рабочий элемент, и другой его тут же сможет увидеть..

    Что касается способа переноса проекта домой и обратно в офис - так тут к сожалению все делается именно на флэшках. Правда проект содержится на диске TrueCrypt, и копируется обычно весь файл диска, т.ч. путаницы нет, всегда под рукой оригинальная версия проекта.

    Вырисовывается следующая схема - в офисе есть сервер TFS с опубликованным в инет Team System Web Access. Там можно использовать все возможности TFS. Проект извлекается в рабочую копию на диске TrueCrypt, ведется обычная разработка. Вечером диск с рабочей копией копируется на флэшку и приносится домой. Там ведется оффлайн разработка все с того же диска TrueCrypt. При большой необходимости вести локальный контроль версий дома, можно использовать связку SVN+TortoiseSVN с файловым хранилищем (правда будет уходить некоторое лишнее время на синхронизацию с домашним хранилищем). Если находится баг, или возникает другая задача, она создается на TFS через Web Access. Другие участники проекта периодически просматривают список рабочих элементов и отрабатывают по ним. Утром снова все синхронизируются на TFS, проганяют все тесты, строят проект и обсуждают дальнейшие планы :) Интересно, насколько это удачное решение? И какие подводные камни могут возникнуть? (например, как TFS воспринимает проект, который изменялся в оффлайне?)
    7 августа 2009 г. 13:49
  • Ну, в принципе основной поток работ выполнен :). С точки зрения возврата изменений в центральное хранилище, я б наверно использовал некий скрипт, который бы:
    1. При доставке «домашней работы» сканировал каталог с флэшки и рабочий каталог TFS разработчика на предмет изменений. Я думаю, утилиты для сравнения файлов из командной строки найдутся.
    2. Если файлы изменились, то в рабочем каталоге TFS делается check-out с помощью tf.exe, и изменившийся файл копируется с флешки в рабочий каталог. Ну и т.д. для других случаев (добавлено, удалено).

    7 августа 2009 г. 14:26
  • А если я сделаю чекаут файла, заменю его своим и попытаюсь зачекинить обратно, он мне предложить слить изменения или просто перезатрет старую версию новой?

    8 августа 2009 г. 2:19
  • Думаю, что будет воспринято как стандартный процесс редактирования, т.е. создаст новую версию.
    8 августа 2009 г. 5:59
  • Тогда такой вариант не подойдет. Т.к. один и тот же файл могут отредактировать два человека. Затем утром сначала первый человек сохранит свою версию, а второй - затрет версию первого своей.
    8 августа 2009 г. 6:51
  • Ну, на самом деле никто не мешает использовать утилиты мержинга, а не просто копировать. Как альтернатива – можно разработку разветвить, т.е. для каждого разработчика сделать свой бранч, далее мержить стандартными средствами TFS.

    8 августа 2009 г. 12:29
  • Про отдельные бранчи - очень интересная идея :) Можно всегда вести разработку в рамках своего бранча. Затем изменения сливать в главную ветку, тестировать и проверять, если главный билд выполняет все тесты и нормально работает, значит принимать его, иначе откатывать до прежнего состояния и дальше отлаживать в своем бранче (кстати TFS поддерживает откат до предыдущего среза времени для всего проекта, чтоб не гадать, какие файлики были изменены?). Таким образом, в главной ветке всегда будет стабильная версия :) Реализовал отдельный функционал, залил в главную ветку, если все ок, можно текущий бранч закрывать и открывать новый для нового функционала. 

    8 августа 2009 г. 13:58
  • >> кстати TFS поддерживает откат до предыдущего среза времени для всего проекта, чтоб не гадать, какие файлики были изменены?

    Для этого можно использовать инструменты Team Foundation PowerToys. Там есть команда “tfpt rollback”, которая позволяет откатить изменения. Примерчик: http://social.msdn.microsoft.com/Forums/en-US/tfspowertools/thread/2cbfd670-74cc-4d03-b9a8-cf5a70584686
    • Изменено Alexandr ShamrayMVP 8 августа 2009 г. 19:07
    • Помечено в качестве ответа Vitaly Zayko 14 сентября 2009 г. 9:23
    8 августа 2009 г. 15:37
  • Спасибо, Shamray Aleksander, Вы мне очень помогли восполнить пробелы использования TFS.

    На самом деле тема очень интересная, очень жаль, что сама МС так мало внимания уделяет описанию разных сценариев использования этого продукта. На многих форумах часто можно встретить отказ от TFS в пользу SVN+NUnit+... именно из-за неумения его использовать, вследствие чего возникают мифы, что TFS этого не может, того не может.

    11 августа 2009 г. 1:19