В тестовом репозитории я пытался сделать минимум всего, просто чтобы показать проблему: коммита действительно не видно. Показалось что было бы приятно иметь возможность «пощупать» самому то, о чем идет рассказ :)
Так у нас такая же ситуация как по вашей ссылке на stackoverflow: у разработчика есть ветка с его кодом, которая конфликтует с мастером. Разработчик подтягивает мастер к себе в ветку, разрешая конфликт «в пользу своих изменений». Потом уже его ветка попадает в мастер, и уже без конфликтов, а мы получаем всю эту историю с потерянным коммитом.
Тогда скорее можно попробовать упрекнуть процесс/инструмент ревью кода. Или там не было видно изменений (и тогда это проблема инструмента) или изменения просто не заметили или пропустили (и тогда это проблема разработчика/процесса). К сожалению, у нас именно последний вариант (не заметили — изменений было банально слишком много).
В целом тут можно пофилосовствовать дальше: не стоило делать такие большие изменения в одной ветке, например. Это правда, но этого может быть тяжело добиться и тяжело заставить людей следовать такому правилу.
Предположу, что странным может показаться что разработчик просто выкинул чужие изменения, но и конфликт там был в очень большом количестве файлов — в ветке делали рефакторинг системы, насколько я понял.
Спасибо, я действительно ошибся. Я точно помню что не обратил внимание на этот раздел, когда смотрел документацию в попытке разобраться, что происходит. Могу только предположить, что искал в документации какие-то комментарии к флагу --follow. А на раздел наткнулся уже после того, как залез в код.
Намного позже, когда писал статью, решил что не просто не заметил этого куска, а его не было. Конкретно из-за этого коммита: в нем в документацию git-log добавилось include::rev-list-description.txt[]
а вот include::rev-list-options.txt[]
уже там было (похоже где-то лет 10 как). Простите, немного человеческой невнимательности :)
Это сложнее. Jira не предоставляет удобного способа создания каких-либо webview. Большинство встроенных операций представляют из себя стандартные экраны (screen), в которых можно настроить только список полей. Для создания чего-то кастомного, нужно смотреть в сторону плагинов: или писать полностью свои или использовать какие-то готовые. Например, в script runner есть возможность добавлять собственные web элементы в интерфейс, в том числе, можно вызывать dialogs при нажатии на кнопку.
Но последнее, конечно, сложнее, чем сделать простую форму на отдельной странице :)
Не все, еще один этап тестирования — в билде, когда тестировщики снова прогоняют все тесты и смотрят задачи. Этот этап важен еще и потому, что две задачи могут работать по отдельности и не работать вместе.
Вообще я не очень хотел останавливаться на выборе способа раскладки. От части, оно было бы здесь уместно, но мне было интереснее рассказать о том, чего мы добились именно с патчами. В конце концов, о процессе раскладки не плохо рассказывает Юра в своем докладе (хотя я понимаю, что не все его посмотрят — я сам люблю статьи больше, чем видео), а еще немного о требованиях может стать понятно из прочтения первой части статьи.
В целом я немного удивлен, что именно эта часть статьи такая комментируемая, думал что люди чаще будут писать о своем опыте "багфиксинга", это было бы интересно (по крайней мере мне) почитать.
Кажется, разобрался. Не сразу сообразил, что под томами вы имеете ввиду volume, не был знаком с этим термином в русскоязычном варианте.
Не могу сказать, что это выглядит просто, если честно. Иногда кажется, что докер все-таки не так удобен для скриптовых языков программирования — теряется часть их (языков) преимуществ в виде простой замены части файлов с кодом (именно простой, придумать вариант всегда можно). С другой стороны, не человеку из компании, придумавшей целую систему для замены файликов, говорить о простоте :)
Все в этой жизни масштабируется, вопрос в трудозатратах. Но мне хочется другую сторону вопрос обсудить: а вы решаете вопрос доставки? Зачем в этой задач git-pull- и rsync- контейнеры, почему не сделать это просто на системе? Мне правда интересно, что с этого можно получить.
Статика собирается с хешом в именах файлов, так что на cdn спокойно живут версии разных файлов.
Т.е. статика у вас будет выглядеть как у нас код, только без карт содержимого?
Если рассматривать только эти два требования — да, это сработает. Но в таком варианте вам нужно следить за тем, чтобы выкладывать код не чаще, чем max_execution_time скрптов или запросов, которые этот код используют.
В нашем случае, это плохо работает потому, что у нас есть скрипты, которые работают часами. Если я ничего не путаю, то мы договаривались что версия кода должна оставаться «рабочей» на машине в течение 2 часов. Не могу сказать, что мне нравится это требование, но с ним приходится жить. Для статистики могу добавить, что за 2 последних часа вчерашнего дня мы выложили 28 версий кода, т.е. нам понадобилось бы 28 рабочих директорий. Это все еще можно использовать, но с Git и доставлять не так удобно, особенно, сгенерированные файлы.
А вы уверены что если вот так брать и откусывать кусок байт от хэша, то оно хоть сколько-то адекватно будет работать?
Лавинный эффект позволяет так думать. Если лень читать, то это свойства, при котором выход функции будет сильно, "лавинно", меняться при небольшом изменении входа.
Взятие первых 32 бит от MD5 является типичным алгоритмом хэширования?
Я знаю, что так часто делают — берут кусок хэша. Наверное, это не очень оптимально, но я описал выше, почему, как мне кажется, это должно давать более-менее приличный результат.
И там ведь сверху ещё велосипедик навёрнут
Я думаю, что стоило "подстелить" этот велосипед еще в самом начале, потому что даже полный md5 хэш не гарантирует, что коллизии не будет. Этот шаг — скорее попытка разрешить коллизию, когда она появится, чем полностью предотвратить ее.
Мы берем первые 8 из этих чисел, которые, по сути, просто символы из набора [0-9a-f]. Немного удивлен вопросу, потому что думал что неподготовленному человеку это должно быть более понятно. Постараюсь с утра придумать альтернативный, лаконичный вариант, спасибо!
Упустили, когда делал опрос и я думаю что сейчас уже совсем не круто менять варианты, но это здорово, что вы отписались тут. А не расскажите, чем у вас отличается цикл тестирования багфикса от полного и почему? Не гоняете автотесты или только автотестами и обходитесь? Может, какой-то промежуточный вариант?
И прям очень интересно было бы узнать, насколько автоматизирован процесс, если не хотите описывать, то может хотя бы оцените по шкале 0-10 баллов?
Закончил вторую часть статьи, где рассказал, как мы добавили возможность эксперментировать с кодом без коммита в master и научились-таки патчить статику :)
Простите, я немного не так вас понял изначально, конечно, у нас есть полноценный флоу с фича-ветками и ревью. Никогда не мерили статистику, но наверное, у нас приблизительно такие же цифры — 1-2 дня с момента создания ветки до ее публикации. Но, помимо этого, у нас так же есть механизм быстрофиксов, о которых я говорил тут.
Держать две тулзы: для быстрофиксов и для обычного флоу отдельных не очень хочется.
Скажите честно, как часто у вас случается, что «пользователи не могут зайти на сайт»?
Нет, на моей памяти было 1 раз за 6 лет и тогда мы просто откатили билд. У нас бывают действительно серьезные проблемы, но намного чаще бывает что-то совсем незначительное. Хорошим примером было бы что-то из разряда удалили код, забыли убрать сбор статистики. В итоге падает большое количество бесполезных ошибок. Можно потерпеть? Однозначно, но проще убрать — за фоном ошибок можно не заметить серьезной проблемы.
Ну, нам тут надо код ревью настроить. Да не, нафиг существующие тулы, запилим свое.
Я только сейчас осознал до конца этот момент. А что нам надо было взять? Это было много лет назад, тогда просто не было альтернатив подходящих. Мы взяли gitphp и он нам понравился. Нам не хватило каких-то механизмов — мы их допилили. Разве что стоило выложить изменения в open-source раньше, чем мы это сделали.
Я все еще вас не понимаю. О какой индексации речь? Пуш — и коммит мгновенно появляется в интерфейсе. Сабмит — и коммит мгновенно мержится в мастер.
Конкретно тут я говорю о нашем опыте использования другого инстурмента. Gerrit, если мне не изменяет память, не очень подходил нашему основному флоу, но лучше об этом спросить uyga
P.s. Лишнюю ветку удалил, спасибо!
Тогда скорее можно попробовать упрекнуть процесс/инструмент ревью кода. Или там не было видно изменений (и тогда это проблема инструмента) или изменения просто не заметили или пропустили (и тогда это проблема разработчика/процесса). К сожалению, у нас именно последний вариант (не заметили — изменений было банально слишком много).
В целом тут можно пофилосовствовать дальше: не стоило делать такие большие изменения в одной ветке, например. Это правда, но этого может быть тяжело добиться и тяжело заставить людей следовать такому правилу.
Предположу, что странным может показаться что разработчик просто выкинул чужие изменения, но и конфликт там был в очень большом количестве файлов — в ветке делали рефакторинг системы, насколько я понял.
Искренне считаю, что самый крутой вариант — это когда в merge добавляют что-нибудь, даже если никакого конфликта не было :)
Намного позже, когда писал статью, решил что не просто не заметил этого куска, а его не было. Конкретно из-за этого коммита: в нем в документацию git-log добавилось
include::rev-list-description.txt[]а вот
include::rev-list-options.txt[]уже там было (похоже где-то лет 10 как). Простите, немного человеческой невнимательности :)
Это сложнее. Jira не предоставляет удобного способа создания каких-либо webview. Большинство встроенных операций представляют из себя стандартные экраны (screen), в которых можно настроить только список полей. Для создания чего-то кастомного, нужно смотреть в сторону плагинов: или писать полностью свои или использовать какие-то готовые. Например, в script runner есть возможность добавлять собственные web элементы в интерфейс, в том числе, можно вызывать dialogs при нажатии на кнопку.
Но последнее, конечно, сложнее, чем сделать простую форму на отдельной странице :)
Вообще я не очень хотел останавливаться на выборе способа раскладки. От части, оно было бы здесь уместно, но мне было интереснее рассказать о том, чего мы добились именно с патчами. В конце концов, о процессе раскладки не плохо рассказывает Юра в своем докладе (хотя я понимаю, что не все его посмотрят — я сам люблю статьи больше, чем видео), а еще немного о требованиях может стать понятно из прочтения первой части статьи.
В целом я немного удивлен, что именно эта часть статьи такая комментируемая, думал что люди чаще будут писать о своем опыте "багфиксинга", это было бы интересно (по крайней мере мне) почитать.
Кажется, разобрался. Не сразу сообразил, что под томами вы имеете ввиду volume, не был знаком с этим термином в русскоязычном варианте.
Не могу сказать, что это выглядит просто, если честно. Иногда кажется, что докер все-таки не так удобен для скриптовых языков программирования — теряется часть их (языков) преимуществ в виде простой замены части файлов с кодом (именно простой, придумать вариант всегда можно). С другой стороны, не человеку из компании, придумавшей целую систему для замены файликов, говорить о простоте :)
Все в этой жизни масштабируется, вопрос в трудозатратах. Но мне хочется другую сторону вопрос обсудить: а вы решаете вопрос доставки? Зачем в этой задач git-pull- и rsync- контейнеры, почему не сделать это просто на системе? Мне правда интересно, что с этого можно получить.
Т.е. статика у вас будет выглядеть как у нас код, только без карт содержимого?
В нашем случае, это плохо работает потому, что у нас есть скрипты, которые работают часами. Если я ничего не путаю, то мы договаривались что версия кода должна оставаться «рабочей» на машине в течение 2 часов. Не могу сказать, что мне нравится это требование, но с ним приходится жить. Для статистики могу добавить, что за 2 последних часа вчерашнего дня мы выложили 28 версий кода, т.е. нам понадобилось бы 28 рабочих директорий. Это все еще можно использовать, но с Git и доставлять не так удобно, особенно, сгенерированные файлы.
Лавинный эффект позволяет так думать. Если лень читать, то это свойства, при котором выход функции будет сильно, "лавинно", меняться при небольшом изменении входа.
Я знаю, что так часто делают — берут кусок хэша. Наверное, это не очень оптимально, но я описал выше, почему, как мне кажется, это должно давать более-менее приличный результат.
Я думаю, что стоило "подстелить" этот велосипед еще в самом начале, потому что даже полный md5 хэш не гарантирует, что коллизии не будет. Этот шаг — скорее попытка разрешить коллизию, когда она появится, чем полностью предотвратить ее.
Как правило, эти 128 бит представляют в виде последовательности из 32 шестнадцатиричных цифр, например так делает стандартная утилита md5sum:
Мы берем первые 8 из этих чисел, которые, по сути, просто символы из набора [0-9a-f]. Немного удивлен вопросу, потому что думал что неподготовленному человеку это должно быть более понятно. Постараюсь с утра придумать альтернативный, лаконичный вариант, спасибо!
И прям очень интересно было бы узнать, насколько автоматизирован процесс, если не хотите описывать, то может хотя бы оцените по шкале 0-10 баллов?
Закончил вторую часть статьи, где рассказал, как мы добавили возможность эксперментировать с кодом без коммита в master и научились-таки патчить статику :)
Простите, я немного не так вас понял изначально, конечно, у нас есть полноценный флоу с фича-ветками и ревью. Никогда не мерили статистику, но наверное, у нас приблизительно такие же цифры — 1-2 дня с момента создания ветки до ее публикации. Но, помимо этого, у нас так же есть механизм быстрофиксов, о которых я говорил тут.
Держать две тулзы: для быстрофиксов и для обычного флоу отдельных не очень хочется.
Нет, на моей памяти было 1 раз за 6 лет и тогда мы просто откатили билд. У нас бывают действительно серьезные проблемы, но намного чаще бывает что-то совсем незначительное. Хорошим примером было бы что-то из разряда удалили код, забыли убрать сбор статистики. В итоге падает большое количество бесполезных ошибок. Можно потерпеть? Однозначно, но проще убрать — за фоном ошибок можно не заметить серьезной проблемы.
Я только сейчас осознал до конца этот момент. А что нам надо было взять? Это было много лет назад, тогда просто не было альтернатив подходящих. Мы взяли gitphp и он нам понравился. Нам не хватило каких-то механизмов — мы их допилили. Разве что стоило выложить изменения в open-source раньше, чем мы это сделали.
Конкретно тут я говорю о нашем опыте использования другого инстурмента. Gerrit, если мне не изменяет память, не очень подходил нашему основному флоу, но лучше об этом спросить uyga