Изначально в гите встроенных средств для коллективного ревью кода нет. Поэтому пришлось искать что-то подходящее.
В то время как для мержа веток все есть из коробки. git merge нас устраивает чуть более чем полностью.
Вот тут в комментариях выше, я описал вводную. Эксперименты с Upsource у нас закончились тем, что в течении двух недель инструмент не смог индексировать историю самого большого репозитория. Мы писали в Jet Brains (у нас есть там контакты со времен укрощения teamcity). Нам ничего вразумительного не смогли посоветовать, а только попросили предоставить им этот самый репозиторий, чтобы они на живых данных проверили что там так долго индексируется. Этого мы, разумеется, себе позволить не смогли.
Да, видимо было бы неплохо сделать обзорную статью со сравнением :) Давайте так: я дам вводную, а после попробую найти время на полный обзор, но не обещаю что время найдется. Это же кучу инсталляций и замеров надо делать опять, причем держа в голове что это для публичной статьи :)
Вводная:
1) Инструмент должен быть self-hosted.
2) Инструмент должен иметь возможность доработки по мере появления запросов на новые фичи.
3) Бесплатный опенсорсный лучше платного проприетарного :)
4) Инструмент должен поддерживать разделение доступа по репозиториям.
5) Общее кол-во репозиториев в системе — чуть менее 250.
6) Самый большой репозиторий содержит ~130 тысяч файлов, весит около 5 гигабайт. История коммитов в нем на текущий момент ~ 670 тысяч коммитов.
Большинство инструментов, которые мы пробовали, начинали фейлить на 6м пункте — загружали историю нашего репозитория по нескольку дней, недель и т.д. И потом безумно тупили. codeisok же не делает никаких внутренних индексов и работает поверх гита. Получается быстро.
gitlab, как я уже упоминал выше, мне видится наиболее перспективным сейчас. Ребята большие молодцы, хорошо развивают свой проект.
В то же время, тогда когда мы его пробовали ранее, продукт был сильно сырым.
Когда мы только начали делать инструмент, сторонние инструменты были другие, да. И с тех пор немало эволюционировали.
А битбакет разве поддерживает self-hosted установку? Гитхаб может, но стоит очень уж дорого.
Не совсем. Бранчдифф это почти то же самое что пулл реквест. Но без необходимости создания отдельной сущности. И более динамичный.
Простой пример — в коде ошибка. Идеология пулл-реквестов во-первых откладывает ее обнаружение на более поздний срок. На момент, когда девелопер оформит пулл-реквест и по нему начнутся автоматические проверки (например). А во-вторых, чтобы ошибку исправить надо пулл реквест отменить и создать новый. Это лишнее время.
В случае с бранчдиффами этого ничего не нужно. Для простоты можно считать что бранчдифф это пулл-реквест, но без лишней бюрократии :)
Ну почему же, такой подход может существовать. Но если взять в уравнение скорость, необходимость аккуратного внедрения в текущий процесс, на текущих задачах, учесть размер компании и ее рост, то все становится не так очевидно. Можно заставить 250 инженеров «правильно» оформлять коммиты перед пушем, но зачем? Какая бизнесу от этого польза?
Хороший вопрос. У меня есть отдельная статья про «правильное» ревью и «неправильное» ревью, где я описываю распространённые ошибки. Скоро опубликуем и подискутируем там в комментариях.
Спасибо!
Компании не нужен «мальчик для битья». Хорошей компании, конечно, ведь случаи разные бывают.
От наказания особой пользы нет. Нужно чтобы чел решал задачи компании. Отсюда и формируется список обязанностей. У кого-то он может быть сильно формальным и расписанным от и до. У кого-то более-менее размытый.
А ответственность должна вознаграждаться соответственно, иначе ее мало кто на себя согласится взять. Но все измерять деньгами конечно же не нужно. Деньги — слабый и краткосрочный мотиватор. Факторов в уравнении сильно больше.
Тимлид (как и другие управленцы) ответственность на себя берет сам, ему ее не «спихивают». А вот как он дальше эту ответственность реализует, как раз и отличает условного тимлида от условного топ-менеджера.
Due date разработчик выдает не в одно лицо, а как минимум, посоветовавшись с менеджером/техническим лидом. Научить все-таки пытаемся, но бывает всякое. Если совсем не получается — признаем что конкретный человек в фичевую разработку не подходит и расстаемся с ним. Это не обязательно означает увольнение. Может быть переход в нефичевую команду, например.
Это просто разработчик в команде. Уровень может быть разный и мы даем «порулить» фичей новичкам в том числе. Под присмотром более опытных, разумеется — для того, чтобы более слабые набирались опыта.
Обучаем/находим — зависит от. Чаще очень трудно найти полностью готового специалиста по абсолютно всем параметрам, поэтому обычно найм — это компромисс. И мы даем время человеку на то, чтобы он подтянул свои навыки после. Бывает так, что отличный разработчик, который не может менеджить задачи, уходит. Нам не нужны «кодеры», нам нужны взрослые, думающие программисты.
Микропроджектменеджер пишет сам код, да. Пропорция менеджмента/программирования зависит от многих факторов: опыт, «чутье», размер фичи и т.д.
Т.е. Володя все-таки должен общаться с продакт-менеджером, дизайнерами, бухгалтерами
Угу. Если Родина требует, то куда деваться?
Я вот читаю, что у меня и у технического менеджера должно быть много свободного времени.
А я считаю что я не должен ходить на работу. Но иногда все-таки нужно, верно?
Видели бы вы тоску в его глазах, когда я очередной раз появляюсь на пороге…
Видел, и много раз. Но есть «хочу», а есть «нужно».
какую помощь он может дать? Дать людей?
Очень сильно зависит от. Увеличить людей — самый простой способ. Утверждаю что есть еще масса вещей, которые стоит попробовать. Главное — результат. А как каждый конкретный Володя его добьется — дело десятое. За это мы Володь и ценим.
Нет, вообще не понятна суть. Я не могу на стороне.
И это прекрасно. Значит у вас нет иного выхода, кроме как «задолбать» своего дизайнера, чтобы он сделал как надо. В этом и суть. У нас нет задачи сделать вам комфортно (уж извините, при всем уважении). У нас задача — дать результат. Следовательно мы пушим всех, и вас в том числе (в данном примере), действовать на результат, выводя вас из зоны комфорта.
Ну смотрите, Андрей.
С точки зрения дат, ситуация Васи и Пети не отличается ничем. А вот с точки зрения ответственности, отличается. В чем преимущество Васи? В том, что он — «пушер». Он «драйвер» и двигатель всех процессов. Может ли он что-то требовать? Может, если это ему поможет сделать задачу эффективнее. Он может просить, убеждать, требовать, взывать к помощи менеджера — не важно.
Если задачу во время не сделал Петя, то ничего страшного. Ну не сделал, и не сделал. А вот для Васи любой исход означает вопрос: «как сделать быстрее»? Его не оштрафуют. Но его обязательно спросят, как быть быстрее в следующий раз.
Про пример с гайдлайнами и вопросом кто будет рисовать — это неважно. Пушить процесс будет Вася. Если он нарисует лучше чем дизайнер, то хорошо. Но скорее всего, дизайнет нарисует лучше. А вот прийти к дизайнеру и направить его на путь истинный должен Вася. Если он прийдет к дизайнеру и тому некогда, то Вася может заказать дизайн на стороне (я сейчас совсем-совсем утрирую, но надеюсь, суть понятна).
Не важно кто и что делает, у кого хватает ресурсов и у кого есть желание что-то делать. Главное — результат. И для его достижения нужна какая-то цель. Такой «универсальной целью» во многих ситуациях и выступает Due date.
Да, так яснее, спасибо.
Я так и ожидал, что будет ответ вроде «по-разному бывает». Это нормально, именно для того мы правила задаем и процессы создаем, чтобы в коллективе могли работать и приносить пользу компании практически все. И понимающие и не понимающие. И согласные и не согласные.
И здорово, если в компании все разработчики толковые и понимающие. Но что если не все? Или как вновь прибывших внедрять и воспитывать правильно?
Многие из моих утверждений в статье спорные. Это сделано намеренно, чтобы читатель задумался, задал себе вопрос «какого фига?». А может и в комментариях со мной подискутировал :)
Изначально в гите встроенных средств для коллективного ревью кода нет. Поэтому пришлось искать что-то подходящее.
В то время как для мержа веток все есть из коробки. git merge нас устраивает чуть более чем полностью.
Вводная:
1) Инструмент должен быть self-hosted.
2) Инструмент должен иметь возможность доработки по мере появления запросов на новые фичи.
3) Бесплатный опенсорсный лучше платного проприетарного :)
4) Инструмент должен поддерживать разделение доступа по репозиториям.
5) Общее кол-во репозиториев в системе — чуть менее 250.
6) Самый большой репозиторий содержит ~130 тысяч файлов, весит около 5 гигабайт. История коммитов в нем на текущий момент ~ 670 тысяч коммитов.
Большинство инструментов, которые мы пробовали, начинали фейлить на 6м пункте — загружали историю нашего репозитория по нескольку дней, недель и т.д. И потом безумно тупили. codeisok же не делает никаких внутренних индексов и работает поверх гита. Получается быстро.
В то же время, тогда когда мы его пробовали ранее, продукт был сильно сырым.
Ах да, атлассиан. Уже вижу с каким скрипом это будет у нас работать. И лицензия на 500 пользователей под 20к стоит.
За ссылку спасибо.
Когда мы только начали делать инструмент, сторонние инструменты были другие, да. И с тех пор немало эволюционировали.
А битбакет разве поддерживает self-hosted установку? Гитхаб может, но стоит очень уж дорого.
Не совсем. Бранчдифф это почти то же самое что пулл реквест. Но без необходимости создания отдельной сущности. И более динамичный.
Простой пример — в коде ошибка. Идеология пулл-реквестов во-первых откладывает ее обнаружение на более поздний срок. На момент, когда девелопер оформит пулл-реквест и по нему начнутся автоматические проверки (например). А во-вторых, чтобы ошибку исправить надо пулл реквест отменить и создать новый. Это лишнее время.
В случае с бранчдиффами этого ничего не нужно. Для простоты можно считать что бранчдифф это пулл-реквест, но без лишней бюрократии :)
Ну почему же, такой подход может существовать. Но если взять в уравнение скорость, необходимость аккуратного внедрения в текущий процесс, на текущих задачах, учесть размер компании и ее рост, то все становится не так очевидно. Можно заставить 250 инженеров «правильно» оформлять коммиты перед пушем, но зачем? Какая бизнесу от этого польза?
Хороший вопрос. У меня есть отдельная статья про «правильное» ревью и «неправильное» ревью, где я описываю распространённые ошибки. Скоро опубликуем и подискутируем там в комментариях.
Спасибо!
От наказания особой пользы нет. Нужно чтобы чел решал задачи компании. Отсюда и формируется список обязанностей. У кого-то он может быть сильно формальным и расписанным от и до. У кого-то более-менее размытый.
А ответственность должна вознаграждаться соответственно, иначе ее мало кто на себя согласится взять. Но все измерять деньгами конечно же не нужно. Деньги — слабый и краткосрочный мотиватор. Факторов в уравнении сильно больше.
Обучаем/находим — зависит от. Чаще очень трудно найти полностью готового специалиста по абсолютно всем параметрам, поэтому обычно найм — это компромисс. И мы даем время человеку на то, чтобы он подтянул свои навыки после. Бывает так, что отличный разработчик, который не может менеджить задачи, уходит. Нам не нужны «кодеры», нам нужны взрослые, думающие программисты.
Микропроджектменеджер пишет сам код, да. Пропорция менеджмента/программирования зависит от многих факторов: опыт, «чутье», размер фичи и т.д.
Угу. Если Родина требует, то куда деваться?
А я считаю что я не должен ходить на работу. Но иногда все-таки нужно, верно?
Видел, и много раз. Но есть «хочу», а есть «нужно».
Очень сильно зависит от. Увеличить людей — самый простой способ. Утверждаю что есть еще масса вещей, которые стоит попробовать. Главное — результат. А как каждый конкретный Володя его добьется — дело десятое. За это мы Володь и ценим.
И это прекрасно. Значит у вас нет иного выхода, кроме как «задолбать» своего дизайнера, чтобы он сделал как надо. В этом и суть. У нас нет задачи сделать вам комфортно (уж извините, при всем уважении). У нас задача — дать результат. Следовательно мы пушим всех, и вас в том числе (в данном примере), действовать на результат, выводя вас из зоны комфорта.
С точки зрения дат, ситуация Васи и Пети не отличается ничем. А вот с точки зрения ответственности, отличается. В чем преимущество Васи? В том, что он — «пушер». Он «драйвер» и двигатель всех процессов. Может ли он что-то требовать? Может, если это ему поможет сделать задачу эффективнее. Он может просить, убеждать, требовать, взывать к помощи менеджера — не важно.
Если задачу во время не сделал Петя, то ничего страшного. Ну не сделал, и не сделал. А вот для Васи любой исход означает вопрос: «как сделать быстрее»? Его не оштрафуют. Но его обязательно спросят, как быть быстрее в следующий раз.
Про пример с гайдлайнами и вопросом кто будет рисовать — это неважно. Пушить процесс будет Вася. Если он нарисует лучше чем дизайнер, то хорошо. Но скорее всего, дизайнет нарисует лучше. А вот прийти к дизайнеру и направить его на путь истинный должен Вася. Если он прийдет к дизайнеру и тому некогда, то Вася может заказать дизайн на стороне (я сейчас совсем-совсем утрирую, но надеюсь, суть понятна).
Не важно кто и что делает, у кого хватает ресурсов и у кого есть желание что-то делать. Главное — результат. И для его достижения нужна какая-то цель. Такой «универсальной целью» во многих ситуациях и выступает Due date.
Удачи!
Я так и ожидал, что будет ответ вроде «по-разному бывает». Это нормально, именно для того мы правила задаем и процессы создаем, чтобы в коллективе могли работать и приносить пользу компании практически все. И понимающие и не понимающие. И согласные и не согласные.
И здорово, если в компании все разработчики толковые и понимающие. Но что если не все? Или как вновь прибывших внедрять и воспитывать правильно?
Многие из моих утверждений в статье спорные. Это сделано намеренно, чтобы читатель задумался, задал себе вопрос «какого фига?». А может и в комментариях со мной подискутировал :)