Деплойные миры

Прочитав, статью с критикой деплоймента для питона [1] захотел сделать сравнение по другим популярным на вебе платформам. Рассмотрим и сравним как процесс деплоймента на разных платформах т.е. перенос результатов разработки программного обеспечения на боевые или тестовые серверы. Этот процесс для нас будет интересен по следующим основным критериям:

  • Гибкость модели, это когда можно выложить изменения как через веб-интерфейс сервера например так и исползуя консоль, или заменить на горячую отдельные файлы или что-то еще

  • Изоляция и переносимость, возможность создавать и разворачивать достаточно самостоятельные и переносимые конфигурации

  • Универсальность, когда есть некоторая интероперабельность между решениями и подходами от разных поставщиков

  • Легкость создания и изменения конфигураций проектов

Java

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

Гибкость - 5, Изоляция - 5, Универсальность - 5, Легкость - 4

PHP

Для пхп проекты традиционно деплоились через систему управления версий, развитие технологий сборки сделало процесс несколько более неоднозначным и замороченным, вроде бы не существует общепринятого способа собрать проект из определенной ветки со всеми зависимостями и за один присест установиь на все серверы. Исторически для решения зависимостей сущетсвовали проекты pear/pyrus, а также с очередной волной появился composer которые решают проблему зависимостей довольно неплохо, однако для самого пхп существует большое количество платформозависимых модулей, которые нельзя гарантированно забандлить и обеспечить тем самым универсальное и гарантированное развертывание на любой платформе. Также модули в пхп слабо стандартизированы и тот же автолоад на моей памяти делался по принципу кто во что горазд. Поэтому ставим такие оценки:

Гибкость - 4, Изоляция - 3, Универсальность - 3, Легкость - 4

Python

В питоне для деплойментов обычно разворачивается окружение virtualenv с подключением менеджера зависиомстей easy_install или pip. Подход нетривиальный во многих отношениях. Во-первых в питоне как и в пхп множество модулей являются платформозависимыми и ставятся в виде расширений платформы или просто требуют сборки. Т.е. окружение не является переносимым дистрибутивом, а просто дает некоторую автоматизацию рутины и учета зависимостей. easy_install поддерживает пакеты, но ставятся они тоже весьма хитрым образом, также весьма нетривиальным по нынешним временам является и написание скриптов и конфигураций сборки setup.py. Получаются самые худшие оценки, деплоймент - больная тема для проектов на питоне.

Гибкость - 3, Изоляция - 3, Универсальность - 3, Легкость - 3

JavaScript

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

Гибкость - 3, Изоляция - 4, Универсальность - 4, Легкость - 5

Получаем такую картинку:

Ссылки

  1. Why I hate virtualenv and pip http://pythonrants.wordpress.com/2013/12/06/why-i-hate-virtualenv-and-pip/

Среднее (0 Голоса)
Средний рейтинг 0.0 звезд из 5.


Пока нет комментариев. Будь первым.