I have used Heroku to push up my already coded Rails applications.
But now I wonder how the workflow would look like if I start coding a new Rails application from scratch.
For example if I use their addons (MongoHQ, Redis, Websolr, Sendgrid etc) in my application code, then I guess I shouldn't install MongoDB, Redis, Solr, Mail server etc in my local environment since they won't work with my code, correct?
So that means I have to push my app up to the Heroku platform to be able to run it in the web browser. That means, after a change of lines I have to commit and push it up.
If I'm correct, isn't this time-consuming since before I just changed the code and I could see the results in the browser immediately. Now I have to push for every change I want to see in browser.
You can install all of these locally - you should only need to specify different configurations when you are running in production rather than development.
For example, with Websolr, adding the following line in your initializer:
Sunspot.config.solr.url = ENV['WEBSOLR_URL'] if ENV['WEBSOLR_URL']
Will allow it to work both locally and on Heroku. See the docs for more information.
I can't tell for all addons, but the ones I used have very good fall-back mechanism for local deployment in development mode.
For example, Sendgrid will detect when you're using ActionMailer and send emails for you. You don't have to configure or call anything in your code. Locally you send emails as before (through sendmail or smtp server)
Same with exceptional (although you can invoke its API directly).
MongoHQ... Isn't it supposed to be replacement for PostgreSQL? Then, you should not care in most cases, just like you don't care about PostgreSQL running and not MySQL.
Related
Is it possible to deploy Ruby on Rails app on FTP?
If possible then how run migration on it?
My app also have a cronjob. How to set it?
How I deploy my webiste on FTP?
If any tutorial etc availble?
Technically it is possible to deploy by FTP, but the question is, why would you want to? It's a nightmare when compared to a modern, automated deployment system. There's also serious security concerns since FTP is not in any way encrypted and is extremely easy to crack into. Using public Wi-Fi exposes you to the risk of your credentials being captured.
The traditional way to deploy a Rails application is with Capistrano which handles packaging up your application through your version control system and rolling it on to your production system.
If you're not using a version control system that's the first thing you need to fix. Hacking away on files randomly and throwing them to a server over FTP produces quick results but over time it makes it very difficult to get a consistent, tested, reliable build over to your target server.
Remember that Rails is not something that runs automatically like .php files can be, you'll need to use something like Passenger to handle launching your application.
If all this seems a bit convoluted, it's worth trying Heroku to get started. They have a very streamlined approach.
If I understand right what you are asking (is it possible to run Ruby program using only FTP as a protocol), the answer is no, it is not possible. Ruby files is not Web static content (HTML, JS, CSS) that is executed in a browser and hence you can just upload it somewhere (as an option using FTP) and then access via Web. In case of Ruby, apart from uploading content you need to execute commands there (start interpreter, rake etc.) and this is not possible to do using plain FTP.
Normally you may want to use SSH channel to the deployment server to run the program after it has been uploaded. In that case upload is possible via FTP, but as well secure version of it, SFTP (or SCP to just copy files between local and remote machines).
Hope it helps.
The company I'm working for currently has a Rails 3 application on a dedicated remote server. The current development environment is a local machine.
We are trying to put some infrastructure in place to hire some contractors to be able to do some development remotely. Obviously this won't work with our current development setup because it's local.
I was thinking that I could put the development and test code in separate subdomains i.e.
test.mydomain.com and dev.mydomain.com.
This is a small (but growing) project and we would not have more than one developer working on one or two changes on our system at any given time. We are starting out with smaller enhancements and working our way up to bigger ones.
My question is, what is the best way to deploy a development system that contractors would be able to access remotely and securely?
Normal practice would be for developers to still develop locally on their own systems, cloning the code using a version-control system (VCS) such as git. Then, you'd either 'pull' new code from a location they give you, or allow them to 'push' code to a location you give them. There might well be a 'staging' server set up, though, where the application is deployed as an additional check before deploying to the 'live' server; Rails lets you set up an arbitrary number of environments ('development', 'production', 'test' are the defaults, but more can be added), or you could use a deployment solution which ignores these settings and uses a different approach (such as Heroku).
You need to have source control, preferrably svn, then access that source code anywhere you want. Give a user id and password to the contractor and yourself to access the svn and install local development environment using local development database on your/contractor's pc. Anyone can deploy to dev. env. Or production env only if he/she has the authentication.
I am doing something similar. We use GITs to manage the code. To manage those different environments, I think using the GIT workflow is great, but the next step is configuring a remote database for development that all the developers access. They would just need to pull the code via git, once you are able to configure a remote database in the yaml., everyone would be in sync because you are developing on the same "dev" database.
Although Rails and PHP have different deployment methods, what is the preferable way to distribute a FOSS Rails app? Suppose one of the major PHP apps - Magento, Drupal, Wordpress had been build upon RoR, what would have been the preferable way for them to have distributed their application?
Packaging up the code as a gem seems to be the wrong approach for a complete out-of-the-box application, but I could be wrong.
Coming from the world of PHP with its upload-and-go approach, and being a newcomer to Rails, it's rather opaque at the moment to see how code could be easily and effectively distributed.
Packaging a completed Rails app as a gem is probably the wrong approach. I think the best solution is to provide access to a git repository or a tarball of your git repo.
If you want to offer your users something more than rake db:schema:load to setup your app it's pretty easy to create custom setup commands.
Many applications are packaged with the source code just like typical PHP applications. While deploying Rails applications may seem difficult its expected that the user will know how to set up the server properly according to their environment and needs. The only issue you need to worry about is distributing the code, setting up the server is not a domain that you are going to want to help with.
For information on deployment in Rails you should see the deployment page here.
Well, usually Rails apps run in environment running Apache + Passenger (aka mod_rails).
Deployment is easily done with Capistrano gem.
When you're running Rails app in shared host environment, they usually use fcgi/cgi dispatchers to run Ruby.
Firstly, Happy New Year everyone.
I'm new to Rails, so please tolerate any incorrect use of terminology...
I have developed a simple Rails application, backed by a MySQL database.
I would now like to deploy this application to multiple, independent groups of users (i.e. it is a club application, and I would like to deploy it to a number of completely independent clubs).
I would like to use the same Rails Application code as much as possible, and just have a separate instance of the database for each club.
As each instance will be running on the same server (until server load proves to be an issue) I assume I can use a different port for each Rails server to steer users to the correct group?
I'd read that there are test and production modes, is it possible to have multiple [additional] instances of production modes, e.g. club1, club2, all sharing the same code, with unique databases?
My questions are how to support multiple separate database instances, and also how best to route to these?
Any advice on how to go about this much appreciated.
If you are using Git (I suggest you should be!) then you can keep a central version of your code in one place and then deploy it multiple times, changing only the database.yml file (it should not be checked in to your git repository in that case). http://git-scm.com/
Let's say you put all of your code up on github.com with username 'snips' and the project is called 'clubster'. Using something like Heroku you would then do:
git clone https://github.com/snips/clubster.git
cd clubster
heroku create boxingclub
Because Heroku auto-configures your database there is no need for a database.yml file
git push heroku master
And you'd have a version of your code deployed at boxingclub.heroku.com
When you make changes to your code you just go to each of your installations and do:
git pull origin master
git push heroku master
Which updates your code on that particular instance of your application.
And if you're getting a little more advanced you'd be looking at Chef to manage the whole setup for you. http://www.rubyinside.com/chef-tasty-server-configuraiton-2162.html
The other approach would be to have some kind of subdomain system, but I'll leave that to others to cover.
I am trying to deploy my first rails app and struggling a bit. My plan is to initially host it on a heroku free account to get a feel for live deployments and do some production testing. Eventually I might move it to a VPS.
I use git and do not use Capistrano at the moment.
Heroku primarily uses git, which is fine, but git manages the entire project state not files. So I have issues managing configuration files that are different from production to development, for example captcha keys in the environment.rb or goolge js api keys.
So what I did was to..
1 - Take the environment specific configuration out of the enviornment.rb and put it in the development.rb and production.rb. Created a branch called dev where I do my development and then merge it with master and push master to the production heroku remote.
This all works ok, but wondering if there is a better way to do it.
The other massive problem is I might have to use different gems in dev and in herouku. For example, I use ThinkingSphinix for search in dev, but Heroku I have to use acts_as_solr, which means my "Article.search call in the controller, will have to be Article.find_by_solr in production. This can become messy very fast.
What's the best way to deal with this kind of situation?
Thanks
For non-sensitive keys such as Google's JS API key etc., I found this RailsCasts episode very helpful.
Just created a config file under config/ and store your development settings in there.
# /config/google.yml
development:
google:
js:
key: 123456
test:
google:
js:
key: 345678
production:
google:
js:
key: 567890
Then create an initializer inside config/initializers/ that will parse the yaml and create an object which can be used without worrying about the current environment.
# /config/initializers/google.rb
GOOGLE_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/google.yml")[RAILS_ENV]
The environment variable RAILS_ENV refers to the current environment, so on application startup it picks up the current type, and you can refer to the settings in your code through GOOGLE_CONFIG:
<script type="text/javascript" src="http://www.google.com/jsapi?key=<%= GOOGLE_CONFIG['js']['key'] %>"></script>
For the latter issue, where code itself differs from environment to environment, I believe Capistrano would be a better solution.
For values that you want to keep different between environments, Heroku offers config vars.
As for using one indexing program in production and another in development, that's a bad idea, and will make things way messier than they need to be. Either start using Solr locally, or set up a Thinking Sphinx instance in EC2 yourself, and have your dynos connect to it.
I would suggest that it is very unwise to have different code in development and production.
Your development, test and production environments should be as similar as possible.
In fact, I would go so far as to say the entire point of the different environments is to simply provide an easy system for allowing minor configuration changes between setups. Different databases, different API parameters, different aching options, but the core system MUST be the same.
The the issue you will face is doubling your development effort. You still have to write the code. So in the search example you provide above, you will have to develop and test twice - once for the Solr production system and once for you local Sphinx, then you need to be able to switch and test between the two approaches in all of your environments to ensure test coverage and functionality.