Pull to refresh

Vim по полной: Деплой

Reading time 3 min
Views 12K

Оглавление


  1. Введение (vim_lib)
  2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
  3. Уровень проекта и файловая система (vim_prj, nerdtree)
  4. Snippets и шаблоны файлов (UltiSnips, vim_template)
  5. Компиляция и выполнение чего угодно (vim-quickrun)
  6. Работа с Git (vim_git)
  7. Деплой (vim_deploy)
  8. Тестирование с помощью xUnit (vim_unittest)
  9. Библиотека, на которой все держится (vim_lib)
  10. Другие полезные плагины

Мне нравится, когда клиент может сразу увидеть результаты моих трудов. Я могу корректировать развитие проекта согласно желаниям заказчика, что сильно спасает от недопонимания. Думаю и клиенты не против быть в курсе, куда уходит бюджет и на каком этапе их проект. Добиться этого достаточно просто, благо есть даже целая методология, называемая «Непрерывной интерграцией», позволяющая в кратчайшие сроки деплоить мелкие изменения, но как сделать, чтобы это было достаточно удобно для программиста? Ведь никому не хочется писать код, а после переключаться в контекст системы деплоя или даже использовать ssh соединение чтобы развернуть мелкие изменения на продакшене (или на dev сервере).

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

Универсальность


Плагин vim_deploy задумывался как универсальный интерфейс для работы с различными системами деплоя. Этот плагин не реализует никакой логики развертывания проекта, а лишь определяет семантику адаптеров, которые могу им использоваться для работы с различными системами деплоя. Вот как это работает:
  • Вы устанавливаете себе vim_deploy и один или несколько адаптеров для него, таких как shipit или gradle (для одноименных систем развертывания)
  • Вы создаете файлы задач для используемой системы деплоя к корне проекта
    На пример
    host='raspberrypi'                                                                                                                                              
    path='/var/www'
    
    [deploy]
    git checkout master
    git pull
    php ./update.php
    


  • Вы используете команды vim_deploy или горячие клавиши для быстрого развертывания проекта, при этом совершенно прозрачно для пользователя будет использована та система деплоя, которая настроена для текущего проекта

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

Использование


Приведу пример использования данного плагина в связке с shipit. Почему именно он? Мне нравится shipit своей гениальной простотой, потому я часто использую его для моих проектов.

Как уже было сказано выше, сначала нужно установить vim_deploy и любой адаптер для работы с системой деплоя. Делается это аналогично любым другим плагинам Vim, потому вдаваться в подробности я не буду. После следует настроить vim_deploy так, чтобы он использовал выбранный вами адаптер. Для этого в .vimrc достаточно добавить следующий код:
let vim_deploy#options = {'adapter': 'shipit'}

Пример моего .vimrc
Plugin 'vim_deploy', {
      \  'options': {'adapter': 'shipit'},
      \  'map': {'deploy': '<Leader>d'},
      \}
Plugin 'shipit'


Так же установите горячую клавишу для функции vim_deploy#deploy, чтобы каждый раз не вводить команду. Остается только создать файл .shipit (с задачами деплоя) в каталоге проекта и можно начинать деплоить. Если же вы используете vim_prj, о котором я писал раньше, то адаптер для системы деплоя можно установить на уровне проекта, а не глобально.

Плагин vim_deploy так же включает следующие команды:
  • Deploy — деплой проекта
  • DeployRun задача — выполнение задачи деплоя
  • DeployList — список доступных задач
  • DeployEdit — открыть файл задач системы развертывания


Пока все


Плагин vim_deploy можно приспособить для работы с системами сборки (на пример Grunt) или развертывания локального окружения (на пример Vagrant), но я планировал реализовать для этого отдельные плагины, унифицирующие интерфейсы различных систем, подобно описанному в данной статье подходу. Если вы, прочитав данную стать, подумали — мне как раз не хватает такой штуки для… — напишите об этом в комментариях.
Tags:
Hubs:
+12
Comments 2
Comments Comments 2

Articles