Trying to deploy from a git server behind a firewall -- ideas?

37 views
Skip to first unread message

Isi Robayna

unread,
Apr 20, 2014, 5:10:59 PM4/20/14
to capis...@googlegroups.com
Hello,

I have a project with with two targets defined: staging & production.  Staging is within the local network (does have visibility to git server) and Production is offsite (does not have access to git server as we are hosting the git server on the local network, we are using GitLab)

I am able to deploy to staging no problem but obviously can't to production.

For the production server deployment, I have tried two things:
  1. Reverse SSH connection to local git server from target server
  2. deploying via Rsync
Any suggestions or ideas as to what would be the best practice moving forward. Any other alternatives?


It seems to me that Capistrano v3 intend differs quite a bit from capistrano v2.  Wonder if v2 was too hard to maintain and the team decided to removed features to keep the core simple.  Otherwise, I don't understand the big difference between the two

Thanks

Isi R.


Lee Hambley

unread,
Apr 22, 2014, 2:27:12 AM4/22/14
to capistrano
Hi Isi,

You might be better not loading the SCM at all (see pending issue: https://github.com/capistrano/capistrano/issues/929) and uploading via a tarball, or similar http://lee.hambley.name/2013/06/11/using-capistrano-v3-with-chef.html

- Hope those lead you down partly the right path.

--
You received this message because you are subscribed to the Google Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/3e89a100-e804-4caf-8cbc-f51df4c14707%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Isi Robayna

unread,
Apr 22, 2014, 11:41:53 AM4/22/14
to capis...@googlegroups.com
Thank you for your feedback!

After spending days on this, I have decided to revert back to capistrano v2 and try again with v3 down the road.

BTW, v2 aligns much better with this type of deployment where v3 intent seems quite different and if I am allowed to say, somewhat limited functionality out of box.

Lee Hambley

unread,
Apr 22, 2014, 11:58:53 AM4/22/14
to capistrano
BTW, v2 aligns much better with this type of deployment where v3 intent seems quite different and if I am allowed to say, somewhat limited functionality out of box.

Yes, it's better at the more standard use-case, which is what we had to shoot for, since the 5 strategies appliacable to 5 SCMs with their leaky abstractions were basically (and continue to be) completely untested in v2, and we couldn't even hope to believe that we could guarantee that everything works.

For what ti's worth, cap3 is built on Rake, which is a build tool, so you can define "I need a tarball from my working copy to upload", and Rake will lazily create it for you, and let you do what you want with it, in cap 3 that's hooked into the much simplified "flow" capistranorb.com/documentation/getting-started/flow/ - where you are encouraged to add to your own needs.
Reply all
Reply to author
Forward
0 new messages