В моей практике самые удобные результаты профилирования и отчёты были у NYTProf (профайлер для Perl, авторы из New York Times).
В питоне всё не так удобно и красиво, конечно (к слову картинка профайлера из Matlab меня ужаснула =), но это не мешает профилировать программы и оптимизировать их.
Всегда хочется чего-то лучшего. Комментарий совершенно справедлив, и если этот вопрос действительно интересен, есть предложение пообщаться более плотно в личке.
— Пакеты удобны, позволяют в любой момент разложить любую версию проекта.
— Gitflow смотрели, пробовали, пока не прижилось. Возможно, в будущем ещё раз попробуем, спасибо за совет =)
— Уже не первый раз мне советуют Bamboo. Обязательно изучу этот продукт, хотя, если честно, не вижу сейчас смысла уходить с Jenkins, ведь всё работает отлично.
— Очень интересно. А можно поподробнее? В чём плюсы-минусы, чего не хватает в существующих решениях? На чём реализована, как?
Logstash хорош, согласен, но это именно логи, — полноценно заменить Sentry с его подробнейшей информацией об исключениях и ошибках не получится.
Думаю, эти два инструмента идеально дополняют друг друга. Мы сейчас кое-где используем Sentry в тех случаях, когда хватило бы просто логов, и это, конечно же, не совсем правильно.
Ценное замечание. Можно держать код локально, и многие наши разработчики так делают: запускают скрипт, который при изменении файлов в директории проекта просто запускает rsync для синхронизации локальной папки с удалённой директорией на виртуальной машине.
Всё на совести коллег. Бывают, конечно, проблемы с устаревшей документацией, но адекватный разработчик просто поправит это, когда увидит.
У нас нет публично доступной документации. Если бы она была (например, наше API было бы открыто для всех), тогда за обновлением информации следили бы особо пристально. Поэтому никаких особых пунктов про документацию в workflow нет. В некоторых случаях ответственный человек (например, я, как тимлид) может просить добавить/поправить что-то в confluence.
Совет один: нанимать адекватных разработчиков. Самый лучший вариант изменения рабочего процесса — когда сами программисты чувствуют те или иные узкие места в работе и внедряют те или иные улучшения. Когда указание по применению новых инструментов спускают «сверху», это всегда встречает отторжение, по крайней мере в первое время.
Не заметил вторую часть вопроса.
На сервере git-репозитория стоит проверка тех коммитов, которые пользователь пытается запушить. В случае, если python-файлы из этих коммитов содержат ошибки, сервер вернёт ошибку и команда git push не будет выполнена. Разработчику нужно будет исправить замечания и запушить код ещё раз.
flake8.readthedocs.org/en/latest/vcs.html — вот пример pre-commit хука, на сервере всё происходит примерно так же. Кстати, проверка перед коммитом тоже есть, но это не панацея, — локальные хуки нужно настраивать после каждого нового клона репозитория и легко забыть это сделать.
Речь идёт о строке 15? github.com/dreadatour/dotfiles/blob/master/.zshrc#L15
Если да, то это просто использование стандартных сочетаний клавиш из emacs в zsh, например, Ctrl+A — переход в начало строки, Ctrl+E — в конец.
Сам emacs я так и не освоил, хотя честно пытался несколько раз. Достаточно неплохо знаю vim и вполне им доволен (хотя в повседневной жизни использую Sublime Text).
Для хуков в гит у нас свои скрипты (там не только проверка синтаксиса выполняется, ещё куча других штук), но легко можно использовать существующие инструменты. Вот пример: flake8.readthedocs.org/en/latest/vcs.html.
Сейчас у нас несколько основных веток в гите (названия могут не совпадать с реальными по понятным причинам):
master: только стабильный код, готовый к выкладке в бой в любой момент. именно из этой ветки собирается RPM для раскладки на живые серверы
prerelease: сюда попадает код, который готов к раскладке в бой, но нуждается в проверке. он раскатывается на тестовый сервер и терзается нашими тестерами
dev: основная ветка разработки backend'а. прямо в эту ветку идут простые багфиксы, (те, которые состоят из одного коммита) и от неё создаются ветки по задачам
webdev: основная ветка разработки frontend'а. всё то же самое, что с веткой dev
Каждый разработчик сам решает, нужно ли создавать отдельную ветку для задачи. Основной принцип такой: если в ветке будет несколько коммитов и выполнение таска займёт много времени, лучше создать новую ветку. Если это простой багфикс (несколько строк), то ветку можно не создавать и коммитить прямо в девелоперскую ветку.
После того, как работа над итерацией закончена, все девелоперские ветки (dev, webdev и несколько других) сливаются в prerelease и раскатываются на специальные сервер для проверки тестерами.
После того, как всё оттестировано код попадает в master и выезжает в бой.
Когда мы перейдём на Arcanist процесс разработки будет выглядеть иначе, но это уже совсем другая история…
Всё верно, pylint не фейлит сборку. Мы стараемся уменьшать количество замечаний с каждым коммитом, но это не всегда удаётся. Возможно, когда-нибудь, когда мы сделаем все таски, мы почистим все замечания и сделаем так, чтобы билд фейлится при любых варнах, но пока это всего лишь мечты.
С другой стороны, любое замечание pep8 или pyflake сразу же фейлит билд.
Jira интегрирована с git, все коммиты попадают в соответствующие таски.
Jenkins интегрирован с Phabricator — в случае падения сборки или lint'а будет оставлено сообщение в соответствующем реквесте на айдит кода.
Jira не интегрирована с Jenkins, но это очень хорошая идея и мы обязательно так сделаем =)
В питоне всё не так удобно и красиво, конечно (к слову картинка профайлера из Matlab меня ужаснула =), но это не мешает профилировать программы и оптимизировать их.
Всегда хочется чего-то лучшего. Комментарий совершенно справедлив, и если этот вопрос действительно интересен, есть предложение пообщаться более плотно в личке.
Если совсем уж не терпится, то список инструментов можно посмотреть в презентации по самой первой ссылке в статье. Например, вот событийные профайлеры: speakerdeck.com/moscowdjango/profilirovaniie-i-otladka-django?slide=38
Было бы здорово увидеть статью, когда придумаете своё решение для статистики.
Мне, например, будет очень интересно почитать об этом =)
— Gitflow смотрели, пробовали, пока не прижилось. Возможно, в будущем ещё раз попробуем, спасибо за совет =)
— Уже не первый раз мне советуют Bamboo. Обязательно изучу этот продукт, хотя, если честно, не вижу сейчас смысла уходить с Jenkins, ведь всё работает отлично.
— Очень интересно. А можно поподробнее? В чём плюсы-минусы, чего не хватает в существующих решениях? На чём реализована, как?
Думаю, эти два инструмента идеально дополняют друг друга. Мы сейчас кое-где используем Sentry в тех случаях, когда хватило бы просто логов, и это, конечно же, не совсем правильно.
Ценное замечание. Можно держать код локально, и многие наши разработчики так делают: запускают скрипт, который при изменении файлов в директории проекта просто запускает rsync для синхронизации локальной папки с удалённой директорией на виртуальной машине.
У нас нет публично доступной документации. Если бы она была (например, наше API было бы открыто для всех), тогда за обновлением информации следили бы особо пристально. Поэтому никаких особых пунктов про документацию в workflow нет. В некоторых случаях ответственный человек (например, я, как тимлид) может просить добавить/поправить что-то в confluence.
Совет один: нанимать адекватных разработчиков. Самый лучший вариант изменения рабочего процесса — когда сами программисты чувствуют те или иные узкие места в работе и внедряют те или иные улучшения. Когда указание по применению новых инструментов спускают «сверху», это всегда встречает отторжение, по крайней мере в первое время.
Возможно, со временем перейдём на Bamboo, а пока работает главное правило: «работает — не трожь!».
Про графит — всё верно. Для продуктовых метрик мы используем другие инструменты: top.mail.ru, liveinternet.ru и google.com/analytics. Плюс некоторые внутренние инструменты.
Логи уровня debug, info пока не собираем. В общем нам достаточно графиков, но логи тоже нужны и с этим нужно будет что-то делать.
На сервере git-репозитория стоит проверка тех коммитов, которые пользователь пытается запушить. В случае, если python-файлы из этих коммитов содержат ошибки, сервер вернёт ошибку и команда git push не будет выполнена. Разработчику нужно будет исправить замечания и запушить код ещё раз.
flake8.readthedocs.org/en/latest/vcs.html — вот пример pre-commit хука, на сервере всё происходит примерно так же. Кстати, проверка перед коммитом тоже есть, но это не панацея, — локальные хуки нужно настраивать после каждого нового клона репозитория и легко забыть это сделать.
Если да, то это просто использование стандартных сочетаний клавиш из emacs в zsh, например, Ctrl+A — переход в начало строки, Ctrl+E — в конец.
Сам emacs я так и не освоил, хотя честно пытался несколько раз. Достаточно неплохо знаю vim и вполне им доволен (хотя в повседневной жизни использую Sublime Text).
Для хуков в гит у нас свои скрипты (там не только проверка синтаксиса выполняется, ещё куча других штук), но легко можно использовать существующие инструменты. Вот пример: flake8.readthedocs.org/en/latest/vcs.html.
Сейчас у нас несколько основных веток в гите (названия могут не совпадать с реальными по понятным причинам):
Каждый разработчик сам решает, нужно ли создавать отдельную ветку для задачи. Основной принцип такой: если в ветке будет несколько коммитов и выполнение таска займёт много времени, лучше создать новую ветку. Если это простой багфикс (несколько строк), то ветку можно не создавать и коммитить прямо в девелоперскую ветку.
После того, как работа над итерацией закончена, все девелоперские ветки (dev, webdev и несколько других) сливаются в prerelease и раскатываются на специальные сервер для проверки тестерами.
После того, как всё оттестировано код попадает в master и выезжает в бой.
Когда мы перейдём на Arcanist процесс разработки будет выглядеть иначе, но это уже совсем другая история…
Если нужно раскрыть какую-либо из затронутых тем получше, — скажите, я постараюсь написать поподробнее =)
С другой стороны, любое замечание pep8 или pyflake сразу же фейлит билд.
Jenkins интегрирован с Phabricator — в случае падения сборки или lint'а будет оставлено сообщение в соответствующем реквесте на айдит кода.
Jira не интегрирована с Jenkins, но это очень хорошая идея и мы обязательно так сделаем =)