Capistrano deployment without git command on share

2019-06-13 00:00发布

问题:

  • Developer A - Local Repository --> pulls/push ---> github
  • Developer B - Local Repository --> pulls/push ---> github
  • Capistrano would remain on our developers' machines, however we will define :repository to point to our GitHub project: set :repository, "git@github.com:myuser/myproject.git" # My clone url
  • Developer A OR Developer B must be allowed to deploy committed files to the production machine.

I'm not sure about the third point here, is this possible?

I've been told by ctcherry here On this workflow, does git command needs to be installed on the production server? that:

1) By default Capistrano will deploy from the repository, so the files getting deployed would come from the code that is checked into github. You can configure Capistrano to deploy it from the developers local machine by using a different "deployment strategy" See here: http://rubydoc.info/gems/capistrano/2.5.19/Capistrano/Deploy/Strategy/Copy

But I still have doubts here.

If we use this approach, what would the exact work-flow be here?

  • From developer machine A - We grab the committed files from github using Capistrano.
  • From that same developer machine A - We deploy those files into the shared host via SSH and the files will be placed on their correct places?

Is that it?

Update: Please I've never used either Git or Capistrano Deploy however, I'm doing my best to try to understand how all this may work, in order to allow a good workflow development process for my ZF based applications.

So my questions are really basic ones.

If I must provide any additional information, please let me know.

Thanks a lot.

回答1:

The workflow is the same. What happens is, whenever either developer tries to deploy the project, Capistrano will first checkout a fresh copy of the project into a temp directory on their machine, zip it up, and upload it to the remote server. On the remote server the archive will then be decompressed and everything else works as normal.

Note that this approach is considerably slower that a 'normal' deployment, especially if your Internet connection is slow, since the whole project is being copied up each time.