Ваша цель — это надежный и дееспособный продукт на Друпале (да, впрочем, на чем угодно, но Друпал мне ближе по духу, посему буду концентрировать примеры на нем)?

Если да, то длинный и тернистый путь непрерывной интеграции (Continuous Integration), непрерывной инспекции и непрерывного фидбека — это ваш путь. Как Вы могли догадаться, путь тоже непрерывен.

К чему я это? (Disclaimer)

Ребята, в последний раз, когда я смотрел на календарь, на дворе был 2015 год, лето было горячим, а вот кофе уже остыл. И в эту эру технологических инноваций, доступной информации, тонн материалов в интернете о том, как делать стоит, и тем более о том, как делать НЕ НУЖНО, люди по-прежнему дико валят свои проекты. И при этом вгоняют компании в неизмеримую яму технического долга.

И тем не менее, мне в руки постоянно попадают проекты в таком состоянии, что не верить в бога, либо дьявола, в данном конкретном случае поистине невозможно. Такое количество дефектов где-то там, «в глубине души», попросту невообразимо. Не то чтобы я был против, благодаря такому походу я всегда снабжен работой и хорошей материальной компенсацией. Все это я пишу а) просто из интереса: уж очень хочется ваше мнение узнать, и б) глядишь, помогу кому. А по поводу уменьшения объема работы волнуюсь не сильно, не думаю, что в Индии (а именно оттуда идет львиная доля всего, что нужно фиксить и переделывать) читают Хабр. Иногда мне кажется, что тамошние кодеры вообще ничего не читают, а просто рандомно барабанят по клавишам, пока хоть что-то хоть как-то не заработает. Ну да ладно, разговор не о них.

Я, конечно, не утверждаю, что непрерывная интеграция или её элементы — это квинтэссенция совершенного деплоя, но практика хороша. Чертовски хороша.

Простая математика

Согласно SEI, холодные фиксы стоят $2,656 за каждую строку кода (ссылку на пруф не даю, все легко гуглится). А строк таких обычно великое множество, так как дефекты сидят глубоко, глядят далеко и обычно напрямую затрагивают и непосредственный функционал, и технические/бизнес требования. То ли дело, когда дефект замечен и истреблен сразу по появлении, когда достаточно нескольких простых манипуляций, ловкости рук и (иногда) небольшого мошенничества. Это означает меньше требуемого кода, значительно сокращенные затраты времени и функционал, который соответствует, а то и превосходит требования как в стабильности, так и в дальнейшей эксплуатации и содержании.

Так почему именно непрерывная (интеграция + инспекция + фидбек) = продолжительный успех?

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

Те сть НИ (непрерывная интеграция) устраняет сомнения и дает доступ на некий уровень проактивности. Проблемы, которые могут иметь место быть в каких-либо версиях (git ветвях), мониторятся на постоянной основе, тем самым добавляя в процесс разработки лучшие элементы QA.

Как правильно непрерывно интегрировать?

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

Основные тезисы непрерывной интеграции:

• Часто (хоть 1 раз в день) код вносится в хранилище
• Пишутся автоматизированные тесты
• Прогоняются частные билды (процесс состоит из сборки source code, который хранится в хранилище разработчика, Developer repository)
• «Поломанный» код не вносится в хранилище
• «Поломанные» билды чинятся
• Все проверки и тесты заверяются, как заверяется и то, что код из хранилища сломанного кода не используется

Непрерывная инспекция

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

1. Анализ кода и отчет


2. Тренды


3. Собранная информация, повествующая обо всех дефектах, которые имели место в последних изменениях


4. Непосредственный фокус на основных (для бизнеса) элементах


5. Абсолютный контроль над всеми возможными проблемами и дефектами

Непрерывный фидбек

Nokia – connecting people! Слоган этот знаменит и применим в гораздо большем числе случаев, чем изначально предполагали маркетологи производителя незыблемых молотов и мухобоек. В нашем конкретном случае непрерывный фидбек принимает на себя роль финского орудия труда и налаживает мосты между всеми, кто вовлечен в создание продукта.

Зачем оно нужно? Ну, как же, культурное общение — это основа здорового общества, а заказчик, который постоянно в курсе всего — это довольный заказчик (который не лезет в процесс с лишними, дурацкими вопросами). Главное, как и везде, все делать правильно! Руководствуйтесь простым правилом: «Правильным людям. В правильное время. В правильной форме». Как именно доносить информацию — это уже даже не вопрос для века, в котором есть:

• СМС
• Специальные плагины для браузеров
• Электронная почта
• Да хоть сирены или другие, специально для этого дела продуманные звуковые нотификации

Ну, а теперь перейдем ближе к делу. Вот вам небольшой кейс для рассмотрения.

Пример кейса

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

• Drupal
• MySQL (cluster)
• MongoDB
• JavaScript

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


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

Так вот, вывод, к которому пришел я:
Архитектура явно кривовата, что привело к созданию серии ботлнеков, не давало возможности эффективного распределения внутри системы и стало огромной головной болью на фазе содержания. В общем, все не сильно-то и ремонто-пригодно. Код не соответствует стандартам, и тех долг составляет целых полтора (ПОЛТОРА) года!

Что было предпринято:

• Реструктуризация архитектуры
• Реструктуризация кода
• Хостинг платформы
• Мощное (очень) внешнее кэширование

Что получилось?


Судите сами, как по мне – конфетка. По сравнению с тем, что было, как минимум. Да и вообще, работа на 5 с плюсом, поскольку:

• База данных с 10 000 000 записей
• 10 000 сообщений в секунду
• Сайт неоднократно светился в главной страничке выдачи на Yahoo
• 10+К пользователей в час

Вывод

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