Comments 46
Увидев такое большое количество терминов и платформ, становится страшно программировать.
Да ладно, тут ничего страшного. Любой проект начинается с нескольких строк кода.
Дальше оно, конечно, разрастается и разрастается, но, как говорится, «step by step» — сначала одно прикрутили, потом другое, сначала с одним разобрались, потом с другим.
А через год смотришь, у тебя уже пяток серверов только под инфраструктуру.
Дальше оно, конечно, разрастается и разрастается, но, как говорится, «step by step» — сначала одно прикрутили, потом другое, сначала с одним разобрались, потом с другим.
А через год смотришь, у тебя уже пяток серверов только под инфраструктуру.
А можно взглянуть на ваш конфиг pylint? Особенно интересуют выключенные ошибки и регэкспы наименований.
.pylint:
Остальное почти по дефолту.
Предупреждений pylint очень много (прямо сейчас — 503 штуки), но многие из них можно игнорировать.
disable=I0011,W0142,W0223,W0403,W0232,E1101,E1103,R0201,C0103,R0801 good-names=i,j,k,e,ex,id,dt,tz,Run,_
Остальное почти по дефолту.
Предупреждений pylint очень много (прямо сейчас — 503 штуки), но многие из них можно игнорировать.
То есть прохождение pylint — не обязательное условие для коммита? Или вы как-то автоматизированно разделяете критичные и некритичные?
Всё верно, pylint не фейлит сборку. Мы стараемся уменьшать количество замечаний с каждым коммитом, но это не всегда удаётся. Возможно, когда-нибудь, когда мы сделаем все таски, мы почистим все замечания и сделаем так, чтобы билд фейлится при любых варнах, но пока это всего лишь мечты.
С другой стороны, любое замечание pep8 или pyflake сразу же фейлит билд.
С другой стороны, любое замечание pep8 или pyflake сразу же фейлит билд.
Чем вам не нравится virtualenvwrapper — или вы его и используете?
«например, у разработчиков не получится запушить в репозиторий календаря код Python» — круто. Как реализовано?
«например, у разработчиков не получится запушить в репозиторий календаря код Python» — круто. Как реализовано?
Для отрисовки графиков (хотя это и не про статистику) есть клевая штука: IPython: Notebook
virtualenvwrapper используем вовсю, вот, например, мой конфиг:
github.com/dreadatour/dotfiles/blob/master/.zshrc#L88
github.com/dreadatour/dotfiles/blob/master/.zshrc#L88
Не заметил вторую часть вопроса.
На сервере git-репозитория стоит проверка тех коммитов, которые пользователь пытается запушить. В случае, если python-файлы из этих коммитов содержат ошибки, сервер вернёт ошибку и команда git push не будет выполнена. Разработчику нужно будет исправить замечания и запушить код ещё раз.
flake8.readthedocs.org/en/latest/vcs.html — вот пример pre-commit хука, на сервере всё происходит примерно так же. Кстати, проверка перед коммитом тоже есть, но это не панацея, — локальные хуки нужно настраивать после каждого нового клона репозитория и легко забыть это сделать.
На сервере git-репозитория стоит проверка тех коммитов, которые пользователь пытается запушить. В случае, если python-файлы из этих коммитов содержат ошибки, сервер вернёт ошибку и команда git push не будет выполнена. Разработчику нужно будет исправить замечания и запушить код ещё раз.
flake8.readthedocs.org/en/latest/vcs.html — вот пример pre-commit хука, на сервере всё происходит примерно так же. Кстати, проверка перед коммитом тоже есть, но это не панацея, — локальные хуки нужно настраивать после каждого нового клона репозитория и легко забыть это сделать.
А какие инструменты вы используете для функционального тестирования?
UFO just landed and posted this here
Спасибо!
Большинство из моих коллег не страдают NIH-синдромом и предпочитают сосредоточиться на разработке целевого продукта.
И только в том случае, если существующие решения по каким-либо причинам нам не подходят, приходится писать своё. Яркие примеры: tarantool и fest.
Большинство из моих коллег не страдают NIH-синдромом и предпочитают сосредоточиться на разработке целевого продукта.
И только в том случае, если существующие решения по каким-либо причинам нам не подходят, приходится писать своё. Яркие примеры: tarantool и fest.
Отличная статья, спасибо. Пригодится всем: от админа, до руководителя проекта. Забрал себе в закладки некоторые ссылки на инструменты.
Спасибо!
Если нужно раскрыть какую-либо из затронутых тем получше, — скажите, я постараюсь написать поподробнее =)
Если нужно раскрыть какую-либо из затронутых тем получше, — скажите, я постараюсь написать поподробнее =)
Я в Вашем конфиге увидел Emacs — осветите, что в нем используете и как он Вам делает жизнь лучше (если делает). :)
Речь идёт о строке 15? github.com/dreadatour/dotfiles/blob/master/.zshrc#L15
Если да, то это просто использование стандартных сочетаний клавиш из emacs в zsh, например, Ctrl+A — переход в начало строки, Ctrl+E — в конец.
Сам emacs я так и не освоил, хотя честно пытался несколько раз. Достаточно неплохо знаю vim и вполне им доволен (хотя в повседневной жизни использую Sublime Text).
Если да, то это просто использование стандартных сочетаний клавиш из emacs в zsh, например, Ctrl+A — переход в начало строки, Ctrl+E — в конец.
Сам emacs я так и не освоил, хотя честно пытался несколько раз. Достаточно неплохо знаю vim и вполне им доволен (хотя в повседневной жизни использую Sublime Text).
А почему для мониторинга вы не используете продукты такого класса как Zabbix, Nagios и т.п.?
Я так понимаю есть какие-то объективные причины на это?
Я так понимаю есть какие-то объективные причины на это?
Это та тема, которую я не затронул.
Таких тем много, — я не хотел, чтобы статья получилась огромной.
В mail.ru есть огромная система мониторинга, и наш календарь подключен к ней. Есть дежурные администраторы, которые круглосуточно следят за здоровьем проектов и сигнализируют разработчикам и админам при любых неприятностях. Так что мониторинг есть (но это не Zabbix и не Nagios).
Графит и его графики нужны для того, чтобы разобраться в причинах проблем, которые своевременно выявил мониторинг. Как-то так.
Таких тем много, — я не хотел, чтобы статья получилась огромной.
В mail.ru есть огромная система мониторинга, и наш календарь подключен к ней. Есть дежурные администраторы, которые круглосуточно следят за здоровьем проектов и сигнализируют разработчикам и админам при любых неприятностях. Так что мониторинг есть (но это не Zabbix и не Nagios).
Графит и его графики нужны для того, чтобы разобраться в причинах проблем, которые своевременно выявил мониторинг. Как-то так.
Судя по блок-схеме, Jira не интегрирована ни с Jenkins, ни с GIT?
Jira интегрирована с git, все коммиты попадают в соответствующие таски.
Jenkins интегрирован с Phabricator — в случае падения сборки или lint'а будет оставлено сообщение в соответствующем реквесте на айдит кода.
Jira не интегрирована с Jenkins, но это очень хорошая идея и мы обязательно так сделаем =)
Jenkins интегрирован с Phabricator — в случае падения сборки или lint'а будет оставлено сообщение в соответствующем реквесте на айдит кода.
Jira не интегрирована с Jenkins, но это очень хорошая идея и мы обязательно так сделаем =)
Спасибо за статью! Очень интересно!
Вопросы:
Как вы используете git? Под каждую задачу ветки создаете?
Как у вас бэкэнд написан? На фреймворке или что-то свое?
Есть ли у вас какой-нибудь внутренний код-стайл? Вроде того как вы делаете ту или иную вещь, какие используете библиотеки для тех или иных задач.
Вопросы:
Как вы используете git? Под каждую задачу ветки создаете?
Как у вас бэкэнд написан? На фреймворке или что-то свое?
Есть ли у вас какой-нибудь внутренний код-стайл? Вроде того как вы делаете ту или иную вещь, какие используете библиотеки для тех или иных задач.
Спасибо!
Сейчас у нас несколько основных веток в гите (названия могут не совпадать с реальными по понятным причинам):
Каждый разработчик сам решает, нужно ли создавать отдельную ветку для задачи. Основной принцип такой: если в ветке будет несколько коммитов и выполнение таска займёт много времени, лучше создать новую ветку. Если это простой багфикс (несколько строк), то ветку можно не создавать и коммитить прямо в девелоперскую ветку.
После того, как работа над итерацией закончена, все девелоперские ветки (dev, webdev и несколько других) сливаются в prerelease и раскатываются на специальные сервер для проверки тестерами.
После того, как всё оттестировано код попадает в master и выезжает в бой.
Когда мы перейдём на Arcanist процесс разработки будет выглядеть иначе, но это уже совсем другая история…
Сейчас у нас несколько основных веток в гите (названия могут не совпадать с реальными по понятным причинам):
- master: только стабильный код, готовый к выкладке в бой в любой момент. именно из этой ветки собирается RPM для раскладки на живые серверы
- prerelease: сюда попадает код, который готов к раскладке в бой, но нуждается в проверке. он раскатывается на тестовый сервер и терзается нашими тестерами
- dev: основная ветка разработки backend'а. прямо в эту ветку идут простые багфиксы, (те, которые состоят из одного коммита) и от неё создаются ветки по задачам
- webdev: основная ветка разработки frontend'а. всё то же самое, что с веткой dev
Каждый разработчик сам решает, нужно ли создавать отдельную ветку для задачи. Основной принцип такой: если в ветке будет несколько коммитов и выполнение таска займёт много времени, лучше создать новую ветку. Если это простой багфикс (несколько строк), то ветку можно не создавать и коммитить прямо в девелоперскую ветку.
После того, как работа над итерацией закончена, все девелоперские ветки (dev, webdev и несколько других) сливаются в prerelease и раскатываются на специальные сервер для проверки тестерами.
После того, как всё оттестировано код попадает в master и выезжает в бой.
Когда мы перейдём на Arcanist процесс разработки будет выглядеть иначе, но это уже совсем другая история…
Для удобной работы с git есть хорошая надстройка gitflow
Отличный пост, грамотно все по полочкам, кое-что почерпнул и попробую в своих рабочих проектах, особенно заинтересовал подход к логгингу. Кстати хуки под git на проверку синтаксиса, это что свое или существующие инструменты/плагины в гите?
Спасибо! Будут вопросы — обращайтесь =)
Для хуков в гит у нас свои скрипты (там не только проверка синтаксиса выполняется, ещё куча других штук), но легко можно использовать существующие инструменты. Вот пример: flake8.readthedocs.org/en/latest/vcs.html.
Для хуков в гит у нас свои скрипты (там не только проверка синтаксиса выполняется, ещё куча других штук), но легко можно использовать существующие инструменты. Вот пример: flake8.readthedocs.org/en/latest/vcs.html.
Хочу проверить свои предположения. Посмотрел, что вашему сервису один год. Судя по количеству задач и коммитов у вас 3 разработчика и один живой тестировщик. Я сильно ошибся?
Спасибо за интересный пост.
а не смотрели в сторону buildout?
Про графит — я правильно понимаю, что графит вы используете для реал-тайм статистики? А используется что-то для бизнес-аналитики (для всяких специфических метрик, завязанных на бизнес-логике)? Или такие метрики тоже посылаются в графит?
И ещё один вопрос про логи. Вы писали что используете Sentry для ошибок. А всякие логи уровня info собираете? И если да, то используете syslog и его вариации или что-то другое?
мы используем virtualenv при разработке и развёртывании системы, поэтому для установки всех библиотек нужно всего лишь запустить команду
а не смотрели в сторону buildout?
Про графит — я правильно понимаю, что графит вы используете для реал-тайм статистики? А используется что-то для бизнес-аналитики (для всяких специфических метрик, завязанных на бизнес-логике)? Или такие метрики тоже посылаются в графит?
И ещё один вопрос про логи. Вы писали что используете Sentry для ошибок. А всякие логи уровня info собираете? И если да, то используете syslog и его вариации или что-то другое?
Buildout не пробовал, выглядит круто, спасибо за совет!
Про графит — всё верно. Для продуктовых метрик мы используем другие инструменты: top.mail.ru, liveinternet.ru и google.com/analytics. Плюс некоторые внутренние инструменты.
Логи уровня debug, info пока не собираем. В общем нам достаточно графиков, но логи тоже нужны и с этим нужно будет что-то делать.
Про графит — всё верно. Для продуктовых метрик мы используем другие инструменты: top.mail.ru, liveinternet.ru и google.com/analytics. Плюс некоторые внутренние инструменты.
Логи уровня debug, info пока не собираем. В общем нам достаточно графиков, но логи тоже нужны и с этим нужно будет что-то делать.
Если вы используете Jira и Confluence, почему тогда выбрали Jenkins, а не Bamboo (который интегрирован с атласиановскими продуктами)?
Вопрос по документации: каким образом поодерживаете её в актуальном состоянии и кто этим заведует? Может посоветуете какие-то лучше практики? Есть ли в вашем рабочем флоу задача на документацию?
Всё на совести коллег. Бывают, конечно, проблемы с устаревшей документацией, но адекватный разработчик просто поправит это, когда увидит.
У нас нет публично доступной документации. Если бы она была (например, наше API было бы открыто для всех), тогда за обновлением информации следили бы особо пристально. Поэтому никаких особых пунктов про документацию в workflow нет. В некоторых случаях ответственный человек (например, я, как тимлид) может просить добавить/поправить что-то в confluence.
Совет один: нанимать адекватных разработчиков. Самый лучший вариант изменения рабочего процесса — когда сами программисты чувствуют те или иные узкие места в работе и внедряют те или иные улучшения. Когда указание по применению новых инструментов спускают «сверху», это всегда встречает отторжение, по крайней мере в первое время.
У нас нет публично доступной документации. Если бы она была (например, наше API было бы открыто для всех), тогда за обновлением информации следили бы особо пристально. Поэтому никаких особых пунктов про документацию в workflow нет. В некоторых случаях ответственный человек (например, я, как тимлид) может просить добавить/поправить что-то в confluence.
Совет один: нанимать адекватных разработчиков. Самый лучший вариант изменения рабочего процесса — когда сами программисты чувствуют те или иные узкие места в работе и внедряют те или иные улучшения. Когда указание по применению новых инструментов спускают «сверху», это всегда встречает отторжение, по крайней мере в первое время.
Спасибо за емкий расклад проекта!
Хотелось уточнить момент насчет виртуальных серверов в тестовой сети (для почты к примеру) — вы используете vim, emacs,
а нельзя, например, дежать код локально, использовать IDE и аплоадить код при изменении в свое дев окружение по sftp? Как минимум для удобства индексации проекта?
Хотелось уточнить момент насчет виртуальных серверов в тестовой сети (для почты к примеру) — вы используете vim, emacs,
а нельзя, например, дежать код локально, использовать IDE и аплоадить код при изменении в свое дев окружение по sftp? Как минимум для удобства индексации проекта?
Большое спасибо за вашу статью, за то что делитесь опытом!
Отдельное спасибо, что указали сторонние системы и сервисы, которые вы используете в вашем проекте. Меня, например, заинтересовала Sentry, как раз подумываю внедрить что-то подобное в свой проект. Но я больше смотрел в сторону logstash, как более универсального инструмента для структурного логирования.
Отдельное спасибо, что указали сторонние системы и сервисы, которые вы используете в вашем проекте. Меня, например, заинтересовала Sentry, как раз подумываю внедрить что-то подобное в свой проект. Но я больше смотрел в сторону logstash, как более универсального инструмента для структурного логирования.
Logstash хорош, согласен, но это именно логи, — полноценно заменить Sentry с его подробнейшей информацией об исключениях и ошибках не получится.
Думаю, эти два инструмента идеально дополняют друг друга. Мы сейчас кое-где используем Sentry в тех случаях, когда хватило бы просто логов, и это, конечно же, не совсем правильно.
Думаю, эти два инструмента идеально дополняют друг друга. Мы сейчас кое-где используем Sentry в тех случаях, когда хватило бы просто логов, и это, конечно же, не совсем правильно.
Очень похоже на то, как у нас все устроено. Отличается несколько моментов:
* Мы не собираем пакеты (а, возможно, надо бы, подумаем)
* Мы используем hgflow (кстати, советую присмотрется, в вашем случае — к gitflow)
* В качестве CI используем Bamboo — проект тоже от Atlassian, поэтому прекрасно интегрируется с Jira и остальными
* Статистика у нас — свой велосипед
* Мы не собираем пакеты (а, возможно, надо бы, подумаем)
* Мы используем hgflow (кстати, советую присмотрется, в вашем случае — к gitflow)
* В качестве CI используем Bamboo — проект тоже от Atlassian, поэтому прекрасно интегрируется с Jira и остальными
* Статистика у нас — свой велосипед
— Пакеты удобны, позволяют в любой момент разложить любую версию проекта.
— Gitflow смотрели, пробовали, пока не прижилось. Возможно, в будущем ещё раз попробуем, спасибо за совет =)
— Уже не первый раз мне советуют Bamboo. Обязательно изучу этот продукт, хотя, если честно, не вижу сейчас смысла уходить с Jenkins, ведь всё работает отлично.
— Очень интересно. А можно поподробнее? В чём плюсы-минусы, чего не хватает в существующих решениях? На чём реализована, как?
— Gitflow смотрели, пробовали, пока не прижилось. Возможно, в будущем ещё раз попробуем, спасибо за совет =)
— Уже не первый раз мне советуют Bamboo. Обязательно изучу этот продукт, хотя, если честно, не вижу сейчас смысла уходить с Jenkins, ведь всё работает отлично.
— Очень интересно. А можно поподробнее? В чём плюсы-минусы, чего не хватает в существующих решениях? На чём реализована, как?
До бамбу мы пробовали TeamCity, если сравнивать с бамбу – последний выигрывает в удобстве использования.
Про велосипед – нам требуется серьезная аналитика для наших клиентсайд приложений. GA не подходит по некоторым причинам (как минимум – среда выполнения кода не позволяет подключать ga.js). Штуки вроде statsD/graphite (на первый взгляд, по крайней мере) подходят для анализа простых количественных метрик, но не дают возможности удобно работать с различными срезами/измерениями/фильтрами/аггрегациями. Тут бы подошел OLAP, но его одного тоже недостаточно, нужен комплексный подход, а времени как всегда не хватает) Так что пока мы перебиваемся собственным решением на python/mongo/aggregation framework, и думаем как сделать систему, которая будет удовлетворять наши потребности на 100%.
Про велосипед – нам требуется серьезная аналитика для наших клиентсайд приложений. GA не подходит по некоторым причинам (как минимум – среда выполнения кода не позволяет подключать ga.js). Штуки вроде statsD/graphite (на первый взгляд, по крайней мере) подходят для анализа простых количественных метрик, но не дают возможности удобно работать с различными срезами/измерениями/фильтрами/аггрегациями. Тут бы подошел OLAP, но его одного тоже недостаточно, нужен комплексный подход, а времени как всегда не хватает) Так что пока мы перебиваемся собственным решением на python/mongo/aggregation framework, и думаем как сделать систему, которая будет удовлетворять наши потребности на 100%.
Sign up to leave a comment.
Инфраструктура и жизненный цикл разработки веб-проекта