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

• действия выполняются вручную, что требует сосредоточенности и аккуратности;
• жёсткие временные рамки.

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

Несколько месяцев назад мы ускорили генерацию code coverage с 70 до 2,5 часов. Реализовано это было как дополнительный формат в экспорте/импорте coverage. А недавно наши pull requests попали в официальные репозитории phpunit, phpcov и php-code-coverage.

Мы не раз рассказывали на конференциях и в статьях о том, что мы «гоняем» десятки тысяч юнит-тестов за короткое время. Основной эффект достигается, как несложно догадаться, за счёт многопоточности. И всё бы хорошо, но одна из важных метрик тестирования ― это покрытие кода тестами.
Сегодня мы расскажем, как его считать в условиях многопоточности, агрегировать и делать это очень быстро. Без наших оптимизаций подсчёт покрытия занимал более 70 часов только для юнит-тестов. После оптимизации мы тратим всего 2,5 часа на то, чтобы посчитать покрытие по всем юнит-тестам и двум наборам интеграционных тестов общим числом более 30 тысяч.

В июле мы вместе с ведущими IT-Kompot и релиз-инженерами Badoo Владиславом Черновым и Олегом Оямяэ записали выпуск подкаста «Процесс разработки и выкатка релизов в Badoo. Автоматическое тестирование. Девелоперское окружение».
Так как прошлый подкаст вызвал интерес у слушателей и читателей, то этот подкаст мы тоже превратили в статью.

О чем говорили:
Процесс разработки и выкатки релизов в компании Badoo. Используемые инструменты.

• GIT Workflow. Каждая задача в отдельной ветке;
• Использование JIRA, TeamCity и AIDA;
• Формирование релиза и выкатка двух релизов в день. Проблемы и их решения (откат, патчи и т.д.).

Автоматическое тестирование. Рецепт быстрого прогона большого количества тестов.

• Что мы используем;
• Как гоняем тесты;
• Code Coverage;
• Пускалка. 18000 тестов за 3,5 минуты.

Девелоперское окружение в команде, разрабатывающей сложную распределенную систему
И рекомендации от ребят: полезные книги, статьи и т.д.

Хочу рассказать, как компания Badoo охраняет аккаунты своих клиентов. Данная статья написана исключительно в образовательных целях. Я не подталкиваю никого к совершению противоправных действий и не преследую никакого злого умысла.

Не все Bug Bounty programs одинаково полезны

В марте 2013 года компания Badoo объявила конкурс «Проверь Badoo на прочность!».
Конкурс манил призами и я, довольная успехом в поиске уязвимостей для Yandex, зарегистрировалась на сайте, посмотрела, какие ссылки приходят в письмах, и просто вбила их в поисковую строку Google.

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

Статья дает общее описание архитектуры системы с небольшими техническими подробностями и будет интересна тем, кто только собирается или уже каким-то способом уведомляет своих пользователей обо всём новом, что произошло за время их отсутствия на сайте (в приложении, сервисе и т.п.)

Привет! Новая версия контрольной панели для хостеров Parallels Plesk Panel 11.5 в эфире. Здесь уже не раз обсуждались предыдущие версии, причем за всеми комментариями мы внимательно следили. В итоге в новой версии пожелания пользователей учитывались по максимуму. Итак, что изменилось в 11.5?

PHP

• Для каждого сайта теперь можно выбрать любую установленную на сервере и зарегистрированную в Plesk версию PHP – своей сборки или загруженную из репозитория. Нас об этом просили, потому что разные веб-сайты часто требуют разных версий PHP.
• Появился режим «Гибридного веб-сервера», когда часть PHP скриптов можно запускать с помощью nginx, пока остальные работают на Apache. Гибридность при этом — настройка домена, а не сервера.


Конфигурация PHP на странице настройки параметров сайта

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



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

По-моему, эта статья — самое важное, что я в жизни сделал. Не самое сложное, объёмное или интересное, а важное.

Описываю я тут всего лишь одну особенность русских разработчиков и капитаню по-всякому, но это ключевая особенность, отличающая наших разработчиков, тестировщиков и даже звукорежиссёров, как оказалось. История Макаревича под катом.

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

На этой неделе мы выкладывали первую часть расшифрованного подкаста. Сейчас подготовили вторую часть.

О чем мы говорим во второй части подкаста:

• Горизонтальное масштабирование проекта

— когда стоит использовать облачные сервисы, а когда физический хостинг;
— «красивость решения» против «грязного, но производительного» кода. ORM и всякие подобные штуки;
— мультиязычность и мультизонность проекта, проблемы и решения.

• Асинхронные задачи. Очереди.

— асинхронные задачи в распределенных системах;
— когда они приходят на помощь, какие технологии существуют и активно развиваются сейчас;
— какие подходы организации асинхронных задач используются в Badoo;
— c какими проблемами приходилось и приходится сталкиваться при работе с очередями;
— полезные книги и интересные конференции;
— интересные кейсы с собеседований.

Некоторое время назад зам.главы московского офиса разработки Badoo Алексей Рыбак и ведущие IT-Компот записали выпуск подкаста «Архитектура высоконагруженных приложений. Масштабирование распределенных систем".

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

О чем говорили в первой части:

• Общая информация о проекте Badoo: стек технологий, характер и объем нагрузки, посещаемость.
• Горизонтальное масштабирование проекта:

— веб-сервера, кеширование, мониторинг etc;
— подводные камни при масштабировании проекта;
— масштабирование баз данных, как правильно делать шардинг.

Сегодня мы поговорим про разработанную нами утилиту, которая оптимизирует тестирование PHP-кода с помощью PHPUnit и TeamCity. При этом нужно понимать, что наш проект — это не только веб-сайт, но и мобильные приложения, wap-сайт, Facebook-приложение и много чего ещё, а разработка ведется не только на PHP, но и на C, C++, HTML5 и т.д.

Методы, которые мы описываем, прекрасно адаптируются под любой язык, любую систему тестирования и любое окружение. Поэтому наш опыт может оказаться полезным не только разработчикам веб-сайтов на PHP, но и представителям других областей разработки. Кроме того, в ближайшем будущем мы планируем перевести нашу систему в Open Source ― без обязательной привязки к TeamCity и PHPUnit ― наверняка она кому-нибудь пригодится.

Для нас, как и для большинства социальных сетей, очень важны email-рассылки. Одной из интересных и сложных технических задач является корректное отображение писем на мобильных устройствах. Сейчас около 23% писем Badoo открывается именно на них, и это число постоянно увеличивается. А возможно, кто-то прямо сейчас читает наше письмо на своем интернет-холодильнике.
Сегодня мы расскажем, каких правил придерживаться в разработке электронных писем, как сохранить их юзабилити на мобильных устройствах, а также поделимся своими хитростями, накопленными в процессе работы.

Требования

С какими проблемами мы столкнулись и какие требования предъявляются к нашим письмам:

• письма должны корректно отображаться в множестве разных почтовых клиентов и браузеров;
• они должны быть оптимизированы под различные устройства на платформах iOS и Andriod (смартфоны с большим, средним и малым разрешением экрана; планшетные компьютеры);
• нужна обязательная поддержка Outlook 2003/2007/2010, т.к. он занимает большой сегмент использования;
• редактирование компонентов, которые применяются еще в 50 шаблонах писем;
• необходимо создавать универсальные блоки, которые будут подстраиваться под ситуацию, т.к. в письмах данные имеют динамическую структуру (например, письма переводят на 44 языка, в них меняются размеры блоков, изображений, размер текста).

Большинство статей в наш блог пишут разработчики. Мы решили исправить эту несправедливость и добавить немного DevOps. Сегодня поговорим о важном ― о бэкапах.
Так как Badoo активно развивается и количество сотрудников постоянно увеличивается, мы пришли к выводу, что централизованное резервное копирование гораздо удобнее, чем частичное копирование и хранение информации в различных местах.
В статье мы рассмотрим, как различными способами «забэкапить» довольно большое количество рабочих станций с помощью одного хранилища, не прибегая к серьёзным вложениям и избегая громоздкой реализации.
Заранее оговоримся, что бэкап не охватывает 100% сотрудников, так как не все хранят свои данные на локальных машинах, поэтому у нас не было цели сделать бэкап обязательно-принудительным.
Одной из основных сложностей централизованного бэкапа стало то, что сотрудники используют разные операционные системы.

Как же мы смогли собрать всех на одном сервере?

19 марта мы объявили о начале месяца поиска уязвимостей «Проверь Badoo на прочность». Сегодня нам хочется подвести первые итоги и поделиться с вами промежуточными результатами, рассказать, как мы готовились к проверке на прочность, рассмотреть самые интересные уязвимости и сделать «фейспалм».

И для начала немного статистики:

• за первые две недели участники прислали нам почти 500 заявок с потенциальными уязвимостями;
• около 50 заявок оказались дубликатами;
• каждая десятая заявка содержала в себе реальную уязвимость (самые опасные были исправлены в течение нескольких часов);
• Более 150 заявок составили ошибки, не связанные с безопасностью сайта, и около 10% из них относятся к платформам, не участвующим в конкурсе.
• большинство уязвимостей пришлось на самый главный компонент системы ― профиль (как только участники конкурса не издевались над аккаунтами пользователей: удаляли и загружали фотографии, манипулировали комментариями, интересами, личными данными и адресами электронной почты).
• Более половины присланных уязвимостей ― различные CSRF, в основном затрагивающие загруженный или написанный пользователями контент (удаление и загрузка фото и комментариев, работа с чёрным списком, избранным и т.д.).

В Badoo используется много сервисов на C и C++, большинство из которых работают с огромными объёмами данных. Как правило, сервисы выступают в роли «быстрого кэша» или «быстрой базы данных», т.е. совершают различные операции с массивами однотипных данных. Для быстрого доступа к данным мы давно и успешно используем Judy-массивы (англ. Judy arrays). Но однажды нам захотелось странного: обрабатывать большие массивы целых чисел на PHP, и мы сразу вспомнили про Judy.

Немного истории

Judy-массивы были изобретены Дугласом Баскинсом (англ. Douglas Baskins) в начале 2000-го года. Проект их разработки финансировался компанией HP, но примерно через два года был закрыт. За это время было выпущено четыре версии, причём разработка последней заняла больше года, и в ней разработчики смогли в два раза ускорить Judy, в два раза уменьшить потребление памяти, хоть и далось это нелёгкой ценой: объём кода вырос в 5 раз, а его сложность  ― на порядок.

Компания Badoo, вслед за своими коллегами ― крупнейшими представителями IT-индустрии, такими как Google, Facebook и Яндекс, начинает платить за найденные уязвимости. Мы объявляем конкурс «Проверь Badoo на прочность!», который стартует 19 марта и продлится ровно месяц.

Участвовать в конкурсе могут все желающие, кроме сотрудников Badoo. Каждый участник может отправить любое количество заявок.
Участники обязуются сохранять найденные уязвимости в тайне до тех пор, пока Badoo не сообщит об их исправлении в таблице заявок, но не дольше чем до 31 мая 2013 года.
Мы платим за все найденные новые уязвимости.
Уязвимости будут ранжированы от 5-й (500 фунтов стерлингов) до 1-й категории (50 фунтов стерлингов) в зависимости от их критичности. Категорию критичности определяет жюри конкурса.

К тому же у нас есть специальный приз! По итогам конкурса 3 самых активных участника получат по 1000 фунтов. Если вы нашли что-то очень серьезное, то мы можем выдать супер-премию выше 500 фунтов.

Сегодня мы проведём экскурсию по цеху разработки Badoo, в котором создаётся новый функционал нашего сайта, расскажем о самом процессе — от постановки задачи и до момента выкладки в боевое окружение.

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

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

AIDA (англ. Automated Interactive Deploy Assistant) — это учётная запись, значительно облегчающая работу с Git, TeamCity и JIRA.
Сегодня речь пойдет о том, как с её помощью нам удалось автоматизировать многие рабочие процессы.

В первую очередь мы вспомним об используемой в Badoo системе контроля версий, далее расскажем о том, как было автоматизировано создание веток релиза и осуществлено автоматическое слияние веток в Git, поговорим о существенной помощи AIDA в работе с JIRA (контроль и изменение статуса задач, заполнение полей) и ТeamCity (непрерывная интеграция и развёртывание на тестовое окружение).

Навеяно предыдущей статьей на эту тему.
Для того чтобы, структурировать свое понимание – что представляют собой threads (это слово переводят на русский язык как «нити» почти везде, кроме книг по Win32 API, где его переводят как «потоки») и чем они отличаются от процессов, можно воспользоваться следующими двумя определениями:

• Thread – это виртуальный процессор, имеющий свой собственный набор регистров, аналогичных регистрам настоящего центрального процессора. Один из наиважнейших регистров у виртуального процессора, как и у реального – это индивидуальный указатель на текущую инструкцию (например, индивидуальный регистр EIP на процессорах семейства x86),
• Процесс – это в первую очередь адресное пространство. В современной архитектуре создаваемое ядром ОС посредством манипуляции страничными таблицами. И уже во вторую очередь на процесс следует смотреть как на точку привязки «ресурсов» в ОC. Если мы разбираем такой аспект, как многозадачность для того, чтобы понять суть threads, то нам не нужно в этот момент думать о «ресурсах» ОС типа файлов и к чему они привязаны.

Очень важно понять, что thread – это концептуально именно виртуальный процессор и когда мы пишем реализацию threads в ядре ОС или в user-level библиотеке, то мы решаем именно задачу «размножения» центрального процессора во многих виртуальных экземплярах, которые логически или даже физически (на SMP, SMT и multi-core CPU платформах) работают параллельно друг с другом.

Здравствуйте дорогие читатели. В данной статье мы рассмотрим различные потоковые модели, которые реализованы в современных ОС (preemptive, cooperative threads). Также кратко рассмотрим как потоки и средства синхронизации реализованы в Win32 API и Posix Threads. Хотя на Хабре больше популярны скриптовые языки, однако основы — должны знать все ;)

Если вы работаете в большой команде разработчиков над одним и тем же проектом, то рефакторинг становится очень сложной задачей. Приведем пример: мы хотим переименовать функцию do_something() в do_something_with_blackjack(). Мы переименовали все вхождения этой функции в своей ветке и отправили задачу на тестирование. В тот же момент кто-то другой добавил ещё один вызов функции, но со старым названием, тоже в своей ветке. По отдельности наборы изменений будут работать, а вот после слияния получится ошибка.

В статье будет рассмотрен приём, который можно назвать «автоматизированный рефакторинг» — использование самописных скриптов, которые делают нужную работу за вас, позволяя провести рефакторинг после слияния всех веток и перед непосредственной выкладкой на staging/production.

На примере phpBB будет показано, как можно «отрефакторить» вызовы SQL-запросов, чтобы они использовали автоматическое экранирование входных данных (и таким образом помочь в решении проблемы SQL-инъекций).