Table of contents
- Introduction (vim_lib)
- Plugin Manager without fatal flaws (vim_lib, vim_plugmanager)
- Project level and file system (vim_prj, nerdtree)
- Snippets and File Templates (UltiSnips, vim_template)
- Compiling and doing anything (vim-quickrun)
- Work with Git (vim_git)
- Deploy (vim_deploy)
- Testing with xUnit (vim_unittest)
- The library on which everything is kept (vim_lib)
- Other useful plugins
I like it when a client can immediately see the results of my work. I can adjust the development of the project according to the wishes of the customer, which greatly saves from misunderstanding. I think clients are not against being aware of where the budget goes and at what stage their project. To achieve this is quite simple, since there is even a whole methodology, called “Continuous Integration,” which allows you to deploy small changes in the shortest time possible, but how to make it convenient enough for a programmer? After all, no one wants to write code, and then switch to the context of the deployment system, or even use an ssh connection to deploy small changes in production (or on a dev server).
It was precisely this reluctance to switch attention frequently between the editor and the deployment system that prompted me to implement a plugin, which I want to tell you about.
Versatility
The
vim_deploy plugin
was conceived as a universal interface for working with various deployment systems. This plugin does not implement any project deployment logic, but only defines the semantics of adapters that they can use to work with various deployment systems. Here's how it works:
- You install vim_deploy and one or more adapters for it, such as shipit or gradle (for deployment systems of the same name)
- You create task files for your deployment system to the project root.
For examplehost='raspberrypi' path='/var/www' [deploy] git checkout master git pull php ./update.php
- You use the vim_deploy commands or hotkeys for quick project deployment, and the deployment system configured for the current project will be completely transparent to the user.
In practice, this means that you can work with several projects at once and use the same commands (hot keys) for their deployment, regardless of which deployment systems they are used in.
Using
I will give an example of using this plugin in conjunction with
shipit . Why precisely he? I like shipit with my ingenious simplicity, because I often use it for my projects.
As mentioned above, you must first install vim_deploy and any adapter to work with the deployment system. This is done like any other Vim plug-in, so I will not go into details. After that, you need to configure vim_deploy so that it uses the adapter you selected. To do this, it’s enough to add the following code to
.vimrc :
let vim_deploy
An example of my .vimrc Plugin 'vim_deploy', { \ 'options': {'adapter': 'shipit'}, \ 'map': {'deploy': '<Leader>d'}, \} Plugin 'shipit'
Also install the hotkey for the
vim_deploy # deploy function so that you do not enter a command each time. It remains only to create a
.shipit file (with deployment tasks) in the project directory and you can begin to deploy. If you use
vim_prj , about which I
wrote earlier, then the adapter for the deployment system can be installed at the project level, and not globally.
')
The
vim_deploy plugin also includes the following commands:
- Deploy - project deployment
- DeployRun task - execution of the deployment task
- DeployList - list of available tasks
- DeployEdit - open the deployment system task file
Bye all
The
vim_deploy plugin can be adapted to work with build systems (for example Grunt) or to deploy a local environment (for example Vagrant), but I planned to implement separate plug-ins for this, unifying the interfaces of different systems, similar to the approach described in this article. If you, after reading this article, thought - I just do not have enough of such a thing for ... - write about it in the comments.