Comments 27
Наша команда постоянно испытывает боль и страдания при работе с TFS, кроме того это поделие сильно тормозит и постоянно что-то отваливается. Связка tfs-git имеет свойство терять коммиты. Фраза «TFS — г#вн#!!» звучит почти на каждой ретроспективе. Никому не посоветую связываться с этим продуктом
-2
Зачем вам связка git-tfs при нормальных гитовых репозиториях 0_о? У нас ничего не тормозит и работает стабильно. Возможно развернут криво и зачем-то TFVC используете.
+1
Продукт под Linux посему используем git, но репозиторий держим в TFS для всяких релизных процедур и сертификации. К сожалению, отказаться от него(TFS) нельзя, а для пингвина нет нормального TFS клиента контроля версий. Возможно в мире Windows все гладко, но в нашем случае есть определенный геморрой.
0
А какие клиенты нужны? Все необходимое есть в Web. Исходники можно перенести в Git. можно даже в сторонний git сервер. Начиная с TFS 2012 не знаю что такое TFS тормозит. Начиная с 2015 получил еще и шикарные билды.
0
Еще и Nuget фиды, а в 17 и npm завезли.
0
Нужен линуксовый консольный клиент к TFS контролю версий, нативный git репозиторий использовать не модем по ряду причин(централизованные бэкапы, требования по сертификации, etc). Cборочный конвейер пока используем другой.
0
Бэкапы чего? Какие требования по сертификации? Git репо в базе TFS живет.
0
Бэкапы репозитория. IEC 61508, одно из требований — обеспечение трейсабилти между исходным кодом и сущностями трекинговой системы(требованиями, тасками, багами и т.п.)
0
Git так же поддерживает traceability. И лэйблы с билдами и тд. Бэкап репозитория — бэкап базы Project Collection, если хочется руками.
TFS Internals
TFS Internals
0
Вообще с 2013 поддерживаются нативные git репозитории + пул реквесты. Смысл жрать кактус непонятен при этом. И у нас с TFS Нормально работают из под MacOS (Java+Android и Swift+iOS).
0
Не существует такой системы, которая удовлетворяла бы абсолютно всем требованиям и нравилась бы всем. Это утопия.
Про тормоза могу сказать следующее: у нас в TFS 300+ человек, 80+ проектов и постоянно собираются (релиз + CI) два проекта. Так же ежедневно мы бекапим воркфлоу всех проектов и WI и при этом тормозов не наблюдается.
Тормоза иногда возникают при сильной загруженности инфраструктуры, но они достаточно редки.
Связка tfs-git у нас реализована утилитой git-tf. Да, она весьма интересно пушит в гит результаты, но потерянных коммитов ни разу не было. а что используете вы?
Про «тфс — ****» сказать ничего не могу. Мы им пользуемся и нашим запросам он удовлетворяет, пусть и не полностью, но мы ищем решения.
Про тормоза могу сказать следующее: у нас в TFS 300+ человек, 80+ проектов и постоянно собираются (релиз + CI) два проекта. Так же ежедневно мы бекапим воркфлоу всех проектов и WI и при этом тормозов не наблюдается.
Тормоза иногда возникают при сильной загруженности инфраструктуры, но они достаточно редки.
Связка tfs-git у нас реализована утилитой git-tf. Да, она весьма интересно пушит в гит результаты, но потерянных коммитов ни разу не было. а что используете вы?
Про «тфс — ****» сказать ничего не могу. Мы им пользуемся и нашим запросам он удовлетворяет, пусть и не полностью, но мы ищем решения.
+3
У каждого своё мнение. Лично у меня только положительный опыт работы с TFS. Тем более многое из коробки, все модули хорошо интегрированы между собой. Не надо тратить дофига времени, чтобы скрестить бульдога с носорогом.
+3
У того TFS-то нормальный клиент для linux появился?
0
Вы про TFVC или TFS?
0
Я про консольный клиент для линукс, но я уже все выяснил из других комментариев. С 2008го года по-прежнему все плохо. Как не умел ветки сливать, видимо, так и не умеет.
0
А почему на Git не мигрируете?
0
Ой, много чего можно написать. Там, где я с этой проблемой столкнулся, там я давно уже не работаю. Тогда мигрировали с CVS куда-то. Вся контора на винде, и в углу пять юниксоидов. Конечно же, об их удобстве никто не подумал. Точнее, — подумали и проигнорировали. Перешли на TFS. Зато манагеры получили возможность смотреть на красивые отчеты. Как-то так
0
У нас с TFS только в одном жуткая боль (36+ программистов, 10+ релизов в разработке) — удаление ветки после установки.
Попытка удаления папки, в которой 50 задач * 48 000 файлов в ветке вешает намертво процесс удаления и/или чекин. Откатить такой Pending Change тоже не получается.
Может быть кто-нибудь сталкивался с такой проблемой?
Сейчас выкачиваем и сносим по 2-3 ветки, но это сильно раздражает…
Попытка удаления папки, в которой 50 задач * 48 000 файлов в ветке вешает намертво процесс удаления и/или чекин. Откатить такой Pending Change тоже не получается.
Может быть кто-нибудь сталкивался с такой проблемой?
Сейчас выкачиваем и сносим по 2-3 ветки, но это сильно раздражает…
0
Выше уже отписал. Почему не мигрировать на Git? Нет проблем с ветками, при пул реквестах рабочие ветки можно автоматом удалять.
0
У нас специфика разработки и сборки выстроена жестко под тфс + teamcity. Гит смотрели, но не смогли придумать как на нем организовать процесс по той же схеме.
Концепция процесса в том, что все задачи разрабатываются каждая в своей ветке (отношения dev_i -> задача), каждую задачу можно передвинуть за два клика в другой релиз DEV_j просто сделав reparent к DEV_j.
TeamCity собирает все изменения из DEV_i+ все дочерние ветки, после установки релиза на бой все изменения разносятся по цепочке (задачи релиза -> dev_i -> trunk -> dev i+1..n -> задачи по dev i+1..n), т.е. каждая задача в любой момент времени отличается от продуктива исключительно на правки по задаче.
С Git не смогли понять как быстро двигать задачи из релиза в релиз, не затрагивая всю цепочку, но если подскажешь куда посмотреть за пруфом — с удовольствием сходим и посмотрим.
Концепция процесса в том, что все задачи разрабатываются каждая в своей ветке (отношения dev_i -> задача), каждую задачу можно передвинуть за два клика в другой релиз DEV_j просто сделав reparent к DEV_j.
TeamCity собирает все изменения из DEV_i+ все дочерние ветки, после установки релиза на бой все изменения разносятся по цепочке (задачи релиза -> dev_i -> trunk -> dev i+1..n -> задачи по dev i+1..n), т.е. каждая задача в любой момент времени отличается от продуктива исключительно на правки по задаче.
С Git не смогли понять как быстро двигать задачи из релиза в релиз, не затрагивая всю цепочку, но если подскажешь куда посмотреть за пруфом — с удовольствием сходим и посмотрим.
0
Задачи или фичи?
Задачи/фичи после RTM в той же ветке живут или ветка выносится?
Не очень понял про двигать задачи из релиза в релиз :) Можно поподробнее о вашем процессе и требованиях? Сабмодули вам не подходят?
Задачи/фичи после RTM в той же ветке живут или ветка выносится?
Не очень понял про двигать задачи из релиза в релиз :) Можно поподробнее о вашем процессе и требованиях? Сабмодули вам не подходят?
0
Мы сейчас работаем по схеме, которая описана тут в пункте Isolated Development Scenario.
Правда ушли чуть глубже и от каждого релиза (фичи) еще бранчуем все задачи, которые должны в рамках нее встать на бой, чтобы разрабатывать их совсем независимо друг от друга.
В дату установки все задачи вливаются в релиз, релиз вливается в в main и из него разносится во все релизы в разработке, из каждого релиза в разработке — в отбранчеванные от него задачи.
Т.е. каждую задачу можно очень быстро перекинуть от одной фичи к другой, исключив ее из ближайшей установки или наоборот двинуть пораньше. Задачи отдельно на продуктив не встают — только протестированной пачкой и в рамках релиза. Это краеугольный камень в нашем процессе, из за которого не смогли перейти на GIt.
Почитаю про подмодули, там есть над чем подумать. Спасибо.
Правда ушли чуть глубже и от каждого релиза (фичи) еще бранчуем все задачи, которые должны в рамках нее встать на бой, чтобы разрабатывать их совсем независимо друг от друга.
В дату установки все задачи вливаются в релиз, релиз вливается в в main и из него разносится во все релизы в разработке, из каждого релиза в разработке — в отбранчеванные от него задачи.
Т.е. каждую задачу можно очень быстро перекинуть от одной фичи к другой, исключив ее из ближайшей установки или наоборот двинуть пораньше. Задачи отдельно на продуктив не встают — только протестированной пачкой и в рамках релиза. Это краеугольный камень в нашем процессе, из за которого не смогли перейти на GIt.
Почитаю про подмодули, там есть над чем подумать. Спасибо.
0
Я бы попробовал сабмодули в таком случае. TFS 2015 их поддерживает:
One TFS Build, Multiple Git Repositories with Submodules
One TFS Build, Multiple Git Repositories with Submodules
0
Прочитал что там по ссылке, приведенной вами. Нет никаких проблем не перейти на Git. Бранчевание, это то, что лучше Git пока никто не умеет.
С Git вы можете хоть под каждую идею реализации одной таски (в камках фичи (в рамках релиза)) делать ветку. И все это будет без боли. Легко сделали — легко удалили, если не понрацился результат. И не надо засорять прохими реализациями общий репозиторий.
С Git вы можете хоть под каждую идею реализации одной таски (в камках фичи (в рамках релиза)) делать ветку. И все это будет без боли. Легко сделали — легко удалили, если не понрацился результат. И не надо засорять прохими реализациями общий репозиторий.
0
Мне почему-то кажется что вы только что описали какую-то жуткою ересь в плане работы с ветками.
В Git работа с ветками куда более гибкая. Все описанное выше делается запросто.
К тому же не понятно зачем вообще teamcity если есть родной билд сервер.
В Git работа с ветками куда более гибкая. Все описанное выше делается запросто.
К тому же не понятно зачем вообще teamcity если есть родной билд сервер.
0
Мы работаем по схеме, описанной в рекомендациях микрософта. Сама схема у нас проблем не вызывает, напротив — очень удобно.
Единственная проблема, с которой мы сталкиваемся, как уже писалось выше:
Но это не на столько критичная проблема, чтобы ломать выстроенные удобные процессы и резко уходить на Git.
Единственная проблема, с которой мы сталкиваемся, как уже писалось выше:
Попытка удаления папки, в которой 50 задач * 48 000 файлов в ветке вешает намертво процесс удаления и/или чекин.
Но это не на столько критичная проблема, чтобы ломать выстроенные удобные процессы и резко уходить на Git.
0
Sign up to leave a comment.
Личный опыт: организация Workflow в трекере TFS