Комментарии 38
Читаю после работы и может быть чего-то недопонимаю, но такое ощущение, что это недописанный черновик статьи. Слишком много моментов опущено.
Например, почему сложно создать задачу? Jira давно и не очень активно пользовался, неужели настолько сложно создать задачу? Не припоминаю таких сложностей.
Почему используются текстовые патчи, которые надо копи-пейстить в форму? Чем хуже стандартная функциональность pull request?
Спасибо за комментарий )
Почему сложно создать задачу? Честно говоря, тоже не понимаю. Мне до сих пор кажется, что это минута времени и достаточно просто, но разработчики сопротивляются. Если кто-то поделится, в чем реально сложность — с удовольствием почитаю.
С pull request сложнее. Для меня основная причина их отсутствия — они не сделают процесс удобнее. Сейчас вы делаете изменения, копируете их и добавляете в интерфейс. Не нужно создавать специальных веток нигде. Ну и это какие-то дополнительные сложности для нас (РЕ) в поддержке. У нас будет новый вид веток, которые надо отличать от стандартных, для которых будет другой набор хуков выполняться, например (у нас их много, но мы не все гоняем для патчей — кому важно, как отформатирован код, если сайт лежит?).
Когда-то давно у нас в компании каждый мог вносить свои изменения прямо в ветку мастера
GitFlow? Нет, не слышали…
но разработчики сопротивляются
Если нет объективных причин у разработчиков, то у вас просто не хватает волевого решения, зачем вам тогда руководители…
Выход, как я вижу укрупнять задачи.
Странно что в статье не написанно про тестирование. Раскатка идет сразу в прод сервера? Есть ли автотесты?
Выход, как я вижу укрупнять задачи.
Странное решение. У меня лежит прод и я могу поднять его одной строчкой. НО… не поправить ли мне за одно вон те стили, чтобы дифф был не маленьким? Так? :)
Странно что в статье не написанно про тестирование. Раскатка идет сразу в прод сервера? Есть ли автотесты?
Тесты запускаются: необходимый набор unit-тестов (высчитывается из кавереджа) и smoke-тесты. Думаю, автор не упомянул об этом потому, что это не имеет непосредственного отношения к истории создания и устройству системы патчей.
При этом еще нужно понять почему лежит? почему не дотестировали? Как предотвратить в будушем?
А заниматься разбором того, почему сломали, почему не дотестировали и как предотвратить в будущем, стоит уже после.
Надеюсь, я правильно понял суть Вашего вопроса. Он довольно сумбурный на мой взгляд.
Немного дополню ответ nizkopal: уже после того, как мы все починили, мы начинаем задавать вопросы "а что было?" и "как предотвратить?". В этом процессе мы обычно пишем штуку под названием постмортем, и об этом у нас рассказывал ableev в своем докладе.
P.s. А еще, у меня сложилось впечатление (возможно, ложное), что Вы немного смешали обычные задачи и патчи. У нас есть стандартный флоу, я на нем не останавливался, но "обычные" задачи уезжают дважды в каждый рабочий день: утром и вечером (в пятницу — только утром). А вот hotfix'ы часто закрываются патчами.
По поводу волевого решения — не сомневайтесь, там где нужно поднажать, поднажимаем. Но необходимо так же помнить о том, что рабство запрещено некоторое время назад. К тому же наша компания (как и многие другие) — не армия. И способов мотивации сотрудников тогда, когда это действительно нужно, сильно больше чем «кнут» и «пряник».
Причем тут рабство и армия, я про здоровую субординацию и направление развития. Вы же не станете соглашаться, что каждый сотрудник у вас независим, работает за «печеньки» и делает только то, что он сам хочет. Не надо уж так утрировать
С pull request сложнее. Для меня основная причина их отсутствия — они не сделают процесс удобнее. Сейчас вы делаете изменения, копируете их и добавляете в интерфейс. Не нужно создавать специальных веток нигде.
Считаем на пальцах.
Сейчас, как понимаю, что-то типа такого:
1. Выводим дифф на экран (кстати, как это делается у вас?)
2. Копируем в буфер
3. Открываем броузер
4. Открываем страницу с «интерфейсом»
5. Вставляем дифф и жмакаем кнопку «Готово»
6. Если забыли что-то добавить, то или забиваем или повторяем всю операцию для хотфикса
С обычными гитовскими ветками процесс будет примерно в три команды:
git branch my-new-feature
###.... правим код
git commit -a --verbose
git push
По-моему, написать три команды — более удобный процесс, чем жонглирование окнами броузера и буферами обмена, нет?
Кажется, Вы забываете о том, что наша система в первую очередь нужна для маленьких изменений и hotfix'ов. У нас есть отдельный стандартный флоу с my-new-feature ветками, где есть (достаточно сложный, к слову) процесса auto-merge, который сам заберет вашу задачу, если вы в день релиза находитесь в офисе.
Возвращаясь к патчам, здесь все равно придется открывать браузер: нужно отметить человека, который будет делать ревью, выбрать ветку (или вставить дифф в нашем случае) и отметить задачу, к которой это все относится.
Ну и посмотрите на разницу в командах:
git checkout -b {branch} && git commit -am {message} && git pushvs
git diff | pbcopyНаверное, оно выглядит интуитивно понятнее для Вас, но уверяю, что это просто дело привычки. На практике, оно не будет так уж здорово. Хотя я признаюсь, что мне хотелось бы найти что-то более интуитивное, простое и "гиковское" (в хорошем смысле этого слова) на замену простому копированию из консоли в браузер.
P.s.
Выводим дифф на экран (кстати, как это делается у вас?)
Если вы про терминал, откуда обычно копируют изменения — git-diff, но мне показалось, что вопрос прозвучал более обширно. У нас есть собственная тулза для ревью изменений в коде, называется codeisok, мы выложили ее недавно в open-source. Этот инструмент получился путем сильной переделки старого gitphp (не нашего) и мы писали об этом, если вам интересно :)
В чем преимущество усложнения системы дополнительными обвязками в виде контейнеров? К тому же там, где подобное необходимо, мы докер вполне используем. banuchka даже про это доклады и статьи делал.
Но ведь в таких условиях возникает масса проблем, часть которых вы тут тоже затронули, и которые как раз и решаются переходом от монолитной к распределённой архитектуре, с быстрыми и однозначно репродуцируемыми сборками отдельных компонентов. Тогда появляется смысл эти компоненты распихать по контейнерам и отправить в дальнее странствие по кубернетесовым облакам.
У нас сложный процесс сборки и раскладки, это правда, но он не долгий. Я писал в статье про время, но оно не катастрофическое: в этой части истории сборка и раскладка занимали где-то минут 10-12 с инкрементальной сборкой статики. Оно покажется большим только в сравнении: mscp позволяет разложить изменения за минуту.
Что касается микросервисов, тут ведь вопрос не только в раскладке изменений. Такой подход изменит весь процесс разработки и тестирования, а текущий вариант нас вполне устраивает. Менять же свою жизнь настолько сильно только ради деплоя — звучит как не самая хорошая идея. Более того, я думаю, что с отдельными сервисами есть свои сложности. У нас есть команда, которая пишет сервисы (хоть и не всегда микро) и с ними хватает проблем :)
P.s. Но в отрыве от всего этого, идея с оркестрируемым решением, конечно, выглядит красивой.
Почему не пользуетесь стандартным функционалом git (или аналогов)?
Create branch, commit, push, merge.
Даже если у вас разработчики на диалапе и имеют доступ только к е-мейлу, есть же git format-patch и git am.
А в чем преимущества у использования git-format-patch перед отдельной формой на сайте?
Можно вот это пояснить, пожалуйста? Ветки в гит – базовая фича, какая еще поддержка нужна?
> А в чем преимущества у использования git-format-patch перед отдельной формой на сайте?
Они вообще о разном.
Я видимо неверно прочитал «чтобы она позволяла любому разработчику присылать свои изменения в Git и раскладывать их на серверы».
Я посчитал, что у некоторых людей прямого доступа к репе нет (например, у находящихся на необитаемом острове) и им приходится отправлять свои патчи по е-мейл, эти две команды для того и сделаны.
Если же линк до сервера с репой есть, то конечно, для всех удобнее будет делать пуш в репу напрямую.
не github, не bitbucket, которые действительно предоставляют функционал для pull request-ов из коробки, а просто git репозиторий.
основная сложность тут не в том, чтобы доставить ваш diff в систему контроля версий, а в том, чтобы организовать всю обвязку вокруг.
помимо diff-а, вам нужно через какой-то ui:
— выбрать ревьюера
— выбрать тикет к которому прилинковать hotfix
— автоматом прогнать unit и smoke тесты
— дождаться пока ревьюер нажмет approve
— дождаться, пока разработчик нажмет кнопку «все готово, поехали на продакшен»
(делать это сразу после approve не очень хорошая идея)
— выложить hotfix на продакшен и замержить в мастер
конкретный способ доставки diff-а в эту систему тут вообще не играет никакой роли, самое важное и сложное — это как раз все последующие шаги.
и раз уж вы все равно делаете веб-интерфейс для их реализации, логичным выглядит добавление туда поля diff, чтобы не придумывать сложный механизм автоматического обнаружения этих hotfix-веток.
если говорить о детялах, то положить git diff в clipboard отличается от git format-patch по сути только оформлением, суть абсолютно одна и та же.
глубокое понимание состояния человека.
Тут взоржал и заплакал одновременно. Атака нейронок через рекламку распознаётся на раз-два, но это зомби-стайл же. Подсказываю: нет, люди не любят уничтожать зомби тысячами и миллионами. Ибо уныло.
Как я почитал статью: «Ну, нам тут надо код ревью настроить. Да не, нафиг существующие тулы, запилим свое. Да не, нафиг нативная работа с гитом, будем фигачить код в формочку на сайте». WTF?
Я, конечно, недолюбливаю Gerrit, но в нашей компании он и используется. И, представьте себе, он делает именно то, что вы описали. Разработчик сделал коммит -> «git review» -> коммит появился в веб-интерфейсе, емейл-нотификашки прилетели всем указанным ревьюверам, коммит получил +2 от другого разработчика — можно замержить в мастер (одной кнопкой Submit в интерфейсе). В вашем же случае это какой-то ад — скопировать текст(!) патча, руками ввести чего куда, а если есть замечания по ревью, то опять повторять этот процесс? Да вы шутите…
Дальше как вы уже с мастера деплоите, это другая тема, не имеющая отношения к ревью.
Все их можно адаптировать, но они так или иначе нам не подходят. Те же иструменты для ревью кода плохо справляются с нашими объемами репозиториев и ужасно медленно идексируют новые изменения. И теперь представьте: вы хотите быстрее разложить изменения, потому что знаете, что пользователи не могут зайти на сайт, а Вася не может ваш код поревьюить, потому что какой-нибудь fisheye не успел обновить у себя код.
Мы видим, что сторонние инструменты не стоят на месте и потихоньку становятся лучше. Периодически мы просмотриваем их с целью «выкинуть самописное — заменить готовым», но пока они не работают у нас, нам приходится как-то жить. Я бы даже предложил написать статью с обзором, но я боюсь, что у нас часто очень специфические требования и такой обзор будет достаточно бесполезным для других.
Я все еще вас не понимаю. О какой индексации речь? Пуш — и коммит мгновенно появляется в интерфейсе. Сабмит — и коммит мгновенно мержится в мастер.
>вы хотите быстрее разложить изменения, потому что знаете, что пользователи не могут зайти на сайт
Скажите честно, как часто у вас случается, что «пользователи не могут зайти на сайт»? Я, конечно, не эксперт, но если Вася пупкин сломал прод своим коммитом, а до этого в течение месяца вся команда по разу ложила прод — это вам не ревью, а тестирование и многоуровневое развёртывание надо улучшать. Я вижу ситуацию «прод лежит, срочно хотфикс» как очень исключительную и разовую и в таком случае даже можно пропушить фикс без ревью имхо — бизнес важнее. Поэтому я вас опять не понимаю.
В нашей компании от пуша на ревью до мержа в мастер в среднем проходит около 2 дней, пока другие разработчики поревьювят, потом исправить замечания и пр.
Простите, я немного не так вас понял изначально, конечно, у нас есть полноценный флоу с фича-ветками и ревью. Никогда не мерили статистику, но наверное, у нас приблизительно такие же цифры — 1-2 дня с момента создания ветки до ее публикации. Но, помимо этого, у нас так же есть механизм быстрофиксов, о которых я говорил тут.
Держать две тулзы: для быстрофиксов и для обычного флоу отдельных не очень хочется.
Скажите честно, как часто у вас случается, что «пользователи не могут зайти на сайт»?
Нет, на моей памяти было 1 раз за 6 лет и тогда мы просто откатили билд. У нас бывают действительно серьезные проблемы, но намного чаще бывает что-то совсем незначительное. Хорошим примером было бы что-то из разряда удалили код, забыли убрать сбор статистики. В итоге падает большое количество бесполезных ошибок. Можно потерпеть? Однозначно, но проще убрать — за фоном ошибок можно не заметить серьезной проблемы.
Ну, нам тут надо код ревью настроить. Да не, нафиг существующие тулы, запилим свое.
Я только сейчас осознал до конца этот момент. А что нам надо было взять? Это было много лет назад, тогда просто не было альтернатив подходящих. Мы взяли gitphp и он нам понравился. Нам не хватило каких-то механизмов — мы их допилили. Разве что стоило выложить изменения в open-source раньше, чем мы это сделали.
Я все еще вас не понимаю. О какой индексации речь? Пуш — и коммит мгновенно появляется в интерфейсе. Сабмит — и коммит мгновенно мержится в мастер.
Конкретно тут я говорю о нашем опыте использования другого инстурмента. Gerrit, если мне не изменяет память, не очень подходил нашему основному флоу, но лучше об этом спросить uyga
Закончил вторую часть статьи, где рассказал, как мы добавили возможность эксперментировать с кодом без коммита в master и научились-таки патчить статику :)
Patch me if you can: как мы отлаживаемся на production. Часть 1