Vim in full: Deploy

    Table of contents


    1. Introduction (vim_lib)
    2. Plugin manager without fatal flaws (vim_lib, vim_plugmanager)
    3. Project level and file system (vim_prj, nerdtree)
    4. Snippets and file templates (UltiSnips, vim_template)
    5. Compiling and executing anything (vim-quickrun)
    6. Work with Git (vim_git)
    7. Deploy (vim_deploy)
    8. Testing with xUnit (vim_unittest)
    9. The library on which everything rests (vim_lib)
    10. 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 customers do not mind being in the know where the budget goes and at what stage their project. This is quite simple to achieve, since there is even a whole methodology called “Continuous Integration” that allows you to deploy minor changes as soon as possible, but how to make it convenient enough for the programmer? After all, no one wants to write code, and then switch to the deployment system context or even use an ssh connection to deploy minor changes to the production (or to the dev server).

    It was the reluctance to often switch attention between the editor and the deployment system that prompted me to implement the plugin that 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 the adapters that it 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 the same deployment systems)
    • You create task files for the deploy system used to the root of the project
      For instance
      host='raspberrypi'                                                                                                                                              
      path='/var/www'
      [deploy]
      git checkout master
      git pull
      php ./update.php
      


    • You use the vim_deploy commands or hot keys to quickly deploy the project, and the deployment system that is configured for the current project will be completely transparent to the user

    In fact, this means that you can work with several projects at once and use the same commands (hot keys) to deploy them no matter what deployment systems are used in them.

    Using


    I will give an example of using this plugin in conjunction with shipit . Why exactly him? I like shipit for its ingenious simplicity, because I often use it for my projects.

    As mentioned above, first you need to install vim_deploy and any adapter to work with the deployment system. This is done similarly to any other Vim plugins, so I will not go into details. After that you should configure vim_deploy so that it uses the adapter of your choice. To do this, add the following code to .vimrc :
    let vim_deploy#options = {'adapter': 'shipit'}
    

    An example of my .vimrc
    Plugin 'vim_deploy', {
          \  'options': {'adapter': 'shipit'},
          \  'map': {'deploy': 'd'},
          \}
    Plugin 'shipit'
    


    Also set a 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 start deploying. If you use vim_prj , which I wrote about 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 - deploy project
    • DeployRun task - perform deployment task
    • DeployList - list of available tasks
    • DeployEdit - open the deployment system task file


    Bye bye


    The vim_deploy plugin can be adapted to work with build systems (for example, Grunt) or deployment of a local environment (for example, Vagrant), but I planned to implement separate plugins 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.

    Also popular now: