• Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет
    0
    А на жире не смогли такое сделать?

    Это сложнее. Jira не предоставляет удобного способа создания каких-либо webview. Большинство встроенных операций представляют из себя стандартные экраны (screen), в которых можно настроить только список полей. Для создания чего-то кастомного, нужно смотреть в сторону плагинов: или писать полностью свои или использовать какие-то готовые. Например, в script runner есть возможность добавлять собственные web элементы в интерфейс, в том числе, можно вызывать dialogs при нажатии на кнопку.


    Но последнее, конечно, сложнее, чем сделать простую форму на отдельной странице :)

  • Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет
    +1
    Не все, еще один этап тестирования — в билде, когда тестировщики снова прогоняют все тесты и смотрят задачи. Этот этап важен еще и потому, что две задачи могут работать по отдельности и не работать вместе.
  • Patch me if you can: как мы отлаживаемся на production. Часть 2
    0

    Вообще я не очень хотел останавливаться на выборе способа раскладки. От части, оно было бы здесь уместно, но мне было интереснее рассказать о том, чего мы добились именно с патчами. В конце концов, о процессе раскладки не плохо рассказывает Юра в своем докладе (хотя я понимаю, что не все его посмотрят — я сам люблю статьи больше, чем видео), а еще немного о требованиях может стать понятно из прочтения первой части статьи.


    В целом я немного удивлен, что именно эта часть статьи такая комментируемая, думал что люди чаще будут писать о своем опыте "багфиксинга", это было бы интересно (по крайней мере мне) почитать.

  • Patch me if you can: как мы отлаживаемся на production. Часть 2
    0

    Кажется, разобрался. Не сразу сообразил, что под томами вы имеете ввиду volume, не был знаком с этим термином в русскоязычном варианте.


    Не могу сказать, что это выглядит просто, если честно. Иногда кажется, что докер все-таки не так удобен для скриптовых языков программирования — теряется часть их (языков) преимуществ в виде простой замены части файлов с кодом (именно простой, придумать вариант всегда можно). С другой стороны, не человеку из компании, придумавшей целую систему для замены файликов, говорить о простоте :)

  • Patch me if you can: как мы отлаживаемся на production. Часть 2
    0
    Спасибо!
  • Patch me if you can: как мы отлаживаемся на production. Часть 2
    0

    Все в этой жизни масштабируется, вопрос в трудозатратах. Но мне хочется другую сторону вопрос обсудить: а вы решаете вопрос доставки? Зачем в этой задач git-pull- и rsync- контейнеры, почему не сделать это просто на системе? Мне правда интересно, что с этого можно получить.


    Статика собирается с хешом в именах файлов, так что на cdn спокойно живут версии разных файлов.

    Т.е. статика у вас будет выглядеть как у нас код, только без карт содержимого?

  • Patch me if you can: как мы отлаживаемся на production. Часть 2
    0
    Кстати, отличная штука для некоторых задач автоматизации процессов, был очень рад, когда они добавили эту функциональность.
  • Patch me if you can: как мы отлаживаемся на production. Часть 2
    0
    Если рассматривать только эти два требования — да, это сработает. Но в таком варианте вам нужно следить за тем, чтобы выкладывать код не чаще, чем max_execution_time скрптов или запросов, которые этот код используют.

    В нашем случае, это плохо работает потому, что у нас есть скрипты, которые работают часами. Если я ничего не путаю, то мы договаривались что версия кода должна оставаться «рабочей» на машине в течение 2 часов. Не могу сказать, что мне нравится это требование, но с ним приходится жить. Для статистики могу добавить, что за 2 последних часа вчерашнего дня мы выложили 28 версий кода, т.е. нам понадобилось бы 28 рабочих директорий. Это все еще можно использовать, но с Git и доставлять не так удобно, особенно, сгенерированные файлы.
  • Patch me if you can: как мы отлаживаемся на production. Часть 2
    +2
    А вы уверены что если вот так брать и откусывать кусок байт от хэша, то оно хоть сколько-то адекватно будет работать?

    Лавинный эффект позволяет так думать. Если лень читать, то это свойства, при котором выход функции будет сильно, "лавинно", меняться при небольшом изменении входа.


    Взятие первых 32 бит от MD5 является типичным алгоритмом хэширования?

    Я знаю, что так часто делают — берут кусок хэша. Наверное, это не очень оптимально, но я описал выше, почему, как мне кажется, это должно давать более-менее приличный результат.


    И там ведь сверху ещё велосипедик навёрнут

    Я думаю, что стоило "подстелить" этот велосипед еще в самом начале, потому что даже полный md5 хэш не гарантирует, что коллизии не будет. Этот шаг — скорее попытка разрешить коллизию, когда она появится, чем полностью предотвратить ее.

  • Patch me if you can: как мы отлаживаемся на production. Часть 2
    0

    Как правило, эти 128 бит представляют в виде последовательности из 32 шестнадцатиричных цифр, например так делает стандартная утилита md5sum:


    $ echo 1 | md5sum
    b026324c6904b2a9cb4b88d6d61c81d1  -

    Мы берем первые 8 из этих чисел, которые, по сути, просто символы из набора [0-9a-f]. Немного удивлен вопросу, потому что думал что неподготовленному человеку это должно быть более понятно. Постараюсь с утра придумать альтернативный, лаконичный вариант, спасибо!

  • Patch me if you can: как мы отлаживаемся на production. Часть 2
    +1
    Упустили, когда делал опрос и я думаю что сейчас уже совсем не круто менять варианты, но это здорово, что вы отписались тут. А не расскажите, чем у вас отличается цикл тестирования багфикса от полного и почему? Не гоняете автотесты или только автотестами и обходитесь? Может, какой-то промежуточный вариант?

    И прям очень интересно было бы узнать, насколько автоматизирован процесс, если не хотите описывать, то может хотя бы оцените по шкале 0-10 баллов?
  • Patch me if you can: как мы отлаживаемся на production. Часть 1
    +2

    Закончил вторую часть статьи, где рассказал, как мы добавили возможность эксперментировать с кодом без коммита в master и научились-таки патчить статику :)

  • Patch me if you can: как мы отлаживаемся на production. Часть 1
    +1

    Простите, я немного не так вас понял изначально, конечно, у нас есть полноценный флоу с фича-ветками и ревью. Никогда не мерили статистику, но наверное, у нас приблизительно такие же цифры — 1-2 дня с момента создания ветки до ее публикации. Но, помимо этого, у нас так же есть механизм быстрофиксов, о которых я говорил тут.


    Держать две тулзы: для быстрофиксов и для обычного флоу отдельных не очень хочется.


    Скажите честно, как часто у вас случается, что «пользователи не могут зайти на сайт»?

    Нет, на моей памяти было 1 раз за 6 лет и тогда мы просто откатили билд. У нас бывают действительно серьезные проблемы, но намного чаще бывает что-то совсем незначительное. Хорошим примером было бы что-то из разряда удалили код, забыли убрать сбор статистики. В итоге падает большое количество бесполезных ошибок. Можно потерпеть? Однозначно, но проще убрать — за фоном ошибок можно не заметить серьезной проблемы.


    Ну, нам тут надо код ревью настроить. Да не, нафиг существующие тулы, запилим свое.

    Я только сейчас осознал до конца этот момент. А что нам надо было взять? Это было много лет назад, тогда просто не было альтернатив подходящих. Мы взяли gitphp и он нам понравился. Нам не хватило каких-то механизмов — мы их допилили. Разве что стоило выложить изменения в open-source раньше, чем мы это сделали.


    Я все еще вас не понимаю. О какой индексации речь? Пуш — и коммит мгновенно появляется в интерфейсе. Сабмит — и коммит мгновенно мержится в мастер.

    Конкретно тут я говорю о нашем опыте использования другого инстурмента. Gerrit, если мне не изменяет память, не очень подходил нашему основному флоу, но лучше об этом спросить uyga

  • Patch me if you can: как мы отлаживаемся на production. Часть 1
    +1
    Я понимаю ваше возмущение, правда. Я знаю, что есть много систем, которые решают проблему мержа изменений: в Gerrit есть описанный вами функционал, в github есть pull request, в teamcity добавили automatic merge и я уверен, что есть еще минимум десяток других решений.

    Все их можно адаптировать, но они так или иначе нам не подходят. Те же иструменты для ревью кода плохо справляются с нашими объемами репозиториев и ужасно медленно идексируют новые изменения. И теперь представьте: вы хотите быстрее разложить изменения, потому что знаете, что пользователи не могут зайти на сайт, а Вася не может ваш код поревьюить, потому что какой-нибудь fisheye не успел обновить у себя код.

    Мы видим, что сторонние инструменты не стоят на месте и потихоньку становятся лучше. Периодически мы просмотриваем их с целью «выкинуть самописное — заменить готовым», но пока они не работают у нас, нам приходится как-то жить. Я бы даже предложил написать статью с обзором, но я боюсь, что у нас часто очень специфические требования и такой обзор будет достаточно бесполезным для других.
  • Patch me if you can: как мы отлаживаемся на production. Часть 1
    0
    Коммитятся в мастер ветку. Мы даже сначала их коммитим (а не после), а потом файлы раскладываем уже из мастера, чтобы не разрешать конфликты между разными версиями файлов на серверах (например, если было два патча на один файл).
  • Patch me if you can: как мы отлаживаемся на production. Часть 1
    +2

    Кажется, Вы забываете о том, что наша система в первую очередь нужна для маленьких изменений и hotfix'ов. У нас есть отдельный стандартный флоу с my-new-feature ветками, где есть (достаточно сложный, к слову) процесса auto-merge, который сам заберет вашу задачу, если вы в день релиза находитесь в офисе.


    Возвращаясь к патчам, здесь все равно придется открывать браузер: нужно отметить человека, который будет делать ревью, выбрать ветку (или вставить дифф в нашем случае) и отметить задачу, к которой это все относится.


    Ну и посмотрите на разницу в командах:


    git checkout -b {branch} && git commit -am {message} && git push

    vs


    git diff | pbcopy

    Наверное, оно выглядит интуитивно понятнее для Вас, но уверяю, что это просто дело привычки. На практике, оно не будет так уж здорово. Хотя я признаюсь, что мне хотелось бы найти что-то более интуитивное, простое и "гиковское" (в хорошем смысле этого слова) на замену простому копированию из консоли в браузер.


    P.s.


    Выводим дифф на экран (кстати, как это делается у вас?)

    Если вы про терминал, откуда обычно копируют изменения — git-diff, но мне показалось, что вопрос прозвучал более обширно. У нас есть собственная тулза для ревью изменений в коде, называется codeisok, мы выложили ее недавно в open-source. Этот инструмент получился путем сильной переделки старого gitphp (не нашего) и мы писали об этом, если вам интересно :)

  • Patch me if you can: как мы отлаживаемся на production. Часть 1
    0
    Лично для меня ситуация с отдельными ветками выглядит приблизительно как с pull request'ами, о которых спрашивали где-то выше. Если коротко, то они не сделают наш процесс удобнее. Скорее нам надо будет потратиться на поддержание отдельного типа веток для патчей.

    А в чем преимущества у использования git-format-patch перед отдельной формой на сайте?
  • Patch me if you can: как мы отлаживаемся на production. Часть 1
    +3
    Спасибо за ваш комментария, все сразу хочется обсудить! )

    У нас сложный процесс сборки и раскладки, это правда, но он не долгий. Я писал в статье про время, но оно не катастрофическое: в этой части истории сборка и раскладка занимали где-то минут 10-12 с инкрементальной сборкой статики. Оно покажется большим только в сравнении: mscp позволяет разложить изменения за минуту.

    Что касается микросервисов, тут ведь вопрос не только в раскладке изменений. Такой подход изменит весь процесс разработки и тестирования, а текущий вариант нас вполне устраивает. Менять же свою жизнь настолько сильно только ради деплоя — звучит как не самая хорошая идея. Более того, я думаю, что с отдельными сервисами есть свои сложности. У нас есть команда, которая пишет сервисы (хоть и не всегда микро) и с ними хватает проблем :)

    P.s. Но в отрыве от всего этого, идея с оркестрируемым решением, конечно, выглядит красивой.
  • Patch me if you can: как мы отлаживаемся на production. Часть 1
    +3

    Немного дополню ответ nizkopal: уже после того, как мы все починили, мы начинаем задавать вопросы "а что было?" и "как предотвратить?". В этом процессе мы обычно пишем штуку под названием постмортем, и об этом у нас рассказывал ableev в своем докладе.


    P.s. А еще, у меня сложилось впечатление (возможно, ложное), что Вы немного смешали обычные задачи и патчи. У нас есть стандартный флоу, я на нем не останавливался, но "обычные" задачи уезжают дважды в каждый рабочий день: утром и вечером (в пятницу — только утром). А вот hotfix'ы часто закрываются патчами.

  • Patch me if you can: как мы отлаживаемся на production. Часть 1
    +5
    Здраствуйте,

    Спасибо за комментарий )

    Почему сложно создать задачу? Честно говоря, тоже не понимаю. Мне до сих пор кажется, что это минута времени и достаточно просто, но разработчики сопротивляются. Если кто-то поделится, в чем реально сложность — с удовольствием почитаю.

    С pull request сложнее. Для меня основная причина их отсутствия — они не сделают процесс удобнее. Сейчас вы делаете изменения, копируете их и добавляете в интерфейс. Не нужно создавать специальных веток нигде. Ну и это какие-то дополнительные сложности для нас (РЕ) в поддержке. У нас будет новый вид веток, которые надо отличать от стандартных, для которых будет другой набор хуков выполняться, например (у нас их много, но мы не все гоняем для патчей — кому важно, как отформатирован код, если сайт лежит?).
  • Процесс релиза iOS-приложений в Badoo
    0
    Не очень понял вопрос про dSYM, можете как-то подробнее описать проблему?

    По поводу релизных веток: название для новой ветки мы берем из текущих настроек проекта. При этом у нас есть различные механизмы по изменению версии в настройках:

    * ручные, например, если мы решим выпустить версию {n+1}.0.0, надо будет самим поменять версию
    * полуавтоматические, например, для ресабмита приложения (когда бинарник отклоняют после ревью) у нас есть кнопка Bump Version (видно на скринах в конце статьи)
    * автоматическое, которое происходит после каждого релиза

    Как-то так :)
  • Как организовать Performance Review в IT-компании: опыт Badoo
    +5
    Новый функционал конечно же. Я думаю, что больше 50% задач в каждом релизе — это различные улучшения (не исправления багов). Не всегда это именно новый функционал от продуктовой команды, но, например, какие-то технические улучшения кода, чтобы работало быстрее, сбор дополнительной статистики, запуск новых А/Б тестов и т.п.
  • Git: много хуков полезных и разных
    +1
    Никак не решили, каждому новому пользователю все еще надо что-то делать самому. Выставлять настройки/делать симлинки и т.д. и т.п.

    Я так понимаю, кстати, что это — принципиальный момент, и ничего в этом плане не двигается из соображений безопасности.
  • Как мы уже 4 года выживаем в условиях двух релизов в день
    +2
    Касательно отката задач

    На самом деле, была целая статья про автоматизацию: https://habrahabr.ru/company/badoo/blog/169417/

    Если лень читать, вот ответ именно на ваш вопрос: мы используем git-rebase и с помощью него убираем коммиты, которые относятся к задаче, включая различные правки (патчи). Есть альтернативный вариант с git-revert, но он кажется нам менее удобным :)

    Я не очень понял про «откат мастера» в вопросе. На всякий случай уточню, что мы собираем билд в виде отдельной ветки, которая попадет в мастер только после всех проверок, в т.ч. на production окружении.