Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

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

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

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

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


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

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

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

Для маленьких команд и планов рациональнее применять менее навороченные и больше бесплатные аналоги как бы той же BugzillaPhabricator либо 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

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

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

В среднем, при всяком аудите коммита возникает три-четыре примечания.

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

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

Прекрасный код — отличный код. Следование правилам code-style всеми членами команды разрешает с первого взора разобраться в любом месте программы, а так же разрешает избежать подавляющего большинства тупых ошибок. Всякий пуш в репозиторий календаря проверяется с поддержкой PEP8pyflake и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), а так же дублируются нам, то есть разработчикам плана. Это разрешает неизменно быть в курсе всех задач и оперативно на них реагировать: в трудных случаях мы сами отвечаем написавшим людям и совместно с ними решаем возникшие затруднения.

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

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

Взамен послесловия

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

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

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

Владимир Рудных,
Технический начальник Календаря Mail.Ru.

Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB