6 ms·

Okay, pre-heroku, Capistrano, which again was a huge simplification on other deployment processes. How is rails more of a pain point than anything else? Deplo

by Volpe 15y ago

Okay, pre-heroku, Capistrano, which again was a huge simplification on other deployment processes. How is rails more of a pain point than anything else? Deployment is always going to be a task that is required. Rails has for a long time had pretty good solutions to this. I'm objecting to the parent stating that deployment is a serious pain point for rails. I would like to know what the 'simple' deployment stack people are comparing the Rails stack too?

deleted 15y ago
[deleted]
regularfry 15y ago
Rsync.
flocial 15y ago
I think Java deployment is pretty straightforward and php is dead simple. I guess it depends on how much traffic your site gets but the larger your Rails site gets the more moving parts you end up with (at a lot less traffic than say a Java stack), higher server specs, reliance on memcache, some proxy, etc. just for a standard dynamic website. Sure you can wrap that deployment dance into a Capistrano recipe but it's not inherently simple. But the main point is that since Rails/Ruby requires a lot more resources (cpu, ram, etc.) and wraps a lot up into a black box (auto-generated queries that might have a deadly join or two), when you deploy it's more "thrilling" for want of a better word. I'm not saying Rails sucks completely, but the programmer productivity thing is oversold because in a small shop, the dev guys are usually babysitting servers too. This and some whimsical api changes can dampen your enthusiasm a bit. I just wanted to emphasize that some Rails enthusiasts are zealously in a state of denial of Rails/Ruby short-comings and putting a Rails app in production/deployment can be a bit challenging. Like others have said, the number of startups focused on making deployment and scaling of Rails apps "easy" kind of says something.
nasmorn 15y ago
PHP. I used rails exclusively for webdev the last 6-7 years and I just now worked on a PHP project. Deployment of PHP is the same as deployment of static HTML. How is that not simpler than what we got in rails. For rails you need to understand version control, webservers and scripting. For PHP you need to understand copy. For a serious project I think rails is great but you can't deny it involves lots of abstractions which sometimes break down and then necessitate expert knowledge that most people don't have.
- bad_user 15y ago
  Deployment of PHP is the same as deployment of static HTML Until somebody other than you does a database schema change or data migration, and forgets to tell you about it. Or until somebody adds a new PHP dependency (for resizing images or other shit like that) and forgets to tell the rest of the team. For rails you need to understand version control, webservers and scripting No shit - those things are required in PHP too, unless you're building a contact form. you can't deny it involves lots of abstractions which sometimes break down and then necessitate expert knowledge Those abstractions save you from dealing with boilerplate or with repetitive tasks that you can easily forget about. They are based on sane practices used by experts. And those same abstractions are also present in mature PHP frameworks like Symfony and not because the developers were bored to death and just wanted to complicate your life. Rails is not for contact forms. You are better off using PHP for that - but I saw contact forms evolve into big piles of unmaintainable crap and developers doing that because they thought a mature framework was too complicated and haven't evolved since then - shouldn't have a place in this industry.
  - nasmorn 15y ago
    I truly understand the points you give and I like the fact that rails has a proper process for all of this. Fact is though that 90% of projects that I didn't start myself involve FTPing stuff to a server were all the developers muck around writing over each others files. Horrible yes. State of the art in most web consultancies also yes. Passenger allows one to basically work this way with ruby too and it is sorely needed because there are 'developers' out there that seemingly haven't worked with Sourcecontrol in their entire career. If you need to give them access to some templates it is nice if you don't have to bring them up to speed on git first. I wouldn't hire those people but I was forced to work with some. My point: Allowing a less robust but easier deployment method is a pareto improvement because I can now choose. It is also a path towards sane practices used by experts when you start with a big pile of unmaintainable crap.
    - bad_user 15y ago
      I get what you're saying - and I think simple scripts uploaded by FTP are good in many contexts. However, Ruby on Rails was never good for shared hosting. It was never designed or intended for this purpose. The deployment solutions available are not doing so good in a shared hosting environment. Or at least, not as good as PHP (nothing is as good as PHP in shared hosting). The deployment story got a lot better when Passenger came along in 2008, which is a self-healing and easy to configure server, capable of functioning with Nginx or Apache in front. You wouldn't believe the shit you had to pull before that for reliable servers. Personally, I hate Heroku because their prices are for the moment too high and I could partly replicate their environment on my own, using already available tools. But such hosting services will become the norm as they are so kick-ass and convenient; for instance I just received an invitation for Gondor, a Heroku-like service for Python and Django.

by Volpe 15y ago

deleted 15y ago

[deleted]

regularfry 15y ago

Rsync.

flocial 15y ago

I think Java deployment is pretty straightforward and php is dead simple. I guess it depends on how much traffic your site gets but the larger your Rails site gets the more moving parts you end up with (at a lot less traffic than say a Java stack), higher server specs, reliance on memcache, some proxy, etc. just for a standard dynamic website. Sure you can wrap that deployment dance into a Capistrano recipe but it's not inherently simple. But the main point is that since Rails/Ruby requires a lot more resources (cpu, ram, etc.) and wraps a lot up into a black box (auto-generated queries that might have a deadly join or two), when you deploy it's more "thrilling" for want of a better word. I'm not saying Rails sucks completely, but the programmer productivity thing is oversold because in a small shop, the dev guys are usually babysitting servers too. This and some whimsical api changes can dampen your enthusiasm a bit. I just wanted to emphasize that some Rails enthusiasts are zealously in a state of denial of Rails/Ruby short-comings and putting a Rails app in production/deployment can be a bit challenging. Like others have said, the number of startups focused on making deployment and scaling of Rails apps "easy" kind of says something.

nasmorn 15y ago

PHP. I used rails exclusively for webdev the last 6-7 years and I just now worked on a PHP project. Deployment of PHP is the same as deployment of static HTML. How is that not simpler than what we got in rails. For rails you need to understand version control, webservers and scripting. For PHP you need to understand copy. For a serious project I think rails is great but you can't deny it involves lots of abstractions which sometimes break down and then necessitate expert knowledge that most people don't have.

bad_user 15y ago
Deployment of PHP is the same as deployment of static HTML Until somebody other than you does a database schema change or data migration, and forgets to tell you about it. Or until somebody adds a new PHP dependency (for resizing images or other shit like that) and forgets to tell the rest of the team. For rails you need to understand version control, webservers and scripting No shit - those things are required in PHP too, unless you're building a contact form. you can't deny it involves lots of abstractions which sometimes break down and then necessitate expert knowledge Those abstractions save you from dealing with boilerplate or with repetitive tasks that you can easily forget about. They are based on sane practices used by experts. And those same abstractions are also present in mature PHP frameworks like Symfony and not because the developers were bored to death and just wanted to complicate your life. Rails is not for contact forms. You are better off using PHP for that - but I saw contact forms evolve into big piles of unmaintainable crap and developers doing that because they thought a mature framework was too complicated and haven't evolved since then - shouldn't have a place in this industry.
- nasmorn 15y ago
  I truly understand the points you give and I like the fact that rails has a proper process for all of this. Fact is though that 90% of projects that I didn't start myself involve FTPing stuff to a server were all the developers muck around writing over each others files. Horrible yes. State of the art in most web consultancies also yes. Passenger allows one to basically work this way with ruby too and it is sorely needed because there are 'developers' out there that seemingly haven't worked with Sourcecontrol in their entire career. If you need to give them access to some templates it is nice if you don't have to bring them up to speed on git first. I wouldn't hire those people but I was forced to work with some. My point: Allowing a less robust but easier deployment method is a pareto improvement because I can now choose. It is also a path towards sane practices used by experts when you start with a big pile of unmaintainable crap.
  - bad_user 15y ago
    I get what you're saying - and I think simple scripts uploaded by FTP are good in many contexts. However, Ruby on Rails was never good for shared hosting. It was never designed or intended for this purpose. The deployment solutions available are not doing so good in a shared hosting environment. Or at least, not as good as PHP (nothing is as good as PHP in shared hosting). The deployment story got a lot better when Passenger came along in 2008, which is a self-healing and easy to configure server, capable of functioning with Nginx or Apache in front. You wouldn't believe the shit you had to pull before that for reliable servers. Personally, I hate Heroku because their prices are for the moment too high and I could partly replicate their environment on my own, using already available tools. But such hosting services will become the norm as they are so kick-ass and convenient; for instance I just received an invitation for Gondor, a Heroku-like service for Python and Django.