How to upgrade rails application on client server

[Kengsreng Tang]

We ship our rails application to customer and customer deploy on their
own server.
If we release a new version that include bug fixes, and we want to apply
to those bug fixes to all clients.
What is the good approach?

--
Posted via http://www.ruby-forum.com/.

[arcasys]

If you have a network connection to your customer you should give capistrano a try. Using capistrano you can deploy to multiple servers at the same time. You need to checkin your app into a repository like svn or git from which your customers servers will then checkout and updates the deltas.
No need to have capistrano on the customers server. capistano works over ssh and runs commands on the target servers.

The most secure way is to have a vpn connection to the ccustomer site although this is not a must. But it avoids to open a ssh port on both sides which is always a risk.

[Colin Law]

On 4 February 2015 at 09:32, arcasys <ma...@arcasys.de> wrote:
> If you have a network connection to your customer you should give capistrano
> a try. Using capistrano you can deploy to multiple servers at the same time.
> You need to checkin your app into a repository like svn or git from which
> your customers servers will then checkout and updates the deltas.
> No need to have capistrano on the customers server. capistano works over ssh
> and runs commands on the target servers.
>
> The most secure way is to have a vpn connection to the ccustomer site
> although this is not a must. But it avoids to open a ssh port on both sides
> which is always a risk.

Provided the root user is disabled on the machines and ssh login with
passwords is also disabled (use keys instead) then I believe an open
port for ssh can be considered secure.

Colin

>
> Am Mittwoch, 4. Februar 2015 08:01:07 UTC+1 schrieb Ruby-Forum.com User:
>>
>> We ship our rails application to customer and customer deploy on their
>> own server.
>> If we release a new version that include bug fixes, and we want to apply
>> to those bug fixes to all clients.
>> What is the good approach?
>>
>> --
>> Posted via http://www.ruby-forum.com/.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-talk/1720e6f6-17d9-4a45-bad7-d99bb17887ac%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Vivek Sampara]

We went the route of ssh / access and failed horribly. We moved the code base to jruby and started releasing Warable files . This way, updates go in with a single click along with all the bundled latest gems. Try it out. 

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAL%3D0gLvCVDN%2BXbCTMXjcnvZTK0F77TzA0vH284GL2B_pWpyy_A%40mail.gmail.com.

[Norm Scherer]

How you do it depends a lot on whether you can push the updates or do
the customers want to pull the updates at a time of their choosing etc.
In my app I put a 'update' link which fetches (ftp) files from my server
and then installs them on the customers server. This process lets the
customer decide when he can have an interruption including a restart of
the server. If you can push the update whenever you want a capistrano
based solution may work.

Norm

[Kengsreng Tang]

Thanks for the answers.
@ Vivek Sampara how do you deal with migration? because customer have
existing data that can't be lost.

[Hassan Schroeder]

On Wed, Feb 4, 2015 at 11:03 AM, Kengsreng Tang <li...@ruby-forum.com> wrote:

Not speaking for @ Vivek Sampara but --

> how do you deal with migration? because customer have
> existing data that can't be lost.

Migrations are migrations; that has nothing to do with how the app
is being distributed.

Basically you have the servlet container (e.g. Tomcat) deploy the
WAR file, and then you run migrations as needed.

But my question is: if the customer can install the app to start with,
why is updating it any different? Surely that required some technical
ability on someone's part...

--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan
Consulting Availability : Silicon Valley or remote

[arcasys]

This is yet another good reason to use capistrano. capistrano recipes allow to define comands to be performed on the target server, so it's easy to add a mysqldump command for backup and a a rake task to perform the migration.
And, usually I warn my customers before upgrading them and agree a 'service window'. That's good practice anway.
Finally, a lot depends on your customer relationship. If your customer doesn' trust you you need to go with a different solution.