Комментарии 21
проект с гигантским git-репозиторием, в котором есть тысячи веток и тегов
Удалить ненужное не?
Дело в том, что у нас используется по ветке на тикет, и в каждый момент времени количество открытых тикетов достигает тысяч (какое-то количество тикетов просто открыто и ещё не зарезолвлено, какое-то — в QA, разработчиков у нас около 100 :)).
И зачем вам такие приблуды: GitPHP и самописные профайлеры? Git создан для коммандной строки. А для профилирования есть Xdebug и KCachegrind
Одна из основных вещей, для которой мы используем GitPHP — это процесс ревью кода. В нашей версии добавлена функциональность, позволяющая в удобном виде смотреть дифф по ветке (заточенная под наш workflow, то есть, задачи стартуют от мастера и «живут» в своих ветках).
Таймеры а-ля pinba позволяют легко отлаживать времена обращений к внешним сервисам. Внутри компании для профилирования мы всё же предпочитаем использовать XHProf, но по умолчанию страницы не профилируются. Такой простенький профилировщик на каждой странице позволяет легко видеть узкие места, когда дело касается вызова утилиты git. XHProf или XDebug выдают несравненно больше информации, которую нужно отдельно анализировать. Pinba-like таймеры и XHProf не отменяют друг друга.
Таймеры а-ля pinba позволяют легко отлаживать времена обращений к внешним сервисам. Внутри компании для профилирования мы всё же предпочитаем использовать XHProf, но по умолчанию страницы не профилируются. Такой простенький профилировщик на каждой странице позволяет легко видеть узкие места, когда дело касается вызова утилиты git. XHProf или XDebug выдают несравненно больше информации, которую нужно отдельно анализировать. Pinba-like таймеры и XHProf не отменяют друг друга.
Просмотреть все изменения в ветке some_feature можно командой git diff master...some_feature.
git difftool — возможность ревью. Можно использовать любой графический инструмент слияния и просмотра изменений от meld и до kdiff3. Возможности PHPGit и рядом не стояли.
Преждевременная оптимизация источник всех бед (с). Оптимизацией нужно заниматься используя соотвествующий инструментарий, в нужное время и нужными людьми.
git difftool — возможность ревью. Можно использовать любой графический инструмент слияния и просмотра изменений от meld и до kdiff3. Возможности PHPGit и рядом не стояли.
Преждевременная оптимизация источник всех бед (с). Оптимизацией нужно заниматься используя соотвествующий инструментарий, в нужное время и нужными людьми.
Безусловно diff с тремя точками покажет изменения по ветке, в оригинальном GitPHP этой возможности нет, вот мы и добавили один простой вызов.
Нас вполне устраивает вид unified диффа в браузере + наша подсветка изменений символов в строке. Каждый сотрудник использует удобную ему операционную систему и GitPHP работает везде одинаково и требует только браузер, также никто не запрещает использовать другие средства, такие как meld или встроеный в phpstorm diff viewer. Но это только просмотр, в нашей версии есть возможность тут же написать комментарии и по окончании ревью уведомить разработчика и возможно обновить статус задачи в баг-трекере.
GitPHP очень простой инструмент и делает не больше чем вызов программы git с нужными параметрами.
Необходимость оптимизации настала, очень тоскливо ждать загрузки страницы с бранчдиффом по 20+ секунд. Инструмент уже был встроен в GitPHP, мы его только улучшили и поделились с автором.
Нас вполне устраивает вид unified диффа в браузере + наша подсветка изменений символов в строке. Каждый сотрудник использует удобную ему операционную систему и GitPHP работает везде одинаково и требует только браузер, также никто не запрещает использовать другие средства, такие как meld или встроеный в phpstorm diff viewer. Но это только просмотр, в нашей версии есть возможность тут же написать комментарии и по окончании ревью уведомить разработчика и возможно обновить статус задачи в баг-трекере.
GitPHP очень простой инструмент и делает не больше чем вызов программы git с нужными параметрами.
Необходимость оптимизации настала, очень тоскливо ждать загрузки страницы с бранчдиффом по 20+ секунд. Инструмент уже был встроен в GitPHP, мы его только улучшили и поделились с автором.
У меня, честно говоря, все эти истории про бадушную инфраструктуру вызывают всего одну мысль — «Мыши плакали, кололись, но продолжали жрать фичебранчи, вместо того чтобы организовать нормальный continious delivery».
Хорошо. Допустим вы на каждый чих заводите тикет и ветку. Это нормально. Стандартная процедура для большой компании, где все проверяется долго и нудно.
С ваших слов я примерно прикидываю что у ва 2000-3000 веток на 100 разработчиков, то есть в среднем 20-30 на одного. Пусть 20. 20 мелких задач, 20 веток. Я не верю что 20 задач у разработчика никак не связаны с собой. Так не бывает, мы живем в реальном мире, тикеты приходят пачками на один тип задачи. В рамках одной ветки(задачи) они и делаются. И все это в одной ветке и тестируется и выкатывается.
А вся эта возьня с ветками просто похоже на видимость работы. Любой разработчик иногда прикрывается тикетами, не надо этого скрывать, это нормально. Просто со временем видимость работы, которая создается иммено тикетами превращается в работу и человек думает что он правда работает. Хотя на самом деле это все не так. Разработчику любого уровня всего-то и надо — просто х@$рить код.
С ваших слов я примерно прикидываю что у ва 2000-3000 веток на 100 разработчиков, то есть в среднем 20-30 на одного. Пусть 20. 20 мелких задач, 20 веток. Я не верю что 20 задач у разработчика никак не связаны с собой. Так не бывает, мы живем в реальном мире, тикеты приходят пачками на один тип задачи. В рамках одной ветки(задачи) они и делаются. И все это в одной ветке и тестируется и выкатывается.
А вся эта возьня с ветками просто похоже на видимость работы. Любой разработчик иногда прикрывается тикетами, не надо этого скрывать, это нормально. Просто со временем видимость работы, которая создается иммено тикетами превращается в работу и человек думает что он правда работает. Хотя на самом деле это все не так. Разработчику любого уровня всего-то и надо — просто х@$рить код.
Разделение на мелкие ветки не означает, что мы не можем, скажем, мержить эти ветки между собой, если задачи между собой сильно связаны :). Базовый паттерн «ветка на фичу» позволяет комбинировать ветки, как нам удобно, потому что они уже разбиты на довольно мелкие кусочки. Если задачи между собой связаны по коду, то мы выкладываем сразу все эти задачи, в этом вы правы.
Я считаю, что вводить ограничения на количество веток (или тикетов) только из соображений производительности только _одного_ из инструментов, который мы используем — это как-то странно :).
В целом после перехода с SVN (и разработки в trunk) на фиче-ветки стало намного проще отслеживать статус задач и тестировать сами задачи. Проблемы с производительностью мы способны решить сами :). Архитектура GitPHP весьма простая и легко поддается оптимизации, благо опыт у каждого из наших PHP-разработчиков в этом более, чем достаточный.
В команде мобильной разработки, например, у нас используется немного другой workflow, о котором мы рассказывали на HighLoad++ (см. доклад Владислава Чернова). Для веба наш текущий workflow нас устраивает.
Я считаю, что вводить ограничения на количество веток (или тикетов) только из соображений производительности только _одного_ из инструментов, который мы используем — это как-то странно :).
В целом после перехода с SVN (и разработки в trunk) на фиче-ветки стало намного проще отслеживать статус задач и тестировать сами задачи. Проблемы с производительностью мы способны решить сами :). Архитектура GitPHP весьма простая и легко поддается оптимизации, благо опыт у каждого из наших PHP-разработчиков в этом более, чем достаточный.
В команде мобильной разработки, например, у нас используется немного другой workflow, о котором мы рассказывали на HighLoad++ (см. доклад Владислава Чернова). Для веба наш текущий workflow нас устраивает.
Feature Branching is a poor man's modular architecture, instead of building systems with the ability to easy swap in and out features at runtime/deploytime they couple themselves to the source control providing this mechanism through manual merging.
— Dan Bodart
Давайте будем честными.
ИМХО, скорее всего у вас сильносвязанный код с плохо изолированными модулями и поэтому вы изолируете изменения в отдельных ветках, потому что не можете честно включать/выключать фичи при деплое (как это делает гитхаб, например). А еще вы скорее всего толком не рефакторите, так как при любом серьезном рефакторинге вы будете постоянно влетать в семантические конфликты и вся автоматизация мержей не будет давать никакого профита. Ну и, скорее всего, вы регулярно ловите интеграционные баги в, казалось бы, уже оттестированных задачах на продакшне.
Ни в коем разе не отменяя ваш вклад в открытые продукты, вместо разруливания реальных проблем — вы тратите ресурсы на прикрывание чьих-то организационных и архитектурных факапов автоматизируя бардак. Да еще и гордитесь этим ;(
Комментатор выше абсолютно прав — это видимость работы.
— Dan Bodart
Давайте будем честными.
ИМХО, скорее всего у вас сильносвязанный код с плохо изолированными модулями и поэтому вы изолируете изменения в отдельных ветках, потому что не можете честно включать/выключать фичи при деплое (как это делает гитхаб, например). А еще вы скорее всего толком не рефакторите, так как при любом серьезном рефакторинге вы будете постоянно влетать в семантические конфликты и вся автоматизация мержей не будет давать никакого профита. Ну и, скорее всего, вы регулярно ловите интеграционные баги в, казалось бы, уже оттестированных задачах на продакшне.
Ни в коем разе не отменяя ваш вклад в открытые продукты, вместо разруливания реальных проблем — вы тратите ресурсы на прикрывание чьих-то организационных и архитектурных факапов автоматизируя бардак. Да еще и гордитесь этим ;(
Комментатор выше абсолютно прав — это видимость работы.
не тру. репо должен шевелиться с любым вероятным кол-вом веток и тегов. Badoo молодцы, спасибо за вклад в Open Source!
Я уж было удивился, что в китайском поисковике badoo работают наши программисты. Потом сходил в google и понял что поисковик — это baidu.
У меня к badoo такой личный вопрос, не относящийся к топику:
Когда рапортуешь, что в некой анкете фотография чужая (обычно знаменитости), требуется указать имя изображённого. Для этого приходится через задницу выуживать фото (простые методы вами заблокированы), чтобы впихнуть в google images или tineye и, наконец, идентифицировать эту знаменитость.
В результате badoo никаких действий по поводу данной анкеты не предпринимает.
Вопрос: нахрена это всё в таком случае?!
Когда рапортуешь, что в некой анкете фотография чужая (обычно знаменитости), требуется указать имя изображённого. Для этого приходится через задницу выуживать фото (простые методы вами заблокированы), чтобы впихнуть в google images или tineye и, наконец, идентифицировать эту знаменитость.
В результате badoo никаких действий по поводу данной анкеты не предпринимает.
Вопрос: нахрена это всё в таком случае?!
Подскажите ваш аккаунт (в пм) — посмотрим кого вы репортили и почему с ним ничего не сделали.
ты решил на меня теперь здесь пожаловаться??? мои это фотки, я отвечаю!!!
На самом деле можно просто написать слово знаменитость, если уж вы не помните имя — это не критично, а далее наши модераторы проверят фотку на принадлежность какой-либо знаменитости и уберут её с сайта.
Но в скором времени не нужно будет вводить никакой текст. Так что всё меняется, мы развиваемся и стараемся упрощать подобные процессы.
Но в скором времени не нужно будет вводить никакой текст. Так что всё меняется, мы развиваемся и стараемся упрощать подобные процессы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
GitPHP в Badoo