Ваша цель — это надежный и дееспособный продукт на Друпале (да, впрочем, на чем угодно, но Друпал мне ближе по духу, посему буду концентрировать примеры на нем)?
Если да, то длинный и тернистый путь непрерывной интеграции (Continuous Integration), непрерывной инспекции и непрерывного фидбека — это ваш путь. Как Вы могли догадаться, путь тоже непрерывен.
Ребята, в последний раз, когда я смотрел на календарь, на дворе был 2015 год, лето было горячим, а вот кофе уже остыл. И в эту эру технологических инноваций, доступной информации, тонн материалов в интернете о том, как делать стоит, и тем более о том, как делать НЕ НУЖНО, люди по-прежнему дико валят свои проекты. И при этом вгоняют компании в неизмеримую яму технического долга.
И тем не менее, мне в руки постоянно попадают проекты в таком состоянии, что не верить в бога, либо дьявола, в данном конкретном случае поистине невозможно. Такое количество дефектов где-то там, «в глубине души», попросту невообразимо. Не то чтобы я был против, благодаря такому походу я всегда снабжен работой и хорошей материальной компенсацией. Все это я пишу а) просто из интереса: уж очень хочется ваше мнение узнать, и б) глядишь, помогу кому. А по поводу уменьшения объема работы волнуюсь не сильно, не думаю, что в Индии (а именно оттуда идет львиная доля всего, что нужно фиксить и переделывать) читают Хабр. Иногда мне кажется, что тамошние кодеры вообще ничего не читают, а просто рандомно барабанят по клавишам, пока хоть что-то хоть как-то не заработает. Ну да ладно, разговор не о них.
Я, конечно, не утверждаю, что непрерывная интеграция или её элементы — это квинтэссенция совершенного деплоя, но практика хороша. Чертовски хороша.
Согласно SEI, холодные фиксы стоят $2,656 за каждую строку кода (ссылку на пруф не даю, все легко гуглится). А строк таких обычно великое множество, так как дефекты сидят глубоко, глядят далеко и обычно напрямую затрагивают и непосредственный функционал, и технические/бизнес требования. То ли дело, когда дефект замечен и истреблен сразу по появлении, когда достаточно нескольких простых манипуляций, ловкости рук и (иногда) небольшого мошенничества. Это означает меньше требуемого кода, значительно сокращенные затраты времени и функционал, который соответствует, а то и превосходит требования как в стабильности, так и в дальнейшей эксплуатации и содержании.
Как все отлично известно, менеджеры и программисты отличаются друг от друга. Последние своими натруженными ручками пишут код и знают его наизусть. Так вот менеджер может предполагать стабильность какого-либо продукта к запуску исходя из получаемой информации (верной или искаженной), в то время как программист определяет отсутствие дефектов в коде, тем самым устраняя сомнения в готовности того или иного билда.
Те сть НИ (непрерывная интеграция) устраняет сомнения и дает доступ на некий уровень проактивности. Проблемы, которые могут иметь место быть в каких-либо версиях (git ветвях), мониторятся на постоянной основе, тем самым добавляя в процесс разработки лучшие элементы QA.
Все, что я тут напишу, не будет иметь ровно никакого смысла без конкретных примеров. Да и мы не на рынке за баранью ногу торгуемся, чтоб вы мне на слово о свежести оной верили.
Основные тезисы непрерывной интеграции:
Непрерывная инспекция — это важная составляющая НИ и призвание её в следующем: этот процесс обязан показать и наглядно визуализировать весь процесс разработки, да так, чтобы было понятно именно тем большим дядям у руля, у которых ключ от квартиры, где деньги лежат. То есть инспекция — часть важная и незыблемая, а разделить её можно на следующие элементы:
1. Анализ кода и отчет
2. Тренды
3. Собранная информация, повествующая обо всех дефектах, которые имели место в последних изменениях
4. Непосредственный фокус на основных (для бизнеса) элементах
5. Абсолютный контроль над всеми возможными проблемами и дефектами
Nokia – connecting people! Слоган этот знаменит и применим в гораздо большем числе случаев, чем изначально предполагали маркетологи производителя незыблемых молотов и мухобоек. В нашем конкретном случае непрерывный фидбек принимает на себя роль финского орудия труда и налаживает мосты между всеми, кто вовлечен в создание продукта.
Зачем оно нужно? Ну, как же, культурное общение — это основа здорового общества, а заказчик, который постоянно в курсе всего — это довольный заказчик (который не лезет в процесс с лишними, дурацкими вопросами). Главное, как и везде, все делать правильно! Руководствуйтесь простым правилом: «Правильным людям. В правильное время. В правильной форме». Как именно доносить информацию — это уже даже не вопрос для века, в котором есть:
Ну, а теперь перейдем ближе к делу. Вот вам небольшой кейс для рассмотрения.
Проект: новостной интернет-портал, который содержит функционал блога, показывает видосики (нет, не что, что вы подумали, фи на вас!) и представляет собой целое сообщество. Технологии, которые питают наш портал:
В целях конспирации и из-за кип подписанных бумажек все имена были изменены, а сходства с реальностью чисто случайны (ну или не совсем случайны, хех-хе).Вернемся к нашим баранам. Вот та картина, которая изначально предстала пред мои ясны очи:
Не волнуйтесь, я знаю, это сложно, но попытайтесь перебороть желание окропить монитор святой водой, все уже готово.
Так вот, вывод, к которому пришел я:
Архитектура явно кривовата, что привело к созданию серии ботлнеков, не давало возможности эффективного распределения внутри системы и стало огромной головной болью на фазе содержания. В общем, все не сильно-то и ремонто-пригодно. Код не соответствует стандартам, и тех долг составляет целых полтора (ПОЛТОРА) года!
Что было предпринято:
Что получилось?
Судите сами, как по мне – конфетка. По сравнению с тем, что было, как минимум. Да и вообще, работа на 5 с плюсом, поскольку:
Вы вот сами увидели результат хорошей работы с помощью НИ. Почему-же методология еще так слабо распространена среди тех, кто разрабатывает очень много внешних проектов? Это же просто уничтожает аутсорсинг как индустрию и подрывает доверие к нормальным специалистам. И да, я знаю, что кушать можно как ложкой, так и вилкой, и тут также есть и другие пути решения. Но зачем изобретать велосипед? Вот вы скажите, пользуетесь ли вы НИ, если да, то как, если нет, то почему?
Если да, то длинный и тернистый путь непрерывной интеграции (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+К пользователей в час
Вывод
Вы вот сами увидели результат хорошей работы с помощью НИ. Почему-же методология еще так слабо распространена среди тех, кто разрабатывает очень много внешних проектов? Это же просто уничтожает аутсорсинг как индустрию и подрывает доверие к нормальным специалистам. И да, я знаю, что кушать можно как ложкой, так и вилкой, и тут также есть и другие пути решения. Но зачем изобретать велосипед? Вот вы скажите, пользуетесь ли вы НИ, если да, то как, если нет, то почему?
