Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote deployments without SCM on target machine #2059

Open
fishbone1 opened this issue May 6, 2020 · 3 comments
Open

Remote deployments without SCM on target machine #2059

fishbone1 opened this issue May 6, 2020 · 3 comments

Comments

@fishbone1
Copy link

We have two web applications, one is a plain HTML/CSS/JS application and one is a Symfony4 PHP application. Both applications have assets (CSS/JS) that are generated by a build script. CSS is generated from SCSS, JS is minified etc. The Symfony app uses webpack for that.

The Symfony 4 app is running at a basic web server hosting provider. They allow SSH and to run PHP on cli and git. But there is no Node.JS (required for processing assets) and we are not able to install anything.

The plain HTML/CSS/JS app is hosted at one of our client's servers. This is a web server only, we are not allowed to run a build script via Node.JS there.

We created CI pipelines for both applications in Gitlab. We run the build scripts on a dedicated build server. The last step would be deployment - we have to store the result on the target web server. For the Symfony case we have to run composer install and clear the cache after deployment.

So I found Capistrano and everything I read about it made me confident that it is the proper tool for this deployment step. We could write scripts on our own, but there are already recipes which take care of special shared and writable directories. Additionally it allows rolling back and keeping arbitrary number of releases. Perfect!

But when I dived into the documentation I realized that I have to configure a SCM repository on the target machine and that Capistrano will check out the source code there. But this doesn't help us at all, because the files generated by the build process will be missing.

This SO entry confirms it:
https://stackoverflow.com/questions/24220779/can-i-deploy-with-capistrano-without-scm

I'm really confused as I cannot imagine that a popular deployment tool like Capistrano doesn't fit for our basic deployment requirement. I don't think our development/deployment process is something special today (i.e. CI build servers). We even have a third Angular app with the same requirements. Capistrano seems to be unable to perform the actual deployment (transfering the build artifacts from the build machine to the target machine).

In my experience the case that you build an application on the machine where it is deployed is rather rare. So my feature request here is to allow remote deployment (maybe via rsync). It seems that this was possible with Capistrano 2, so I think you had good reasons to drop this feature and maybe our deployment process is not as common as I thought. So at least, if you won't allow remote deployments again, I ask you to clearify in the README.md that the build process has to be executed on the target deployment machine and that you shouldn't use Capistrano if you have plain web servers that are not able or allowed to run programs required for building.

@leehambley
Copy link
Member

leehambley commented May 6, 2020

If you have a CI server that builds assets and will run Capistrnao why not simply upload the assets after doing the deploy (or, during the deploy)?

See:

and

@fishbone1
Copy link
Author

fishbone1 commented May 6, 2020

Thanks for your quick response and of course for all your work here!

After building assets my manual steps would be:

  • on the build server:
    • transer the built files to a new release directory on the deployment-target machine
  • connect to the target server via ssh
    • create symlinks to directories that are shared across releases (e.g. logs, file uploads)
    • make sure that web server has write access for respective directories (logs, cache, file uploads)
    • install dependencies (in some cases this is done during the build phase, but for Symfony you can get into trouble if you do this on a different machine with different PHP version)
    • clear and warm up cache
    • migrate the database
    • change the symlink of the current release to that new release directory
    • delete older releases (but keep 5 to allow rollback)

This fits to your flow or the Symfony plugin's flow and I understand that i can extend it (e.g. the database migration part).

The only problem I see is the first step "transfer the built files...". As far as I understand it's mandatory to have a SCM on the deployment target machine and checkout the code there. Or did I understand it wrong? Then I'm sorry for wasting your time here. I have to admit that the documentation is hard to understand for me.

@leehambley
Copy link
Member

As far as I understand it's mandatory to have a SCM on the deployment target machine and checkout the code there.

It's not mandatory, but expected. You can also run "no" scm plugin and simply transfer files (using Capistrano as a glorified hooks/remote execution framework).

One example of that approach is https://github.com/ctaintor/capistrano-rails-artifact

We also document how to provide a custom SCM https://capistranorb.com/documentation/advanced-features/custom-scm/ this SCM would implement whatever you need to do a "gitless" checkout on the server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants