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