Джун, который класса с 10го качал математику для поступления и четыре года учился в бакалавриате сам решать задачи и искать информацию - это коллега.
Джун, который вчера был искусствоведом, а сегодня прошел курсы, знает эксель и готов "вкалывать" - это чаще балласт, ведущий к выгоранию тимлида и сеньора. Потому что именно эти ребята должны будут не просто написать в PR замечание, а подкрепить его документацией, ссылкой на хабр и, в совсем тяжелых случаях, созвоном.
Наверняка есть компании, которые готовы себе растить штат таким образом... но не хотелось бы в них оказаться.
Мы работаем по схеме, описанной в рекомендациях микрософта. Сама схема у нас проблем не вызывает, напротив — очень удобно.
Единственная проблема, с которой мы сталкиваемся, как уже писалось выше:
Попытка удаления папки, в которой 50 задач * 48 000 файлов в ветке вешает намертво процесс удаления и/или чекин.
Но это не на столько критичная проблема, чтобы ломать выстроенные удобные процессы и резко уходить на Git.
Мы сейчас работаем по схеме, которая описана тут в пункте Isolated Development Scenario.
Правда ушли чуть глубже и от каждого релиза (фичи) еще бранчуем все задачи, которые должны в рамках нее встать на бой, чтобы разрабатывать их совсем независимо друг от друга.
В дату установки все задачи вливаются в релиз, релиз вливается в в main и из него разносится во все релизы в разработке, из каждого релиза в разработке — в отбранчеванные от него задачи.
Т.е. каждую задачу можно очень быстро перекинуть от одной фичи к другой, исключив ее из ближайшей установки или наоборот двинуть пораньше. Задачи отдельно на продуктив не встают — только протестированной пачкой и в рамках релиза. Это краеугольный камень в нашем процессе, из за которого не смогли перейти на GIt.
Почитаю про подмодули, там есть над чем подумать. Спасибо.
У нас специфика разработки и сборки выстроена жестко под тфс + teamcity. Гит смотрели, но не смогли придумать как на нем организовать процесс по той же схеме.
Концепция процесса в том, что все задачи разрабатываются каждая в своей ветке (отношения dev_i -> задача), каждую задачу можно передвинуть за два клика в другой релиз DEV_j просто сделав reparent к DEV_j.
TeamCity собирает все изменения из DEV_i+ все дочерние ветки, после установки релиза на бой все изменения разносятся по цепочке (задачи релиза -> dev_i -> trunk -> dev i+1..n -> задачи по dev i+1..n), т.е. каждая задача в любой момент времени отличается от продуктива исключительно на правки по задаче.
С Git не смогли понять как быстро двигать задачи из релиза в релиз, не затрагивая всю цепочку, но если подскажешь куда посмотреть за пруфом — с удовольствием сходим и посмотрим.
У нас с TFS только в одном жуткая боль (36+ программистов, 10+ релизов в разработке) — удаление ветки после установки.
Попытка удаления папки, в которой 50 задач * 48 000 файлов в ветке вешает намертво процесс удаления и/или чекин. Откатить такой Pending Change тоже не получается.
Может быть кто-нибудь сталкивался с такой проблемой?
Сейчас выкачиваем и сносим по 2-3 ветки, но это сильно раздражает…
Как я вас понимаю! Особенно сложно себя заставить куда-то ехать зимой, когда не то что в кафе — до магазина то себя сложно заставить выбраться. Я в том году поймала себя на разговорах с роботом-пылесосом =(
И у меня. Первая зп была 15 тысяч, а друзья в продажах по 50-60 уже зарабатывали.
У них правда и сейчас 50-60 :-)
Джун, который класса с 10го качал математику для поступления и четыре года учился в бакалавриате сам решать задачи и искать информацию - это коллега.
Джун, который вчера был искусствоведом, а сегодня прошел курсы, знает эксель и готов "вкалывать" - это чаще балласт, ведущий к выгоранию тимлида и сеньора. Потому что именно эти ребята должны будут не просто написать в PR замечание, а подкрепить его документацией, ссылкой на хабр и, в совсем тяжелых случаях, созвоном.
Наверняка есть компании, которые готовы себе растить штат таким образом... но не хотелось бы в них оказаться.
Единственная проблема, с которой мы сталкиваемся, как уже писалось выше:
Но это не на столько критичная проблема, чтобы ломать выстроенные удобные процессы и резко уходить на Git.
Правда ушли чуть глубже и от каждого релиза (фичи) еще бранчуем все задачи, которые должны в рамках нее встать на бой, чтобы разрабатывать их совсем независимо друг от друга.
В дату установки все задачи вливаются в релиз, релиз вливается в в main и из него разносится во все релизы в разработке, из каждого релиза в разработке — в отбранчеванные от него задачи.
Т.е. каждую задачу можно очень быстро перекинуть от одной фичи к другой, исключив ее из ближайшей установки или наоборот двинуть пораньше. Задачи отдельно на продуктив не встают — только протестированной пачкой и в рамках релиза. Это краеугольный камень в нашем процессе, из за которого не смогли перейти на GIt.
Почитаю про подмодули, там есть над чем подумать. Спасибо.
Концепция процесса в том, что все задачи разрабатываются каждая в своей ветке (отношения dev_i -> задача), каждую задачу можно передвинуть за два клика в другой релиз DEV_j просто сделав reparent к DEV_j.
TeamCity собирает все изменения из DEV_i+ все дочерние ветки, после установки релиза на бой все изменения разносятся по цепочке (задачи релиза -> dev_i -> trunk -> dev i+1..n -> задачи по dev i+1..n), т.е. каждая задача в любой момент времени отличается от продуктива исключительно на правки по задаче.
С Git не смогли понять как быстро двигать задачи из релиза в релиз, не затрагивая всю цепочку, но если подскажешь куда посмотреть за пруфом — с удовольствием сходим и посмотрим.
Попытка удаления папки, в которой 50 задач * 48 000 файлов в ветке вешает намертво процесс удаления и/или чекин. Откатить такой Pending Change тоже не получается.
Может быть кто-нибудь сталкивался с такой проблемой?
Сейчас выкачиваем и сносим по 2-3 ветки, но это сильно раздражает…