Ответ 1
После долгих размышлений и экспериментов я решил, где использовать Vagrant и как он интегрируется с рабочим процессом разработки Java.
Для JavaEE/развернутых приложений настройка веб-сервера и сервера базы данных - это, безусловно, вещи, которые имеют "достаточную" сложность, чтобы оправдать использование Vagrant. С двумя серверами и множеством способов их настройки легко настроить синхронизацию с одного разработчика на другой, что приводит к синдрому "работает на моей машине". Для такого программного обеспечения было бы лучше всего отредактировать и скомпилировать код на хосте и развернуть на Vagrant VM, который имитирует вашу производственную среду. Папка развертывания для веб-сервера может быть даже привязана к цели компиляции на хосте, что устраняет необходимость повторного развертывания вручную. Таким образом, Vagrant может быть важной частью жизненного цикла разработки, но время цикла для кода/компиляции/развертывания с хоста и запуска на виртуальной машине с Java будет больше, чем время цикла для кода на хосте и запускается на виртуальной машине, что мы видим с PHP/Ruby/ Node/и т.д.
Для автономных приложений Java (например, библиотек или настольных приложений) история немного меняется. В этом случае имеет смысл редактировать, компилировать и запускать на главной машине, избегая использования Vagrant вообще. Если вы используете одну из больших Java IDE (Eclipse, Netbeans, IntelliJ...), у вас уже установлена Java на компьютере. В этот момент очень мало преимуществ по сравнению с накладными расходами на использование Vagrant, и это только служит для добавления дополнительного уровня сложности в процесс разработки. Это связано с тем, что к тому времени, когда вы сможете редактировать Java с помощью IDE, вы все равно можете запускать все на хосте. Одна из проблем заключается в том, что версия Java, требуемая для проекта, может не соответствовать версии, запускающей IDE на хосте. В целом (надеюсь) это не слишком большая проблема; На момент написания этой статьи JDK6 остался без конца, и JDK8 еще не выпущен (предположим, что это оставляет нас). Но если вам нужно запустить несколько версий, вы должны установить JAVA_HOME на хост по мере необходимости. Несмотря на то, что это вводит дополнительную сложность, это не так сложно, как поддерживать время выполнения Vagrant, просто для работы с проектами, использующими разные версии Java.
Интересный вопрос - что делать с неконтейнерными веб-приложениями. Должен ли веб-сервер (в данном случае внутренний для приложения) запускаться внутри виртуальной машины, как это было сделано для внешнего веб-сервера? Или запустить на хосте, как мы сделали для автономного приложения? Для веб-приложений без контейнеров нет внешнего веб-сервера, о котором можно беспокоиться, но, вероятно, есть база данных. В этой ситуации мы можем использовать гибридный подход. Запуск веб-приложения без контейнеров по существу совпадает с запуском автономного приложения, поэтому было бы эффективно компилировать и запускать ваш код на главной машине. Но при использовании базы данных все еще есть достаточно сложностей и конфигурации, что имеет смысл иметь сервер базы данных на собственной Vagrant VM.
Надеюсь, это даст разработчикам Java, которые заинтересованы в использовании Vagrant в том, как использовать его.