company_banner

Инфраструктура и жизненный цикл разработки веб-проекта

    Когда проект маленький, особых проблем с ним не возникает. Список задач можно вести в текстовом файле (TODO), систему контроля версий, по большому счёту, можно и не использовать, для раскладки файлов на живой сервер их можно просто скопировать (cp/scp/rsync) в нужную директорию, а ошибки всегда можно посмотреть в лог-файле. Глупо было бы, например, для простенького сервиса с двумя скриптами и тремя посетителями в день поднимать полноценную систему управления конфигурациями серверов.

    С ростом проекта требования растут. Становится неудобно держать в TODO-файле несколько десятков задач и багов: хочется приоритетов, комментариев, ссылок. Появляется необходимость в системе контроля версий, специальных скриптах/систем для раскладки кода на сервер, системе мониторинга. Ситуация усугубляется, когда над проектом работает несколько человек, а уж когда проект разрастается до нескольких серверов, появляется полноценная инфраструктура («комплекс взаимосвязанных обслуживающих структур или объектов, составляющих и/или обеспечивающих основу функционирования системы», Wikipedia).

    На примере нашего сервиса "Календарь Mail.ru" я хочу рассказать о типичной инфраструктуре и жизненном цикле разработки среднего по размерам веб-проекта в крупной интернет-компании.


    Любая работа начинается с постановки задачи, будь то запланированная фича или сообщение об ошибке.

    Управление проектами и задачами


    В качестве системы «Issue & project tracking» мы, в Mail.ru, используем Atlassian Jira, которая является стандартом де-факто среди крупных организаций. Вот далеко не полный список компаний, использующих Jira: ru.wikipedia.org/wiki/Atlassian_JIRA. По функционалу, гибкости, расширяемости и удобству использования этой системе нет равных, и альтернативы я не вижу, хотя по имеющейся у меня информации некоторые крупнейшие IT-компании с тысячами сотрудников успешно (по их заверениям) используют Bugzilla в качестве багтрекера.

    Для небольших команд и проектов целесообразнее использовать менее навороченные и более бесплатные аналоги вроде той же Bugzilla, Phabricator или Redmine. Как вариант, в случае использования хостинга проектов (GitHub, BitBucket и другие) можно использовать встроенные в них системы отслеживания ошибок.
    На данный момент проект «Календарь» в Jira содержит 1816 задач, из которых 1386 успешно закрыты. Около 500 из них были багами =)

    После того, как задача была поставлена менеджером, специалистом по тестированию или службой поддержки пользователей, разработчик приступает к работе над ней. Весь код проекта находится в репозитории.

    Система контроля версий


    На сегодняшний день самыми распростанёнными системами контроля версий являются Git и Mercurial. Обе имеют, по большому счёту, схожий функционал (распределённые системы), хоть и различаются в деталях. Практически все проекты Mail.ru перешли на Git (кто с SVN, кто вообще с CVS), и Календарь — не исключение.

    В нашей компании есть несколько больших и мощных серверов, на которых установлен gitosis для хостинга git-репозиториев. Разные репозитории имеют разные настройки, например, у разработчиков не получится запушить в репозиторий календаря код Python, который не соответствует стандартам PEP8 (за этим следит специальный хук на сервере).

    Весь код Календаря (frontend и backend) хранится в одном репозитории. Для небольшого и среднего проекта это позволяет быстро разворачивать весь проект целиком и легко отслеживать любые изменения в коде. Для больших и очень больших проектов (таких как Почта Mail.ru) более удобным представляется хранение клиентского и серверного кода в отдельных репозиториях (а то и нескольких), хотя, конечно, любой подход требует осмысленного и аргументированного решения.
    На сегодняшний день у нас в репозитории Календаря 7175 коммитов, а за всё время было создано около 300 веток. Размер всего проекта 60 Мб.

    Для того, чтобы разрабатывать проект, требуется сначала его запустить, для этого нужно иметь соответствующее ПО и библиотеки.

    Окружение для разработки


    Говорят, что каждое правило в технике безопасности написано кровью. В IT-компаниях до такого, конечно, не доходит, но жёсткие правила, тем не менее, есть. Например, в Mail.ru только системные администраторы имеют доступ на «боевые» серверы и к данным реальных пользователей. Разработчикам доступны лишь тестовые машины с тестовыми пользователями, которая никак не связана с «живой», и вся разработка ведётся только в тестовой сети. Такое разделение обязанностей избавляет самых «умных» программистов от соблазна что-нибудь «быстренько поправить на живом» и заставляет более вдумчиво и качественно писать код.

    Есть системы, которые очень трудно, а иногда и невозможно запустить на одной машине, например, Почта Mail.Ru: для полноценной работы ей требуется огромное количество библиотек, демонов, скриптов и сервисов. Такие проекты запускаются на нескольких (десятках) виртуальных серверов в тестовой сети, и разработчики работают с кодом, запущенным на этих машинах (vim, emacs, diff, вот это всё).

    Нам в Календаре повезло: весь проект достаточно легко запускается на локальной машине разработчика и никаких проблем с разработкой нет. Для работы можно без ухищрений использовать любимые редакторы, IDE и отладчики, каждый программист работает со своим кодом и никак не влияет на работу других. Конечно, у нас тоже есть виртуальные серверы в девелоперской сети, но они используются, в основном, для тестирования. Ещё больше облегчает работу тот факт, что все в Календаре предпочитают использовать MacBook в своей работе, поэтому среда разработки практически не различается у членов команды.

    Серверная часть календаря написана на Python, и, конечно же, мы используем virtualenv при разработке и развёртывании системы, поэтому для установки всех библиотек нужно всего лишь запустить команду
        pip install -r requirements/development.txt

    из склонированного репозитория. Клиентская (фронтенд) часть использует npm и все зависимости ставятся так же легко и непринуждённо.
    Сейчас в календаре используется 33 сторонние библиотеки Python.

    Всё необходимое ПО на маке ставится из brew, и для первоначальной установки проекта на компьютер разработчика достаточно запустить
        brew install ...

    со списком зависимостей. Конечно, одной команды недостаточно и потребуется дальнейшая настройка, например, инициализация пользователя и БД в PostgreSQL. В установке отдельных программ есть некоторые особенности (например, мы используем патченный nginx со своими модулями), но это не вызывает никаких проблем, потому что всё описано в системе документации (wiki).

    Документация по проекту


    Знание — сила. Знаниями стоит делиться со своими коллегами, их нужно записывать, чтобы не забыть самому. Идеальным местом для хранения информации являются wiki-системы, и в Mail.ru мы испольуем Atlassian Confluence в качестве таковой. Особых преимуществ перед другими wiki-системами у Confluence я не вижу (их функционал, по сути, схож), но так сложилось, что продукция Atlassian прижилась в нашей компании и пользуется популярностью. Хотя одно достоинство всё-таки есть: продукты одной компании легко интегрировать друг с другом, а в любой крупной компании все внутренние сервисы так или иначе связаны друг с другом.

    Мы стараемся документировать всё, что касается процесса разработки и эксплуатации: как установить тот или иной софт, какая конфигурация требуется, с какими проблемами можно столкнуться, на каких серверах какие сервисы запущены и как они общаются друг с другом.
    В проекте Календарь в Confluence 122 страницы документации.

    Любому продукту нужен контроль качества и наш Календарь не исключение.

    Code review


    Каждый разработчик сталкивается с ошибками в коде. Первый шаг в борьбе за качество — code review, это позволяет своевременно заметить любые огрехи в программе. Ещё одно достоинство аудита кода заключается в знакомстве с каждым коммитом как минимум двух программистов: того, кто написал код и того, кто его ревьюил (соответственно, ответственность так же делится пополам).

    У Atlassian для code review есть шикарный инструмент Сrucible, но так исторически сложилось, что мы в Календаре используем Phabricator: open-source разработку от Facebook. У фабрикатора много возможностей, но мы используем лишь часть из них, а именно аудит, комментирование кода и просмотр репозитория онлайн.
    В среднем, при каждом аудите коммита появляется три-четыре замечания.

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

    Синтаксический контроль и тестирование


    Красивый код — хороший код. Следование правилам code-style всеми членами команды позволяет с первого взгляда разобраться в любом месте программы, а так же позволяет избежать подавляющего большинства глупых ошибок. Каждый пуш в репозиторий календаря проверяется с помощью PEP8, pyflake и pylint.
    В календаре нет ни одного исключения из правил pep8 и pyflake.

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

    Для запуска различных задач мы используем open-source систему Jenkins CI (Continuous integration), в которой имеется три задания для календаря:
    1. для тестовых веток: синтаксический контроль (lint) кода, запуск всех тестов, подготовка отчёта code coverage
    2. для ветки prerelease: синтаксический контроль (lint) кода, запуск всех тестов, сборка тестового пакета (RPM) проекта и раскладка его на наш пререлизный (тестовый) сервер
    3. для ветки master: запуск тестов и сборка пакета (RPM) проекта

    Все задачи запускаются при пуше соответствующей ветки по хуку в git-репозитории.
    Сборка проекта длится, в среднем, около пяти минут.

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

    На выходе получается один (или несколько, в зависимости от проекта) RPM-файл, который содержит в себе весь проект полностью, с virtualenv, всеми необходимыми зависимостями (библиотеками) и файлами (статикой).

    Релиз собран, оттестирован, проверен и готов к выкладке на боевые машины, доступ к которым есть только у системных администраторов.

    Раскладка проекта в бой


    Админы — люди умные и ленивые. Если часто приходится делать рутинные операции, то почему бы их не автоматизировать?

    В Mail.ru многие тысячи серверов, у каждого своя роль и свои настройки. Для управления конфигурациями серверов мы используем Puppet. Настройки каждой группы серверов описываются в простых файлах, которые лежат в системе контроля версий. Таким образом, всегда есть история изменений файлов конфигурации с возможностью откатиться в любое из предыдущих состояний. Доступ к репозиториям и к паппету в целом есть только у системных администраторов.

    Процесс выкладки новой итерации на живые серверы выглядит, например, так: админы, если нужно, правят файлы конфигурации проекта, прописывают необходимые версии RPM-пакетов и пушат изменения в репозиторий. Дальше всем занимается Puppet: все файлы конфигураций на всех серверах будут обновлены, пакеты установлены и нужные сервисы перезапущены.
    Раскладка проекта занимает около одной минуты.

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

    Логгирование ошибок


    В первую очередь нас интересуют, так называемые, «пятисотки», то есть критические ошибки на сервере. Если они есть (а они бывают, от этого никуда не деться), значит что-то пошло не так и нужно в срочном порядке готовить багфиксы. Как поймать такие ошибки? Можно, конечно, писать всё в лог, и тогда простым «грепом» (поиском по файлу лога) мы всегда будем в курсе о количестве и типе ошибок, но есть вариант получше.

    Система логгирования в Календаре настроена таким образом, чтобы отправлять все ошибки, исключения и просто варнинги в специальну систему под названием Sentry. В ней мы видим не только статистику по ошибкам (когда, какие ошибки и сколько раз возникали), но и подробнейшую информацию об этих ошибках: полный traceback (порядок вызова функций) со значением всех переменных в контексте каждой функции. Так же имеется информация о пользователе (email, ОС, браузер) и запросе (url, заголовки, GET и POST параметры). Все браузерные ошибки так же попадают в Sentry, правда, информация не столь подробна (JavaScript, ничего не поделаешь). Всё это позволяет легко локализовать проблемы и в кратчайшие сроки исправлять ошибки.

    В основном, мы пишем в Sentry различные предупреждения. Например, в процессе рефакторинга, прежде чем отказаться от какой-нибудь функции мы всегда добавляем warning в неё, и только при отсутствии сообщений в Sentry, в следующую итерацию, эта функция будет окончательно удалена из кода. Бывают, конечно, и ошибки, бывает и много ошибок («факапы»).
    В Sentry Календаря попадает, в среднем, около 100 сообщений в час. Sentry выдерживает тысячи ошибок в минуту (проверено на практике =).

    Логгирование — хорошо, но этого недостаточно, проекту жизненно необходима статистика.

    Статистика и графики


    Статистику любят все. Менеджеры любуются ею, радуясь увеличению количества хитов и пользователей, разработчики получают информацию о «здоровье» проекта. Мы используем Graphite в качестве системы для сбора и хранения метрик, а так же StatsD — сервер, который обрабатывает и аггрегирует входящие метрики, передавая их на хранение во всё тот же графит.

    Для чего нужны графики? Как я уже говорил, по графикам всегда можно судить о состоянии проекта: внезапно увеличилось количество редиректов, выросло в два раза среднее время запроса в базу или увеличилось количество операций ввода-вывода на одном из серверов. Всё это позволяет обнаружить проблему, а наличие истории (графики хранятся месяцами и годами) облегчают анализ внезапных неприятностей с проектом.

    Графики помогают при рефакторинге. Достаточно, например, добавить декораторы статистики к функциям, вызвавшим вопросы при профилировании и получить достоверную информацию о поведении кода под нагрузкой. После выкладывания итерации с правками можно оценить их эффективность, так, уменьшение среднего времени работы функции в десятки раз (с сотен до десятков и даже единиц милисекунд) или количества запросов в базу с сотен (тысяч) до единиц получше любых слов доказывает результативность рефакторинга.

    Графики показателей сервера (мы используем Diamond для этого) позволяют своевременно оценить нагрузку и заблаговременно заказать дополнительные машины или же озаботиться производительностью программ.
    В графит Календаря каждую минуту пишется около 25 тысяч различных метрик.

    Любой проект пишется не для логов и не для графиков: он пишется для людей, для наших любимых пользователей. И пользователи иногда бывают недовольны проектом.

    Общение с пользователями


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

    Вспоминается курьёзный случай, когда один из пользователей написал нам письмо с просьбой добавить нужный ему функционал в Календарь (если я не ошибаюсь, речь шла об уведомлениях по СМС), а мы как раз закончили эту задачу и занимались раскладкой её на живой сервер. Через пятнадцать минут после обращения пользователь получил ответ, что, мол, мы всё сделали как вы просили. Удивлению его не было предела.
    Мы получаем около десяти сообщений в день. Половина из них — слова благодарности и положительные отзывы.


    Вместо послесловия


    Процесс разработки Календаря с нуля продолжается всего полтора года, а релиз календаря состоялся чуть меньше года назад. Проект молодой, и мы, его разработчики, постоянно совершенствуем его инфраструктуру. Расскажу немного о наших планах на будущее.

    Хочется попробовать использовать Vagrant при разработке, это позволит ещё быстрее и проще разворачивать девелоперское окружение. Очень хочется попробовать Selenium для автоматического тестирования проекта (веб-версии и мобильных клиентов). Для более качественного тестирования нового функционала не хватает возможности включать оный по критериям, например, только на сотрудников компании или на определённый процент пользователей, хотим попробовать open-source проект Gargoyle для этого. В ближайшее время, по примеру других Python-проектов в нашей компании, наша команда собирается внедрить Arcanist: надстройку над git для работы с Phabricator из командной строки в репозитории проекта. Это позволит ещё больше упростить процесс code-review и облегчить разработку.

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

    Владимир Рудных,
    Технический руководитель Календаря Mail.Ru.
    Mail.ru Group
    1,032.30
    Строим Интернет
    Share post

    Comments 46

      +3
      Увидев такое большое количество терминов и платформ, становится страшно программировать.
        +4
        Да ладно, тут ничего страшного. Любой проект начинается с нескольких строк кода.
        Дальше оно, конечно, разрастается и разрастается, но, как говорится, «step by step» — сначала одно прикрутили, потом другое, сначала с одним разобрались, потом с другим.
        А через год смотришь, у тебя уже пяток серверов только под инфраструктуру.
        +1
        А можно взглянуть на ваш конфиг pylint? Особенно интересуют выключенные ошибки и регэкспы наименований.
          +2
          .pylint:
            disable=I0011,W0142,W0223,W0403,W0232,E1101,E1103,R0201,C0103,R0801
            good-names=i,j,k,e,ex,id,dt,tz,Run,_

          Остальное почти по дефолту.
          Предупреждений pylint очень много (прямо сейчас — 503 штуки), но многие из них можно игнорировать.
            +1
            То есть прохождение pylint — не обязательное условие для коммита? Или вы как-то автоматизированно разделяете критичные и некритичные?
              0
              Всё верно, pylint не фейлит сборку. Мы стараемся уменьшать количество замечаний с каждым коммитом, но это не всегда удаётся. Возможно, когда-нибудь, когда мы сделаем все таски, мы почистим все замечания и сделаем так, чтобы билд фейлится при любых варнах, но пока это всего лишь мечты.

              С другой стороны, любое замечание pep8 или pyflake сразу же фейлит билд.
          +1
          Чем вам не нравится virtualenvwrapper — или вы его и используете?

          «например, у разработчиков не получится запушить в репозиторий календаря код Python» — круто. Как реализовано?
            +1
            Для отрисовки графиков (хотя это и не про статистику) есть клевая штука: IPython: Notebook
              +3
              Да, ipython вообще один из лучших проектов на питоне. Куча возможностей и применений, ребята молодцы.
              +2
              virtualenvwrapper используем вовсю, вот, например, мой конфиг:
              github.com/dreadatour/dotfiles/blob/master/.zshrc#L88
                +1
                Не заметил вторую часть вопроса.
                На сервере git-репозитория стоит проверка тех коммитов, которые пользователь пытается запушить. В случае, если python-файлы из этих коммитов содержат ошибки, сервер вернёт ошибку и команда git push не будет выполнена. Разработчику нужно будет исправить замечания и запушить код ещё раз.

                flake8.readthedocs.org/en/latest/vcs.html — вот пример pre-commit хука, на сервере всё происходит примерно так же. Кстати, проверка перед коммитом тоже есть, но это не панацея, — локальные хуки нужно настраивать после каждого нового клона репозитория и легко забыть это сделать.
                +3
                А какие инструменты вы используете для функционального тестирования?
                  +1
                  Каких-то специальных инструментов сейчас не используем.
                  У нас в тестах сильно расширен стандартный джанговский django.test.client, и этого пока достаточно.

                  Буду рад услышать рекомендации и success-story использования различных инструментов для этих целей.
                  +7
                  Интересно было почитать. Сразу становится ясно, что «не боги горшки обжигают», и мейлру вполне недалек от народа, что радует, и можно даже поделиться в новой статье чем-то полезным для такой большой компании:)
                    +1
                    Спасибо!

                    Большинство из моих коллег не страдают NIH-синдромом и предпочитают сосредоточиться на разработке целевого продукта.
                    И только в том случае, если существующие решения по каким-либо причинам нам не подходят, приходится писать своё. Яркие примеры: tarantool и fest.
                    +7
                    Отличная статья, спасибо. Пригодится всем: от админа, до руководителя проекта. Забрал себе в закладки некоторые ссылки на инструменты.
                      0
                      Спасибо!
                      Если нужно раскрыть какую-либо из затронутых тем получше, — скажите, я постараюсь написать поподробнее =)
                        +1
                        Я в Вашем конфиге увидел Emacs — осветите, что в нем используете и как он Вам делает жизнь лучше (если делает). :)
                          +1
                          Речь идёт о строке 15? github.com/dreadatour/dotfiles/blob/master/.zshrc#L15
                          Если да, то это просто использование стандартных сочетаний клавиш из emacs в zsh, например, Ctrl+A — переход в начало строки, Ctrl+E — в конец.

                          Сам emacs я так и не освоил, хотя честно пытался несколько раз. Достаточно неплохо знаю vim и вполне им доволен (хотя в повседневной жизни использую Sublime Text).
                      +2
                      А почему для мониторинга вы не используете продукты такого класса как Zabbix, Nagios и т.п.?
                      Я так понимаю есть какие-то объективные причины на это?
                        0
                        Это та тема, которую я не затронул.
                        Таких тем много, — я не хотел, чтобы статья получилась огромной.

                        В mail.ru есть огромная система мониторинга, и наш календарь подключен к ней. Есть дежурные администраторы, которые круглосуточно следят за здоровьем проектов и сигнализируют разработчикам и админам при любых неприятностях. Так что мониторинг есть (но это не Zabbix и не Nagios).

                        Графит и его графики нужны для того, чтобы разобраться в причинах проблем, которые своевременно выявил мониторинг. Как-то так.
                        +1
                        Судя по блок-схеме, Jira не интегрирована ни с Jenkins, ни с GIT?
                          0
                          Jira интегрирована с git, все коммиты попадают в соответствующие таски.
                          Jenkins интегрирован с Phabricator — в случае падения сборки или lint'а будет оставлено сообщение в соответствующем реквесте на айдит кода.

                          Jira не интегрирована с Jenkins, но это очень хорошая идея и мы обязательно так сделаем =)
                          +4
                          Спасибо за статью! Очень интересно!
                          Вопросы:
                          Как вы используете git? Под каждую задачу ветки создаете?
                          Как у вас бэкэнд написан? На фреймворке или что-то свое?
                          Есть ли у вас какой-нибудь внутренний код-стайл? Вроде того как вы делаете ту или иную вещь, какие используете библиотеки для тех или иных задач.
                            +2
                            Спасибо!

                            Сейчас у нас несколько основных веток в гите (названия могут не совпадать с реальными по понятным причинам):

                            • master: только стабильный код, готовый к выкладке в бой в любой момент. именно из этой ветки собирается RPM для раскладки на живые серверы
                            • prerelease: сюда попадает код, который готов к раскладке в бой, но нуждается в проверке. он раскатывается на тестовый сервер и терзается нашими тестерами
                            • dev: основная ветка разработки backend'а. прямо в эту ветку идут простые багфиксы, (те, которые состоят из одного коммита) и от неё создаются ветки по задачам
                            • webdev: основная ветка разработки frontend'а. всё то же самое, что с веткой dev


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

                            После того, как работа над итерацией закончена, все девелоперские ветки (dev, webdev и несколько других) сливаются в prerelease и раскатываются на специальные сервер для проверки тестерами.

                            После того, как всё оттестировано код попадает в master и выезжает в бой.

                            Когда мы перейдём на Arcanist процесс разработки будет выглядеть иначе, но это уже совсем другая история…
                              +3
                              Для удобной работы с git есть хорошая надстройка gitflow
                                0
                                Gitflow хорош, согласен!
                              +6
                              Отличный пост, грамотно все по полочкам, кое-что почерпнул и попробую в своих рабочих проектах, особенно заинтересовал подход к логгингу. Кстати хуки под git на проверку синтаксиса, это что свое или существующие инструменты/плагины в гите?
                                +1
                                Спасибо! Будут вопросы — обращайтесь =)

                                Для хуков в гит у нас свои скрипты (там не только проверка синтаксиса выполняется, ещё куча других штук), но легко можно использовать существующие инструменты. Вот пример: flake8.readthedocs.org/en/latest/vcs.html.
                                +2
                                Хочу проверить свои предположения. Посмотрел, что вашему сервису один год. Судя по количеству задач и коммитов у вас 3 разработчика и один живой тестировщик. Я сильно ошибся?

                                  +1
                                  Практически в точку! У нас четыре разработчика и (с совсем недавнего времени) два специалиста по тестированию.
                                  +2
                                  Спасибо за интересный пост.
                                  мы используем virtualenv при разработке и развёртывании системы, поэтому для установки всех библиотек нужно всего лишь запустить команду

                                  а не смотрели в сторону buildout?

                                  Про графит — я правильно понимаю, что графит вы используете для реал-тайм статистики? А используется что-то для бизнес-аналитики (для всяких специфических метрик, завязанных на бизнес-логике)? Или такие метрики тоже посылаются в графит?
                                  И ещё один вопрос про логи. Вы писали что используете Sentry для ошибок. А всякие логи уровня info собираете? И если да, то используете syslog и его вариации или что-то другое?
                                    +1
                                    Buildout не пробовал, выглядит круто, спасибо за совет!

                                    Про графит — всё верно. Для продуктовых метрик мы используем другие инструменты: top.mail.ru, liveinternet.ru и google.com/analytics. Плюс некоторые внутренние инструменты.

                                    Логи уровня debug, info пока не собираем. В общем нам достаточно графиков, но логи тоже нужны и с этим нужно будет что-то делать.
                                    +2
                                    Если вы используете Jira и Confluence, почему тогда выбрали Jenkins, а не Bamboo (который интегрирован с атласиановскими продуктами)?
                                      0
                                      Так исторически сложилось =)
                                      Возможно, со временем перейдём на Bamboo, а пока работает главное правило: «работает — не трожь!».
                                      +2
                                      Вопрос по документации: каким образом поодерживаете её в актуальном состоянии и кто этим заведует? Может посоветуете какие-то лучше практики? Есть ли в вашем рабочем флоу задача на документацию?
                                        0
                                        Всё на совести коллег. Бывают, конечно, проблемы с устаревшей документацией, но адекватный разработчик просто поправит это, когда увидит.

                                        У нас нет публично доступной документации. Если бы она была (например, наше API было бы открыто для всех), тогда за обновлением информации следили бы особо пристально. Поэтому никаких особых пунктов про документацию в workflow нет. В некоторых случаях ответственный человек (например, я, как тимлид) может просить добавить/поправить что-то в confluence.

                                        Совет один: нанимать адекватных разработчиков. Самый лучший вариант изменения рабочего процесса — когда сами программисты чувствуют те или иные узкие места в работе и внедряют те или иные улучшения. Когда указание по применению новых инструментов спускают «сверху», это всегда встречает отторжение, по крайней мере в первое время.
                                        +1
                                        Спасибо за емкий расклад проекта!
                                        Хотелось уточнить момент насчет виртуальных серверов в тестовой сети (для почты к примеру) — вы используете vim, emacs,
                                        а нельзя, например, дежать код локально, использовать IDE и аплоадить код при изменении в свое дев окружение по sftp? Как минимум для удобства индексации проекта?
                                          0
                                          Спасибо!

                                          Ценное замечание. Можно держать код локально, и многие наши разработчики так делают: запускают скрипт, который при изменении файлов в директории проекта просто запускает rsync для синхронизации локальной папки с удалённой директорией на виртуальной машине.
                                          +1
                                          Большое спасибо за вашу статью, за то что делитесь опытом!
                                          Отдельное спасибо, что указали сторонние системы и сервисы, которые вы используете в вашем проекте. Меня, например, заинтересовала Sentry, как раз подумываю внедрить что-то подобное в свой проект. Но я больше смотрел в сторону logstash, как более универсального инструмента для структурного логирования.
                                            0
                                            Logstash хорош, согласен, но это именно логи, — полноценно заменить Sentry с его подробнейшей информацией об исключениях и ошибках не получится.
                                            Думаю, эти два инструмента идеально дополняют друг друга. Мы сейчас кое-где используем Sentry в тех случаях, когда хватило бы просто логов, и это, конечно же, не совсем правильно.
                                            +1
                                            Очень похоже на то, как у нас все устроено. Отличается несколько моментов:
                                            * Мы не собираем пакеты (а, возможно, надо бы, подумаем)
                                            * Мы используем hgflow (кстати, советую присмотрется, в вашем случае — к gitflow)
                                            * В качестве CI используем Bamboo — проект тоже от Atlassian, поэтому прекрасно интегрируется с Jira и остальными
                                            * Статистика у нас — свой велосипед
                                              +1
                                              — Пакеты удобны, позволяют в любой момент разложить любую версию проекта.
                                              — Gitflow смотрели, пробовали, пока не прижилось. Возможно, в будущем ещё раз попробуем, спасибо за совет =)
                                              — Уже не первый раз мне советуют Bamboo. Обязательно изучу этот продукт, хотя, если честно, не вижу сейчас смысла уходить с Jenkins, ведь всё работает отлично.
                                              — Очень интересно. А можно поподробнее? В чём плюсы-минусы, чего не хватает в существующих решениях? На чём реализована, как?
                                                +1
                                                До бамбу мы пробовали TeamCity, если сравнивать с бамбу – последний выигрывает в удобстве использования.

                                                Про велосипед – нам требуется серьезная аналитика для наших клиентсайд приложений. GA не подходит по некоторым причинам (как минимум – среда выполнения кода не позволяет подключать ga.js). Штуки вроде statsD/graphite (на первый взгляд, по крайней мере) подходят для анализа простых количественных метрик, но не дают возможности удобно работать с различными срезами/измерениями/фильтрами/аггрегациями. Тут бы подошел OLAP, но его одного тоже недостаточно, нужен комплексный подход, а времени как всегда не хватает) Так что пока мы перебиваемся собственным решением на python/mongo/aggregation framework, и думаем как сделать систему, которая будет удовлетворять наши потребности на 100%.
                                                  0
                                                  Да, графит не аггрегирует статистику по различным срезам (например, просто по уникальным пользователям), тут нужны другие решения.

                                                  Было бы здорово увидеть статью, когда придумаете своё решение для статистики.
                                                  Мне, например, будет очень интересно почитать об этом =)
                                                    +1
                                                    Обязательно напишем, если что толковое получится :)

                                            Only users with full accounts can post comments. Log in, please.